06:54luc: hi, is there any particular reason why "for gallium we only support combined Z+stencil, not separate buffers" in mesa::do_validate_framebuffer?
07:23MrCooper: luc: it was a design decision, which simplifies some things; when Gallium was created some 15 years ago, there was already a trend for hardware to support only combined depth/stencil
07:35luc: MrCooper: does that mean most of modern hardwares do not support separate z/s buffers?
07:38MrCooper: I suspect so, not sure though
07:40MrCooper: I have vague recollection Direct3D >= 10 might not support separate depth/stencil buffers at all, again not sure though
07:42luc: MrCooper: thanks a lot for your explanation
07:44dj-death: maybe someone remember what NIR pass optimizes things like : if (true) { some_code... }
08:01glehmann: nir_opt_dead_cf
08:07dj-death: glehmann: thanks :)
11:21meltq: could someone point me to documentation about the possible return values for regulator_enable()? is it always 0 if no error, negative on error?
11:30jani: anyone up for reviewing a fairly mechanical guid_t change? https://lore.kernel.org/r/20240812122312.1567046-1-jani.nikula@intel.com
12:31Schrostfutz: Hi, I'm running into a segfault in rockchip_dri.so. The stacktrace is less than helpful so I want to build a debug version of the mesa present on my system. Where can I find documentation on how to do this?
14:05DavidHeidelberg: eric_engestrom: btw. for the 24.2.1, would you be ok dropping sha512 into docs too? I always find it in the announcement, but in docs is only sha256
14:09eric_engestrom: DavidHeidelberg: please send an MR to change https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/bin/gen_release_notes.py#L68 :)
14:10gfxstrand: jenatali: Care to RB the vtn patches in 30875?
14:12gfxstrand: You seem lke the most relevant person
14:12jenatali: gfxstrand: yeah I'll take a closer look in a bit
14:13jenatali: The MSVC upgrade is good to go btw
14:13gfxstrand: \o/
14:16DavidHeidelberg: eric_engestrom: sure, on it! :P
14:17gfxstrand: cwabbott: The only driver missing an ack in 30876 is turnip
14:19DavidHeidelberg: eric_engestrom: do I get it right, that the checksum is manually pasted there?
14:20eric_engestrom: yes, although in practice I have a script that greps it out of the generated announcement email and seds it into the release note and then commits that, because if I had to actually do it by hand I'd mess it up half the time 😅
14:21DavidHeidelberg: eric_engestrom: so "s/SHA256 checksum/SHA checksums/" would do it for you? (as the checksum has different lenghts)
14:23eric_engestrom: dcbaker was working on a better release script but I think he never finished it, and I've been too busy/lazy to take over as I already have this locally anyway, but it's not great if we were to onboard a new release manager as I'd need to give them my dozen or so tiny scripts automating the various parts
14:24eric_engestrom: DavidHeidelberg: yeah that's fine
14:28dcbaker: eric_engestrom: I should really get that rebased and sent out again…
14:53mareko: luc: AMD doesn't support separate z/s; even though they are separate in memory, there are certain attributes between them that must be identical
15:52DavidHeidelberg: eric_engestrom: seriously, https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30901 for this whole pipeline? you know how much dinosaurs you burning for this sh*t :D
15:54DavidHeidelberg:proposes GitLab feature, which reports how much of a dinosaur is burned per MR
15:55eric_engestrom: fine, I'll put that commit in the next CI MR I merge
15:55eric_engestrom:is trying to get things merged before being away for a while
15:55DavidHeidelberg:is also a bit selfish, because running half of Adreno farm to test ir3 changes
15:55zmike: who cares it's still only 0.00000001% of a cryptobro
15:56DavidHeidelberg:got idea for perfect cryptocurrency. Don't steal it. It's Dinosaur coin. :D
15:57zmike: https://www.dino.win/
15:57eric_engestrom: yeah I don't think the power consumption is any relevant here, but the CI time taken away from someone else would be
15:57zmike: we should have a label for marge weekend queue
15:58zmike: and then a cron job assigns everything with that label to marge saturday afternoon
15:58DavidHeidelberg: zmike: damn. So you want make my weekends waiting longer? :D
15:58eric_engestrom: zmike: yeah that's not a bad idea
15:59DavidHeidelberg: No, no, it isn't. Weekends is only time, when I can happily merge what the f I want without waiting :D don't ruin it for me.... no seriously, having tag "Merge-when-Marge-is-free" would be cool
15:59eric_engestrom: mind creating an issue with that so we don't forget? 🫣
16:01DavidHeidelberg: ^^^ :)
16:01eric_engestrom: thx!
16:10Company: zmike, MrCooper: so https://gitlab.freedesktop.org/mesa/mesa/-/issues/11784 sounds to me like an issue with sizing when GTK creates the egl_window/egl_surface waaaay before actually creating doing any wl_surface setup?
16:12MrCooper: the "first frame doesn't show up" part, yeah possibly
16:12MrCooper: GTK needs to set the window size before calling eglMakeCurrent with non-NULL surface
16:13Company: we set the "window size"
16:13Company: in the sense that there isn't one yet
16:13Company: we create the egl_window shortly after calling wl_compositor_create_surface()
16:14MrCooper: specifically wl_egl_window::width/height is what matters
16:15Company: can GTK manually resize the window?
16:15MrCooper: how is the initial window size determined?
16:17Company: we just hardcode 1x1 I guess
16:17Company: because we don't have any size at that point
16:17MrCooper: I mean the size of the first frame
16:17MrCooper: it was working fine somehow before the 2 gtk commits I bisected
16:18Company: previously we bound to EGL_NO_SURFACE first
16:18Company: which meant we didn't need to create the egl_window
16:18Company: and then later did a 2nd make_current()
16:19MrCooper: still needed to MakeCurrent the actual surface at some point though, and the egl_window size had to be correct at that point
16:19Company: yes, but that happened after we negotiated a proper size with the compositor
16:19MrCooper: then that seems required
16:20Company: and now the code seems to crea the egl_window with 1x1 size and then resizes it to the proper size later
16:21Company: this is not an issue on other platforms like X11 because X11 windows always have a size
16:22Company: XCreateWindow() needs one while wl_compositor_create_surface() doesn't
16:22Company: so that's a thing to make code fall over I guess
16:24Company: I think that's a bug in Mesa (or EGL) still, that it's unclear what the initial size of an egl_window() should be or if it's illegal to create one until the first configure
16:24Company: but I can deal with this in GTK I think
16:25Company: now that I know what the issue is
16:25MrCooper: I don't think it's illegal per se (there's no error), EGL just needs to know the intended window size to choose the back buffer size
16:27MrCooper: the EGL Wayland platform does, specifically
16:27Company: yeah, but we give it the right one via wl_egl_window_resize() later
16:28MrCooper: too late
16:28MrCooper: the back buffer is locked in MakeCurrent
16:28MrCooper: meaning it can't change until SwapBuffers
16:29Company: do I need to re-MakeCurrent() after every resize?
16:29MrCooper: no, per my comment on the issue
16:29Company: or do I even need to SwapBuffers()
16:30Company: so this is only for the first frame?
16:30MrCooper: you need to wl_egl_window_resize before querying the buffer age or doing the first drawing operation
16:30Company: we do that
16:31MrCooper: k, then I guess the question is: does Mesa really need to lock the back buffer in MakeCurrent? Not sure offhand
16:32Company: create 1x1, makeCurrent, resize 828x629, query buffer age (which returns 0 as it should), render full frame, SwapBuffers()
16:32MrCooper: daniels: ^ thoughts? https://gitlab.freedesktop.org/mesa/mesa/-/issues/11784 for more context
16:39MrCooper: Company: though I'm afraid you'll have to deal with it for existing Mesa releases anyway
16:39Company: yeah
16:40daniels: yeah, I don't like those semantics, but those are the semantics we have ...
16:40daniels: by the time it came up, it felt like it was too late to change it, since breaking API is ... not great ... and the way you find out that resize semantics have changed from under you is catching a fatal client error
16:41MrCooper: daniels: specifically, I wonder if the back buffer really needs to be locked already in MakeCurrent
16:56daniels: all things being equal, I think it would be better if it weren't
16:56daniels: however, if we make it not be locked in MakeCurrent, then we change visible semantics
16:56daniels: and I'm not sure whether or not that's safe at this point
17:03MrCooper: right
17:11Company: MrCooper: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/7662
18:45DavidHeidelberg: Mary: Heya, I ran OpenCL piglit set (I was thinking about adding it as nightly, to keep consistent check how the CL works) and it looks kinda brutal, if you're interested in seeing it https://gitlab.freedesktop.org/dh/mesa/-/jobs/62875796 if you see some low hanging fruit to reduce crashes, I'm happy to run the CI branch against it
19:13daniels: DavidHeidelberg: heh yeah, midgard is pretty wild-west for CL, but last we saw CSF/bifrost are in better shape
19:23DavidHeidelberg: daniels: nice to hear, thou T860 is very important, as it's inside the PinePhone Pro :) Let's not talk about the glorious Mali 450 in PinePhone 1 which can do hardly 3D
19:24daniels: haha
19:24daniels: yeah and RK3399 also lives on forever
19:26DavidHeidelberg: daniels: btw. re-did the CL testing TGL -> ADL https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29516
19:45daniels: ahhh yes, sorry, have been sidetracked by other things :\
19:45DavidHeidelberg: np I pushed it yesterday, mentioning it since we talkin
21:23jenatali: eric_engestrom: You might have opinions on !30877. I'm just looking for someone to give me a thumbs up/down :)
22:05eric_engestrom: jenatali: ack (although I see you already got two acks), but I'm a bit surprised by the `14.29 -> 14` change; does it mean `14.*`?
22:06jenatali: Yeah it does
22:06eric_engestrom: ok
22:06eric_engestrom: not sure if you want to pin it to the next version instead?
22:06jenatali: We were already installing both sets of build tools and we had tried to upgrade a while ago, but ran into NaN issues that I recently diagnosed and fixed unrelated to the version bump
22:07eric_engestrom: on the linux side that's what we do, so that a re-gen of the image for another reason doesn't randomly pick a new version of one component
22:07jenatali: I guess we could? I'm not entirely sure what the actual version is :)
22:07jenatali: I think it's 14.40 currently
22:07eric_engestrom: hehe
22:08eric_engestrom: I'll leave that as a comment on the MR as well, for posterity
22:08jenatali: Yeah, I think I have a slight preference to keep rolling forward and only pin when there's problems
22:09eric_engestrom: ack
22:09eric_engestrom: I posted my comment, I guess you can reply that there too :P
22:09jenatali: Sounds good :P