10:54 tomba: I pushed a fix, 3e9a1da270ddff449b1ad9eadc958f43bc204bd2 , to drm-misc-next, thinking that the original commit was not queued for the next merge window, but apparently it was. What's the proper thing to do here, push the fix to drm-misc-fixes too, and live with the duplicate commit? Or is it still drm-misc-next-fixes at this point of time...
13:48 phasta: I've got a new feature patch series here that makes an invisible bug visible. I also have a fix for that now. Would it still be the right thing to do to put the fix in misc-fixes and the feature in misc-next? tzimmermann airlied
13:50 phasta: because, if I understand the merge plan correctly, fix and feature would then only meet again in Linus's tree
13:51 tzimmermann: phasta, that feature series triggers a bug? and you also have a fix for that? you can put the fix into -misc-fixes. as soon as it reaches upstream, we can backmerge into drm-misc-next
13:51 tzimmermann: if the bug isn't sever, you can also put everything into drm-misc-next
13:52 phasta: tzimmermann: correct
13:52 phasta: https://lore.kernel.org/dri-devel/20260414133734.130115-3-phasta@kernel.org/
13:53 phasta: I feel it's probably better to go through misc-next. Otherwise people would see stack traces in misc-next for a while
13:54 tzimmermann: yeah, then do that. if the nouveau bug turns out to be critical, we can still cherry-pick as a last resort
13:54 phasta: OK, thank you
14:35 dschuermann: cwabbott: could you have a look at https://gitlab.freedesktop.org/mesa/mesa/-/jobs/97446938#L2336 ?
14:45 DottorLeo: Hi! @daniels about https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39551 it only affects X11 or even XWayland? Just to understand if something that uses Xwayland like games on Proton are affected
14:45 DottorLeo: Thanks!
14:48 jannau: phasta: is the mismatch between drm_sched_entity_flush() in the commit messages and drm_sched_entity_kill() in the change intended?
14:52 MrCooper: DottorLeo: Xwl in that MR stands for Xwayland
14:57 DottorLeo: MrCooper: the present timing extension that was merged while ago also need this MR to work on proton games?
14:58 MrCooper: when Proton uses an X display, yes, not when it uses Wayland natively though
15:02 phasta: jannau: oh. No it isn't. That's a relic, thx
15:12 DottorLeo: thanks!
17:22 anholt: valentine: should I expect lava runners to be really network-limited? what I'm seeing is that angle traces run fine on their own (data is pre-downloaded to the rootfs before the replay starts), but if I have downloads through the caching proxy going at the same time, the angle traces take so long to run that they time out sometimes. https://anholt.pages.freedesktop.org/-/mesa/-/jobs/97478972/artifacts/results/index.html success vs
17:22 anholt: https://anholt.pages.freedesktop.org/-/mesa/-/jobs/97407377/artifacts/results/index.html fail
17:26 anholt: this behavior isn't consistent, but I've seen it happen on both adl and raven, but not yet on a660.
18:02 valentine: anholt: not really expected, but I've had suspicions that one of the lava workers (https://lava.collabora.dev/scheduler/worker/lava-rack-sjic-0) has some network issues
18:03 valentine: DUTs on that worker can't boot Cuttlefish in time either (CF is super network limited), I've actually just reported the issue earlier today to our lab team
18:03 valentine: the failing Raven job you linked was also running on that worker, so pretty sure it's the same issue
18:04 valentine: I'm more surprised about the adl runner you mentioned though, since that's on a different worker
18:04 valentine: if you hit more instances of this please send over the job links and we can take a closer look.
18:06 anholt: I'll try to compile my failing jobs list in a sec
19:14 anholt: valentine: https://gitlab.freedesktop.org/mesa/mesa/-/work_items/15284
19:34 valentine: thanks, in both cases it's the same adl runner failing, so that's something we can look into
20:38 asrivats: hi i am looking into what it would take to make zink+NVK the default GL driver on pre-turing NVIDIA GPUs (Maxwell/Pascal/Volta). The main blocker I've found is drawIndirectCount - its Turing+ because of the mme_tu104_read_fofoed(). The old nouveau GL driver handles this on pre-turing by using IB entries to DMA the count and draw params into pushbuffer for MME. NVK has nvk_cmd_buffer_push_indirect() which does the same thing. will this be a good
20:38 asrivats: place to start? are there any other blockers I shold know about
21:39 cwabbott: dschuermann: will be fixed by !40961
21:39 cwabbott: was a recent regression
21:48 alyssa: asrivats: does any opengl actually use drawIndirectCount?
22:18 karolherbst: alyssa: I think threaded context uses it
22:18 karolherbst: as an optimization
22:19 alyssa: multiDrawIndirect is different than drawIndirectCount
22:19 karolherbst: ohhh... right..
22:19 alyssa: dIC is the weird one
22:19 alyssa: mDI is fine
22:19 karolherbst: right...
22:19 karolherbst: asrivats: might be better to also join #nouveau
23:15 asrivats: @karolherbst, does nouveau need an invite? i am unable to join
23:27 karolherbst: asrivats: huh.. normally not, what error are you seeing?