02:20swung0x48: anyone reviewing this mr? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37084
02:20swung0x48: (also i dunno if this is the right place to ask for review)
04:10airlied: mlankhorst: finally, reposted
06:09tzimmermann: jfalempe, hi! if you have a few minutes, could you please review the ast patchset at https://patchwork.freedesktop.org/series/153350/ ?
06:36jfalempe: tzimmermann: sure, this is on my todo list for today ;)
07:36tzimmermann: thanks for reviewing
08:23phasta: If a patch intended for drm-misc-fixes was accidentally applied to drm-misc-next, what should one do about it?
09:35glehmann: does !nir_block::divergent mean all invocations are active in this block in a compute shader?
09:38glehmann: for if/else it should be if the description is correct, but I'm not sure about loops
09:39glehmann: if there is a divergent break/continue, I mean
09:48jnoorman: glehmann: if I interpret nir_divergence_analysis correctly, a divergent break/continue will mark the loop as divergent. a simple test shader seems to confirm this as well.
09:48jnoorman: though I guess !nir_block::divergent might also mean that _no_ invocations are active.
10:53phasta: sima: mripard: https://lore.kernel.org/dri-devel/20250901124032.1955-1-pierre-eric.pelloux-prayer@amd.com/ that one should have been pushed to drm-misc-fixes (is now on drm-misc-next instead). Can I just push it additionally to drm-misc-fixes?
10:56mripard: b2b8af21fec3 ?
10:58phasta: mripard: yes
10:59mripard: phasta: done
10:59phasta: mripard: thx!
11:28sima: phasta, yeah it's better to let maintainers do the cherry-pick so it's correctly tagged and doesn't confuse stable backporters
12:57zmike: mareko: still waiting on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36296
12:58zmike: feels like by your own reasoning I should be able to merge this without any review at this point
14:42zmike: can I get an ack for https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37054
14:42zmike: jenatali maybe
14:43jenatali: Ack
14:44zmike: ty
14:54jenatali: My management apparently took some interest in llvmpipe vs WARP perf so I might actually have to figure out how to compare those soon
14:55zmike: uh oh
14:55zmike: WARP: I'm in danger
14:56jenatali: Heh I dunno tbh
14:56zmike: will be interesting to see the results for sure
14:57jenatali: Yeah, just need to figure out how to make it roughly apples to apples
15:00jenatali: Suggestions welcome
15:00zmike: well
15:01zmike: if I can promote a longstanding pain point of GL
15:01zmike: https://github.com/apitrace/apitrace/issues/351
15:01zmike: apitrace replay has insane overhead because the retrace program is very inefficient, but if apitrace could output the trace into compile-able c/c++ then it could be run directly
15:01zmike: which would be incredible for performance testing/benchmarking
15:05danylo: Btw, if benchmarking Mesa vs Mesa, almost everything needed for benchmarking is achieved by dumping u_trace perf data and comparing it. Though not applicable for Mesa vs non-Mesa drivers...
15:07jenatali: Yeah llvmpipe only supports GL/VK natively (AFAIK though maybe I could get d3d10umd to work?) and WARP only does D3D natively so there would need to be a mapping layer of some kind in the way
15:08zmike: dxvk ?
15:08jenatali: But there's so many aspects of perf that unless I'm testing for overhead in high call pattern cases then maybe it would be fine
15:08jenatali: Yeah DXVK or GLOn12 or something
15:58glehmann: great, looks like nir now has three structs to specify subgroup size
16:11glehmann: nir_lower_subgroups_options::subgroup_size is the sane but annoying one (because it's only local)
16:12glehmann: nir_shader_compiler_options::subgroup_size is kind of useless because options are meant to be immutable across the compilation process, but subgroup size isn't for all backend
16:12glehmann: it also only exists to work around gl frontend memes afaict, so it probably shouldn't have been merged in the first place
16:12glehmann: and what the hell even is shader_info::subgroup_size, and how does it work if it's not serialized/deserialized
16:14jenatali: Oof
16:30Company: with my limited testing with GTK, WARP was a lot worse than llvmpipe
16:31Company: not as bad as the Google software renderer, but definitely enough to warrant "I'm in danger" memes
16:32Company: though warp is a lot nicer for debugging
16:51jenatali: GTK = through GLOn12? or D3D native?
16:51jenatali: I'm aware that WARP's D3D12 paths are... suboptimal, compared to how it works through 11
17:08alyssa: glehmann: sorry. in my defence it was my last day O:)
17:11rodrigovivi: dim push is now giving me this: "Branch setup for the integration repo is borked"... I believe after drm-rust setup... anyone knows a quick fix?
19:30Company: jenatali: D3D12 native
19:31Company: jenatali: vs GL with llvmpipe (just copying the opengl32.dll over)
19:31Company: I don't remember if I tried lavapipe, but that would probably be very similar results
19:33Company: jenatali: did I ever tell you about https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/8520 ?
20:47Leftmost: Looked through gitlab labels and didn't see any, but if anyone knows of some NIR/SPIR-V/vtn-related tasks that serve as a good entrypoint to contribution in that area, would much appreciate it.