05:03 maor: tell me anyone can write what the status of mesa 23.2 ? and why its so hard to update the "release calendar" in the site?
05:04 maor: at least let him write like a professional how long it was postponed
08:02 Company: 15 minutes to compile a shader
08:02 Company: that's still faster than compiling my project
08:03 Company: but I think it's a bit slow even on an rpi
08:22 Company: oh look, if I rm the panfrost vulkan renderer, I even have a working Vulkan for my rpi
08:22 Company: what's going wrong there?
08:23 HdkR: Probably the PanVK driver returns incorrect results on initialization on a non-panfrost device, which freaks out the vulkan loader. Raspberry Pi's vulkan driver did this for a while as well.
08:26 Company: that's entirely possible
08:26 Company: because it turns out I now have llvmpipe
08:26 Company: which makes sense, because llvmpipe does descriptor indexing, and the rpi does not
08:27 Company: however, I should have gotten llvmpipe without panfrost probably, and I did not
08:27 Company: also, how does llvmpipe do 10fps on an rpi, that's pretty amazing
12:20 karolherbst: do we have a pass to lower 64 bit phis?
12:21 karolherbst: or maybe 64 bit registers?
12:21 karolherbst: though given that backends call nir_convert_from_ssa pretty late, I'd rather lower 64 bit phis
12:33 karolherbst: uhh.. it's probably caused by nir_opt_peephole_select or something..
12:34 karolherbst: mhh, nvm... it's still because something decides we need 64 bit phis even though it's all lowered...
12:38 karolherbst: ohh, it's part of nir_lower_bit_size.c
12:38 karolherbst: `nir_lower_64bit_phis`...
15:45 gfxstrand: Did we just cut a release?
15:46 gfxstrand: No, we're in rc3
15:59 gfxstrand: dcbaker: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25357
16:00 gfxstrand: dcbaker: That needs to go in 23.2
16:00 gfxstrand: dcbaker: We should probably talk about NVK back-ports. I've not been tagging things stable but I guess I should start. What's the best way to do that? Give you an MR against the 23.2 staging branch?
16:01 dcbaker: gfxstrand: I’m planning to get rc4 out today and try to have the final out Wednesday
16:01 dcbaker: Yeah, if you have a lot you want an MR would be helpful
16:02 gfxstrand: IDK how much I have. I'll need to take a look
16:02 gfxstrand: That one's the important one, though. I really don't want any old UAPI leaking into a Mesa release.
16:04 dcbaker: That makes sense
16:05 gfxstrand: Oh, wait... Looks like all of NVK is after 23.2.0-branchpoint
16:05 gfxstrand: Has it really been that long?
16:06 gfxstrand: Or that not long as the case may be?
16:07 gfxstrand: In that case, no rush.
16:07 gfxstrand: My sense of time is non-existent
16:09 dcbaker: Mine either, which is also why I’m so behind on the release…
16:09 gfxstrand: Heh
16:09 gfxstrand: Time is an illusion. Lunchtime doubly so.
16:52 habernir: dcbaker what are the chances that you release the final version of 23.2 this Wednesday or this week?
16:52 habernir: ***just want to know thats all
16:53 dcbaker: The goal is this Wednesday. That basically requires that all of the CI is green
16:53 habernir: ok thanks
16:56 soreau: daniels: here you are https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25358
16:57 soreau: zmike: I created an issue about Xwayland crashing on zink https://gitlab.freedesktop.org/mesa/mesa/-/issues/9875
20:51 veryclosed: I wanted to slap one apache licensed solution too, which looks interesting but with half of the day staring at it , i have not been able to decipher the compression yet though, cause that way i did not design my own, and can not read it easily. So this is the most challenging file https://github.com/jix/varisat/blob/33e876937c5d22305664e9ae5601484b25cec23f/varisat-internal-proof/src/vli_enc.rs
20:52 veryclosed: but it round about looks likely something similar or neat too
22:39 veryclosed: I can not parse those pseudo-codes at all, but it's base128, which should mean that 128 value is now 10, isn't it? so 256 is 20, 1024 is 80 etc. not very efficient compression still
23:04 veryclosed: hmm or like this , taken another way so bit1 is 1 bit2 is 128