07:40 austriancoder: karolherbst: yes .. from what I can remember, I have both on new hardware. I can tell you more once I switch the focus to the new hw.
09:31 dschuermann: cwabbott: do you mind having a look at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41178#note_3446178 ?
09:50 emersion: sima, tzimmermann, airlied: so we had a question w/ tomba about push criteria. is a maintainer ACK required for pushing? or, if a patch is R-b'ed by a bunch of folks, can it just be pushed?
09:50 emersion: does aren't very clear about this: https://drm.pages.freedesktop.org/maintainer-tools/committer/committer-drm-misc.html
09:50 emersion: this is about drm-misc-next
09:51 tzimmermann: emersion, IMHO if someone with related expertise reviewed the patch, it can be merged
09:52 tzimmermann: but merging features into a driver without consulting the driver maintainer is a bit to much, I'd say
09:52 tzimmermann: for refactoring, it's different
09:52 emersion: the specific question was about core DRM changes
09:52 emersion: drm_fourcc.h additions
09:53 tzimmermann: someone with expertise should give an OK. that's my take on it. just because i happen to maintain drm-misc doesn't mean i know all of it
09:53 emersion: that was my understanding as well, thanks :)
09:56 dolphin: emersion: as last line of defence, maintainers can always revert patches before sending the -next PR (or -fixes, too)
09:56 emersion: yup
10:04 tomba: tzimmermann: emersion: alright, thanks. I'll then proceed with pushing the xilinx fourcc stuff to drm-misc, after I get a chance to do a final test round.
11:19 sima: emersion, yeah it's a judgement call situation, if there's screaming after you've pushed a patch it was not enough acks/reviews
11:21 sima: but there's also the countering policy that maintainers should not be able to block stuff unnecessarily, just because they're busy or might not exactly like the color choice for the bikeshed
11:21 sima: so essentially what tzimmermann also said
11:35 glehmann: can someone from intel review https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41101 ?
12:03 emersion: sima: thanks!
14:18 mlankhorst: pixelcluster: btw do you have any testcases for those eviction changes?
14:20 pixelcluster: mlankhorst: err only a very manual one, as in i boot up that kernel and launch vram-intensive games :D
14:20 pixelcluster: i can try writing some unit cases for that
14:22 mlankhorst: There's xe_cg_dmem, I believe airlied has a sysmem igt for amd you could adapt
14:44 valentine: anholt: we checked and both the DUT and the rack from the linked job are on 1000 Mbps connections so it doesn't look like a network issue
14:45 valentine: I also asked and we have all of the traces cached locally, so we only hit fd.o if the traces are updated
14:47 valentine: I guess it might be worth double checking whether g-t-p is properly using the lava cache, the piglit replayer displayed the download duration on failures, which made this super obvious
15:57 alyssa: glehmann: rb, thanks
15:59 alyssa: glehmann: incidentally that code should probably use nir_builder_alu_instr_finish_and_insert which would take care of the ffma float control but yeah
15:59 alyssa: and nir_def_replace
15:59 alyssa: but neither is your fualt
15:59 alyssa: or your problem
16:22 anholt: valentine: yeah, been looking into things from my end, too. network graph showed that we were getting 1000mb transfers, when transfers were happening (which is intermittently in a way that is pretty suspicious)
16:22 anholt: (e.g. https://anholt.pages.freedesktop.org/-/mesa/-/jobs/98422869/artifacts/results/graphs.html)
17:00 alyssa: anholt: "in terms of working on core compiler, virgl is definitely the lowest quality compiler backend"
17:00 alyssa: I don't know, we have some really low quality backends in tree
17:00 alyssa: I should know, I wrote one of them :P
17:00 anholt: alyssa: I thought you might argue that
17:00 alyssa: =D
17:00 arnd: https://lore.kernel.org/all/20260410205929.3914474-2-matthew.brost@intel.com/ causes a build regression in linux-next when hugepage support is turned off, from "#define HPAGE_PMD_SHIFT ({ BUILD_BUG(); 0; })". I haven't come up with a good fix though.
17:00 arnd: there was a similar bug a while ago, for which I did send a fix https://lore.kernel.org/all/20260318104637.1794243-1-arnd@kernel.org/, but this did not get picked up
17:00 anholt: but, at least in my experience with the "everything GL goes through NIR" stuff, virgl had panfrost beat handily.
17:01 karolherbst: alyssa: I'm sure codegen (the old nouveau one) is worse :P
17:01 anholt: it was so, so painful
17:02 karolherbst: heh
17:03 alyssa: understandable
18:40 karolherbst: pendingchaos: what are your plans in regards to https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33914 ? I'd be interested in that for NVK/NAK as I've seen compute shaders that would be helped by that. Just waiting on reviews or what's the status there?
18:42 karolherbst: though should probably run some stats on NVK, because we currently don't track shared memory usage...
18:45 pendingchaos: I think it's ready for review
18:45 pendingchaos: if it gets reviews, I'll try to respond to them and merge it when that's done
18:46 pendingchaos: I haven't been pushing for it to be reviewed since I don't have much evidence that it's useful
18:48 karolherbst: yeah.. I will add tracking and how it impacts occupancy for NVK first and then see if I also find games that would be helped. I know some compute workloads that do from an initial estimation.
19:08 glehmann: pendingchaos: does it work correctly with the zero initialized shared memory extension?
19:08 glehmann: afaict, that's currently cleared after lowering io, but that won't work with aliasing
19:09 pendingchaos: I assume not
19:09 pendingchaos: might depend on whether it requires variables are zero, or if it requires that workgroups don't share data
19:23 karolherbst: though should be easy to handle when it's lowered. Not so much when the clearing of shared memory is hw supported...
19:23 karolherbst: though on nvidia we got a native instruction to clear shared memory..
19:26 mareko: I wonder if that's how nvidia handles security
19:26 mareko: just clear LDS manually at the end of workgroups
19:27 karolherbst: probably. Shared memory is just split out L1 cache
19:28 karolherbst: could also flush the caches
19:28 mareko: flushing doesn't clear it though
19:28 karolherbst: not sure if there is a command for it to clear it
19:28 karolherbst: there is some invalidation going on when reconfiguring the data/shared mem split
19:28 mareko: yes, but I bet it doesn't clear
19:29 karolherbst: same tbh
19:29 mareko: flushes and invalidations just flip a per-cache-line bit, while clearing requiring issuing stores
19:30 mareko: the HW could issue clear instruction internally and that would do it, but it could be slow
19:30 karolherbst: the shared memory fill is a uniform workgroup op and is doing optimized slicing under the hood..
19:32 karolherbst: but yeah.. I don't think there is a command to do it, need to clear it in the compute shader
19:32 mareko: without the clear, sharing shared mem with the cache could expose previous cache content to new workgroups from different processes
19:33 karolherbst: I wouldn't be surprised if the context switching handling already takes care of that
19:33 karolherbst: or if there is a flag for it
19:34 karolherbst: they can instruction level preempt compute, and saving/restoring shared memory needs to be supported for that I figure