00:32 airlied: don't suppose someone with a good shaderdb maybe on radv could test https://paste.centos.org/view/raw/00177cdb
00:33 airlied: it might just be my pathalogical shader I'm helping
02:10 anholt_: airlied: pull down shader-db-private, and you can have a massive db too.
02:11 anholt_: https://gitlab.freedesktop.org/gfx-ci/private-access/shader-db-private
02:13 airlied: indeed guess I should just go do it :-)
02:34 mareko: austriancoder: what change?
03:03 mareko: austriancoder: that should only change when and how often TC is flushed, there should be no change if you don't use the renderpass info
03:04 mareko: no effect I mean
03:16 airlied: hmm lots of iadd ( iand x & mask1, iand x & mask2) and mask1 and mask2 are disjoint
09:18 austriancoder: mareko: I would say the same.. but the two tests went from crash -> pass with that simple change
09:25 K900: Hey folks, does anyone understand what's going on with https://gitlab.freedesktop.org/mesa/mesa/-/issues/14309 ? We're about to ship a NixOS release and this is a problem...
09:55 pq: Congrats on landing the KMS pre-blend color pipelines and UAPI!
10:08 glehmann: airlied: is this about tensor loads?
10:08 glehmann: I wonder if exposing it even make sense, I kind of expect garbage perf
10:19 austriancoder: should dEQP-GLES31.functional.blend_equation_advanced.basic.multiply pass on llvmpipe?
10:41 airlied: glehmann: yeah tensorloads, the perf probably isn't as bad as the compile times :-P
10:58 bbrezillon: tzimmermann: can you remind me what the problem is with having GEM/buffer related info at the drm_driver level?
10:59 bbrezillon: BTW, I see two other options to solve the problem with resorting to drm_driver field additions (which, as I said, I'm not really sure I see the problem with)
11:00 bbrezillon: 1. Add a drm_device_set_dma_ops() helper storing the default dma_buf_ops for a device in some new drm_device::dmabuf_ops field
11:01 bbrezillon: 2. Add a struct device *dev to dma_buf, so we don't have to test the dma_buf::ops against a driver-private definition to check if the buffer comes from us
11:02 bbrezillon: *without resorting to
11:05 bbrezillon: honestly, at this point it feels more like a philosophical "I'd rather have code duplicated than shared if it touches a single thing in the core" issue, and I'm not sure I want to fight that battle, so I'll probably go and duplicate the prime boiler plate plus shmem utils I added
11:18 phasta: I always get bounce messages from the linaro-mm-sig-bounces mailing list. Can something be done about that?
11:51 daniels: airlied: colorops make it into your 6.19 tree right?
11:52 daniels: orrr, hmm, I guess we need another drm-misc-next pull for that to happen. mlankhorst were you planning on doing that?
12:15 tzimmermann: bbrezillon, modifying the dma_buf itself is hard. it's not welcome AFAIK
12:16 tzimmermann: brezillon, there used to be plenty of ops in drm_drivers that belonged into drm_gem_object funcs. the result was fairly chaotic. it's good that his has been cleaned up
12:18 tzimmermann: it doesn't belong there from a design POV.
12:18 tzimmermann: and a driver might use different instances of dma_buf_ops.
12:18 tzimmermann: we should not assume there's only one