07:40austriancoder: 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:31dschuermann: cwabbott: do you mind having a look at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41178#note_3446178 ?
09:50emersion: 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:50emersion: does aren't very clear about this: https://drm.pages.freedesktop.org/maintainer-tools/committer/committer-drm-misc.html 09:50emersion: this is about drm-misc-next
09:51tzimmermann: emersion, IMHO if someone with related expertise reviewed the patch, it can be merged
09:52tzimmermann: but merging features into a driver without consulting the driver maintainer is a bit to much, I'd say
09:52tzimmermann: for refactoring, it's different
09:52emersion: the specific question was about core DRM changes
09:52emersion: drm_fourcc.h additions
09:53tzimmermann: 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:53emersion: that was my understanding as well, thanks :)
09:56dolphin: emersion: as last line of defence, maintainers can always revert patches before sending the -next PR (or -fixes, too)
09:56emersion: yup
10:04tomba: 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:19sima: 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:21sima: 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:21sima: so essentially what tzimmermann also said
11:35glehmann: can someone from intel review https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41101 ?
12:03emersion: sima: thanks!
14:18mlankhorst: pixelcluster: btw do you have any testcases for those eviction changes?
14:20pixelcluster: mlankhorst: err only a very manual one, as in i boot up that kernel and launch vram-intensive games :D
14:20pixelcluster: i can try writing some unit cases for that
14:22mlankhorst: There's xe_cg_dmem, I believe airlied has a sysmem igt for amd you could adapt
14:44valentine: 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:45valentine: I also asked and we have all of the traces cached locally, so we only hit fd.o if the traces are updated
14:47valentine: 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:57alyssa: glehmann: rb, thanks
15:59alyssa: 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:59alyssa: and nir_def_replace
15:59alyssa: but neither is your fualt
15:59alyssa: or your problem
16:22anholt: 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:22anholt: (e.g. https://anholt.pages.freedesktop.org/-/mesa/-/jobs/98422869/artifacts/results/graphs.html) 17:00alyssa: anholt: "in terms of working on core compiler, virgl is definitely the lowest quality compiler backend"
17:00alyssa: I don't know, we have some really low quality backends in tree
17:00alyssa: I should know, I wrote one of them :P
17:00anholt: alyssa: I thought you might argue that
17:00alyssa: =D
17:00arnd: 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:00arnd: 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:00anholt: but, at least in my experience with the "everything GL goes through NIR" stuff, virgl had panfrost beat handily.
17:01karolherbst: alyssa: I'm sure codegen (the old nouveau one) is worse :P
17:01anholt: it was so, so painful
17:02karolherbst: heh
17:03alyssa: understandable