00:00 zmike: barriers have no such language so they're on a different cleanup list
00:04 alyssa: ok, have barriers ~working on bifrost
00:04 zmike: \o/
00:04 imirkin: just a bit-flip away from working then
00:06 alyssa: hehe
00:06 imirkin:still doesn't have working barriers on nvidia
00:06 jekstrand: Should work out-of-the-box for us, in theory.
00:07 imirkin: they _mostly_ work, but definitely ways to defeat them
01:16 jenatali: karolherbst: You're using -O0 for CL compilation, right? Did you have to add a workaround for inline functions not getting emitted?
07:15 jekstrand: jenatali: Any idea how OpenCL force_unroll decorations are supposed to get carried through SPIR-V? In Vulkan, they go on the OpLoopMerge but CL doesn't have that.
09:53 pq: I tried Bichon today very briefly, and I'm convinced it will make the people disliking the Gitlab web UI to enjoy reviewing MRs. I might use it myself, too. :-)
10:30 emersion: hrm, it needs some kind of gnome thing for the keyring
10:30 emersion: can't get it to work
10:30 emersion: the gnome thing is running, but it needs a keyring i don't have and can't create
11:18 jadahl: emersion: seems it uses "secret service". if you can't get gnome-keyring to work, you can try other implementations
11:19 emersion: the issue is that it requires the secret service keyring to have a specific name
11:19 emersion: and i can't find how to create a keyring with the name "login"
11:19 emersion: seahorse has a keyring name field, but it seems like it's a human-readable string, not the keyring ID
11:19 jadahl: the login one is special AFAIK, opened via pam or something like that
11:20 emersion: well it can have an empty passphrase
11:20 emersion: then no need for PAM
11:20 jadahl: ah ok
11:20 emersion: the fix is to patch Bichon to use the default keyring
11:23 jadahl: bichon seems interesting
13:37 pq: emersion, I didn't use a "secret service". Bichon noticed that and said it'll store stuff encrypted with a password of my choosing.
13:37 pq: a password I need to input every time I start Bichon
13:45 jenatali: jekstrand: Not offhand at least
14:13 emersion: pq: yeah, i wish it accepted no password
16:08 linkmauve: Hi, in intel-gpu-overlay, what is the difference between Power and Package, both being in mW?
16:34 linkmauve: It seems Power is only the GPU, while Package is GPU + CPU + VSC + possibly other parts.
16:35 linkmauve: intel_gpu_top seems to only report the former, is there a way to also see the latter?
16:48 jekstrand: jenatali: k. I'll ask some of our CL people.
16:48 jekstrand: jenatali: I tried putting them in a kernel and realized they don't propagate to NIR.
17:42 jekstrand: Totally random but bitonic sort is pretty cool
18:18 linkmauve: Uh, the merge request process is very easy to misunderstand when the target project has disabled this workflow.
18:19 linkmauve: I ended up creating a merge request to my own master: https://gitlab.freedesktop.org/linkmauve/igt-gpu-tools/-/merge_requests/1
18:26 robclark: mareko, Kayden: btw one thing that bothered me about threaded-ctx is how to ensure that only "safe" things are done w/ the pctx in things called directly from st thread.. so was playing around with clangs locking annotations to help with that.. not completely sprinkled about but enough to show the idea.. https://gitlab.freedesktop.org/robclark/mesa/-/commit/64e15dba24031c72485c93c8ed8ee0879423bcb0
18:27 robclark: (inspired by an earlier experiment with the annotations from krh)
18:32 mareko: robclark: it's easy to check whether a driver is thread-safe: when it only uses ctx->screen
18:34 robclark: there are a few more things that I need from `fd_context` in places, but they are immutable.. I suppose with a lot of shuffling things around stuff could be moved to fd_screen
18:35 robclark: but that is a bunch of churn.. and if I can use the compiler to help me instead, that seems nice
18:44 zmike: it's easy to test if your driver is threadsafe with tc: just run citra :)
18:57 robclark: heheh, I was looking for something a bit more pro-active :-P
18:58 robclark: and that would catch issues in CI
18:58 zmike: yeah for sure that'd be A++++ 👍👍👍
20:05 Kayden: robclark: neat, that looks interesting
20:07 robclark: it is turning a bit into sprinkling annotations everywhere.. but I guess that does also serve to document what gets called where
21:18 soreau: emersion: It turned out to be https://gitlab.freedesktop.org/mesa/mesa/-/issues/4294 of which, this is the culprit https://gitlab.freedesktop.org/mesa/mesa/-/commit/b4651890be4db10a6a6ebf0e6cf2fad7d00623b9#bf3ef1d03575f4461cf4459a7ce353e7022048a7_300_322
21:19 soreau: now I'm wondering if this is something that is expected to be updated in libav
21:20 alyssa:hyped for freedreno + tc
21:29 pepp: soreau: see https://gitlab.freedesktop.org/mesa/mesa/-/issues/4285 and https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9020
21:37 soreau: pepp: yep, that works
21:44 soreau: would be nice to have this command in a CI runner
21:45 soreau: or somehow part of intel va test
22:27 krh: robclark: I think the added annotations are actually a feature of this
22:44 alyssa: krh: inclined to agree even if I suspect if we try to standardize the names we'll bikeshed for ages
22:46 robclark: we just need libbikeshed :-P
22:46 alyssa: robclark: don't you mean bikeshed.rs? :P
22:46 alyssa: we wouldn't want to bikeshed in memory unsafe languages, would we?
22:47 robclark: :-P
22:47 robclark: cargoshed :-P
22:47 alyssa: <3
22:48 alyssa: reading about clang's thread-safety checker, this does seem Rust inspired :>
22:50 jadahl: is llvmpipe on aarch64 known to work? getting swapped color components and not sure whether to blame myself or mesa
22:53 alyssa: it, shoudl?
22:54 robclark: just don't try aarch64 b/e
22:55 jadahl: i double checked that it's l/e, but the as far as I can see, the same code path on an x86_64 produces the same result with swapped red and blue
22:56 jadahl: but as far as I know, running on arm gpu drivers should work just fine
22:56 jadahl: (this is running in CI)
22:56 alyssa: jadahl: greyscale screens can improve productivity, why don't you do that? then it fixes the BGR issue? ;P
22:57 jadahl: alyssa: should made HDR grayscale too. super black to super white only
23:07 jadahl: ahah, I think I found it. different order of executing function arguments; argumenst which were more or less init_color_rgb(pick_color_component(colors), pick_color_component(colors), pick_color_component(colors)) (pick_color_component() being get a semi random number and colors the random generater with a given seed)
23:59 bnieuwenhuizen: hah, unspecified behavior strikes again :)