08:00 tzimmermann: danvet, could you take a look at https://lore.kernel.org/dri-devel/20200813135109.10724-1-tzimmermann@suse.de/ ?
08:01 tzimmermann: it's still the issue with ast mode switching
08:30 MrCooper: DPA: those are generally harmless, valgrind just doesn't know how those ioctls work
09:55 pq: swick, I suspect we would need to ask that on dri-devel mailing list and CC the people who added and reviewed that property.
13:12 kisak: it's super late for me to mention this, but might as well. Hi, I've put out yet another mesa PPA for Ubuntu 18.04+ which is easily findable at this point.
13:13 kisak: The general idea was to fill the gap the aging Padoka Stable PPA left behind and fast track some game-fixing backports
13:14 kisak: if at any point this PPA causes any mesa dev some trouble, please let me know so I can take action.
13:15 kisak: in particular, I don't want to step on tjaalton's toes at all.
13:56 mareko: robclark: ffma is totally broken on freedreno; if I improve fusing, this appears to break: https://tracie.freedesktop.org/dashboard/imagediff/mesa/mesa/4507472/glmark2/terrain.rdc/
13:57 mareko: robclark: that's quite a difference
13:58 mareko: robclark: all failures are here: https://tracie.freedesktop.org/dashboard/job/mesa/mesa/4507472/ - the other failures seem OK
13:59 mareko: robclark: I'd like to merge it, so you need to make a decision about what to do with freedreno: 1) disable ffma 2) update hashes to the new values 3) something else?
14:09 pepp: mareko: the terrain.rdc failure is odd but the new result is closer to the expected result on panfrost (https://tracie.freedesktop.org/dashboard/imagediff/mesa/mesa/4425201/glmark2/terrain.rdc/)... but still different from radeonsi https://tracie.freedesktop.org/dashboard/imagediff/mesa/mesa/4507501/glmark2/terrain.rdc/
14:28 robclark: mareko: just update the hash.. or better yet remove terrain (IMO).. it is pretty horrible about precision. I've seen similar differences highp vs mediump with blob, and afaiu our use of the mad instructions is ok (at least for gles)
15:37 tjaalton: kisak: as long as you stay close to distro packaging, you're fine ;)
15:41 kisak: every xx.x.0 release is a pull from debian sid or testing, then adjusted based on my notes
15:56 jenatali: jekstrand, airlied, karolherbst: Did we come to a consensus on how to deal with Clover gaining a libclc dependency, considering that the SPIR-V target is only in LLVM master? I don't recall
15:57 jenatali: I think that LLVM master's libclc has everything we need for the Clover/vtn MR to merge, if karolherbst was satisfied with the Clover bits, and if we have a plan for how to deal with that dependency
16:00 jekstrand: jenatali: I don't think we had a solid plan.
16:01 jekstrand: jenatali: We could always put it behind a switch for one release
16:01 jenatali: jekstrand: That seems reasonable
16:02 jenatali: Though that probably means going through the vtn code for it and adding fallback paths for things which now rely on libclc, but didn't before
16:21 jekstrand: jenatali: Yeah... I'm not sure how worth it that really is
16:21 jekstrand: jenatali: Honestly, I'm kind-of inclined to say that SPIR-V clover requires libclc and call it a day
16:22 jekstrand: It's not like anyone's able to use clover+nouveau from upstream today
16:22 jenatali: jekstrand: That'd be fine by me
16:23 jekstrand: I just don't want to stomp on karolherbst's attempts to get stuff working upstream unnecessarily.
16:23 jenatali: Yeah
16:23 jenatali: I went ahead and took the WIP tag off that MR
16:23 jekstrand: So what I'll say is that making libclc a hard requirement is my preference. If karolherbst or airlied badly wants to not regress what we have working upstream, I'll let them fight for it.
16:23 jenatali: The fma libclc change is still pending, but that's an optimization for sin/cos rather than a hard requirement
16:24 jekstrand: jenatali: From what you were describing earlier this week, it's a very necessary optimization. 🤣😭
16:24 jenatali: jekstrand: Yeah...
16:24 jenatali: I actually realized that was the reason why I had so many blocks
16:25 jenatali: Because I was inlining unoptimized sin/cos with a not-yet-deleted branch for software fma vs fmad
16:25 jekstrand: SW fma?
16:25 jekstrand: Ah
16:25 jekstrand: That'll do it
16:25 jenatali: Inlining 16 copies of SW fma is enough to hit the block limit apparently :)
16:25 jekstrand: I think you probably want to optimize the libclc stuff somehow
16:26 jenatali: jekstrand: I'm writing that right now :)
16:26 jekstrand: We might want to consider doing it as part of the build
16:26 jekstrand: :)
16:26 jekstrand: Or just optimize it the first time and throw it in the disk cache
16:26 jenatali: Hm, yeah, maybe we should just run SPIRV-Opt on it as part of the build...
16:26 jenatali: Since we can't run LLVM optimizations onit
16:26 jekstrand: SPIRV-Opt increases dependencies though
16:27 jekstrand: And probably doesn't do the optimizations that will really cut down that stuff like opt_peephole_select
16:27 jenatali: Yeah, I was planning to just run NIR optimizations on it and cache the results
16:27 jekstrand: That should work
16:28 jenatali: (https://gitlab.freedesktop.org/kusma/mesa/-/issues/89)
16:28 jekstrand: And it'll likely cut down your CTS runtimes a good bit too
16:28 jekstrand: I don't know what it's like in CL land but the OpenGL and Vulkan CTS spend about half the wall time in the shader compiler.
16:28 jenatali: Yeah, I'm sure it'll help
16:29 jekstrand: jenatali: How long did that vec16 sin test take to compile?
16:29 jenatali: Too long :)
16:29 jenatali: Like 10 seconds or so
16:30 jekstrand: Oh, that's nothing.
16:30 jenatali: Most of the time was spent in the CSE pass allocating/freeing memory
16:30 jenatali: Well, if I let it run multithreaded it took minutes, but that's because CLOn12 has a bug where it'll compile the same shader on multiple threads, and only cache the first-to-finish result
16:30 jekstrand: We have some fp64 tests that take on the order of half an hour with sw emulation.
16:31 mareko: cwabbott: can you please review this commit? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6596/diffs?commit_id=109a6b7791c284087d4f75cad0ec54ac08e2c023
16:31 jekstrand: Well, they used to. I think we've got that trimmed down now.
16:52 jenatali: Hm... well I'm crashing while serializing... that's not great
17:04 dcbaker[m]: bnieuwenhuizen: I'm a little behind this week, but I'm trying to get all of the 20.2 stuff merged, I've got a patch from you "spirv: Deal with glslang..." that seems to be missing a lot of stuff in 20.2. I couldn't figure out exactly what was needed though. What do you want to do with that one?
17:21 kisak: dcbaker[m]: that's odd, 20.2.0-rc4 + !6451 applies and builds here.
17:26 kisak: maybe the two patches got separated or out-of-order?
17:26 bnieuwenhuizen: dcbaker[m]: which of the two? but yes they should be cherry-picked into 20.2. I'm pretty sure they shouldn't really need anything that camse after it
17:27 bnieuwenhuizen: let me make a backport MR
17:30 dcbaker[m]: bnieuwenhuizen: only the decorator one is tagged for stable
17:31 kisak: both have the same Fixes: commit
17:33 bnieuwenhuizen: dcbaker[m]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6690 both have the same fixes and neither have an explicit stable tag?
17:33 dcbaker[m]: oh, the non-uniform one applied cleanly
17:33 dcbaker[m]: odd
17:34 dcbaker[m]: I think there must be some other patch I need first, because the diff is a bunch of vtn_ functions
17:35 bnieuwenhuizen: dcbaker[m]: I think we just ended up adding new functions in the same position
17:35 bnieuwenhuizen: there is no real dependency
17:35 dcbaker[m]: yeah, I think I can just resolve this myself
17:37 dcbaker[m]: compiling now, looks like my fixup work
17:38 dcbaker[m]: *works
17:38 dcbaker[m]: sorry for the noise
17:53 ajax: i wish there was a way to get git to know that like docs/relnotes/new_features.txt is context-free and append-mostly and to try that for conflict resolution on rebase
17:56 emersion: apparently there's a merge=union gitattribute
17:56 emersion: see "Update" in https://about.gitlab.com/blog/2015/02/10/gitlab-reduced-merge-conflicts-by-90-percent-with-changelog-placeholders/
17:57 ajax: repo-wide though? that seems masochistic
17:57 ajax: i guess there's define-your-own too. hm.
17:58 dcbaker[m]: Looks like you can do File merge=union
17:58 dcbaker[m]: Which site like what we want
17:58 dcbaker[m]: *sounds
18:29 sravn: narmstrong: Nice lvgl drm driver you have created!
18:35 narmstrong: sravn: thx !
19:53 rak-zero: umm hey guys
19:53 rak-zero: so i got into fbdev coding and really like it
19:53 rak-zero: its faster than anything i ever worked with
19:54 rak-zero: so ... my code may be noob: https://bpa.st/LB5Q
19:54 rak-zero: but it works quite good
19:54 rak-zero: the issue is, it segfaults, but i'm sure i don't write over the resolution
19:55 rak-zero: i get 1366x768 and can write 1366x500 just fine
19:56 rak-zero: i try to get screensize in that code, but it shows different results each time
20:01 mareko: jekstrand: can you please review this commit? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6596/diffs?commit_id=109a6b7791c284087d4f75cad0ec54ac08e2c023
20:25 jenatali: jekstrand: https://github.com/microsoft/OpenCLOn12/pull/9 :)
20:25 jenatali: In hindsight, I wish I made a way to get cache sessions from D3D without having a device, since so much of CL is device-independent, but oh well
20:55 airlied: jenatali: no objections from me on libclc hard dep
20:58 jenatali: airlied: Thanks
21:17 dcbaker[m]: pendingchaos: I've got "spirv: fix emitting switch cases that jump..." on the stable list, but there's some missing ground work, in particular vtn_case->block isn't in 20.2 I can pull that patch it, but I'm afraid I might be missing more important stuff with that just the one patch
21:19 kisak: dcbaker[m]: I fast tracked that commit into my 20.1 build. It needed https://cgit.freedesktop.org/mesa/mesa/patch/?id=467b90fcc46efdd5ce64a12937fedf507d0242ec to apply cleanly in my build, which isn't in any release branch.
21:19 dcbaker[m]: Is that enough, or is there missing intermediate stuff in there?
21:20 kisak: that was the only dependency for me
21:21 dcbaker[m]: alright, that applies cleanly on 20.2 as well, so I pulled that
21:21 dcbaker[m]: let's see what all of the CI's say :)
21:21 dcbaker[m]: especially after I pulled a whole weeks worth of patches in one day...
21:23 dcbaker[m]: Anyone else getting glcpp test failures? I'm getting an error about "$end" instead of "end of line" wondering if it's just a difference in the version of bison/yacc I'm using
21:23 dcbaker[m]: oh... I just pushed to the wrong branch
21:23 dcbaker[m]: *@#$