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
12:19 tzimmermann: but if you read my replies, we don't have to store dma_buf_ops in drm_driver. and as a side effect, we can halt other drivers (amdgpu) in the long run
12:22 tzimmermann: bbrezillion, i just looked through your replies. maybe we can have a callback in drm_driver. next to gem_prime_import, there could be gem_prime_is_exporter that takes the dev and dma_buf
12:24 tzimmermann: in drm_gem_is_prime_exported_dma_buf: if the callback has been set, use it. otherwise fall back to the current test
12:33 bbrezillon: tzimmermann: sure, I'd be fine with this sort of callback, but let me point the irony here, that's a buffer related callback ;p
12:34 tzimmermann: bbrezillion, i know. this really belongs into the dma-buf api. but that's quite some effort AFAIK. so i'd prefer the callback over the plain pointer
12:34 bbrezillon: if you tell me you're happy with a ::is_prime_exported_dma_buf() callback at the driver, I can give it a try
12:35 tzimmermann: bbrezillion, but couldn't you make a version of drm_gem_is_prime_exported_dma_buf() that takes the dma_buf_ops as arguemnt?
12:35 bbrezillon: sure, I can
12:35 Lynne: zzoon_: anv's h264 decoding has been pretty broken for a while now
12:36 bbrezillon: but that doesn't help with code sharing, does it?
12:36 Lynne: fails to decode P-frames occasionally
12:38 tzimmermann: bbrezillion, amdgpu copied the import helper and replaced the test with their own thing. https://elixir.bootlin.com/linux/v6.17.9/source/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c#L512
12:39 tzimmermann: if we'd have a fully generic version of that test, we could make the whole self import transparent, i guess
12:39 bbrezillon: and the fully generic version is exactly what we're discussing, isn't it?
12:40 tzimmermann: it is. for now, let's go with the callback in drm_driver.
12:42 tzimmermann: i think we should also try to add such a callback to dma_buf_ops and a later step.
12:43 bbrezillon: if what you were suggesting was to have a drm_gem_prime_import_with_ops(), that's only part of the solution because I remember seing these is_this_my_dma_buf() tests in other places
12:44 bbrezillon: so all of a sudden, we have to identify and extend those path to take extra arguments
12:46 tzimmermann: this is what i pointed to in the amdgpu driver. and amdgpu has a pretty ugly solution to the setting the dma ops. they fix it up afterwards: https://elixir.bootlin.com/linux/v6.17.9/source/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c#L365
12:47 tzimmermann: what i suggest is to add drm_driver.gem_prime is importer(dev, dma_buf). it takes the dev and dma buf and returns a boolean
12:47 tzimmermann: drivers can choose to implement it if they set their own dma-buf ops
12:47 tzimmermann: and then do an internal test
12:48 tzimmermann: gem_prime_import does not change at all
12:49 bbrezillon: yep, and I'm good with this approach, but it felt like you were not completely sold on the solution you were proposing
12:50 bbrezillon: the name of the callback is a bit odd
12:51 bbrezillon: but I'm happy with the general idea
12:51 tzimmermann: odd?
12:51 tzimmermann: sorry, 'gem_prime_dev_is_exporter' is what i meant
12:52 bbrezillon: yep, sounds better
12:52 tzimmermann: i'm a bit in a hurry TBH
13:46 YuGiOhJCJ: hello, when I build mesa-25.2.7 I get this error message: "Run-time dependency llvmspirvlib found: NO (tried pkgconfig and cmake)", it's weird because I built and installed from source a brand new llvm-18.1.8, any idea how to fix this?
13:50 K900: That is not brand new
13:50 K900: And llvmspirvlib is part of spirv-llvm-translator
13:52 YuGiOhJCJ: lol indeed llvm-18.1.8 is from 2024 it's not brand new, still better than my old 13.0.0
13:53 YuGiOhJCJ: ok thanks I will install this thing: https://github.com/KhronosGroup/SPIRV-LLVM-Translator/releases
14:54 YuGiOhJCJ: hmm stuck on building SPIRV-Tools-2024.4, I get this error message: "SPIRV-Tools-2024.4/build/core.insts-unified1.inc:511:194: error: ‘SPV_OPERAND_TYPE_OPTIONAL_TENSOR_OPERANDS’ was not declared in this scope;"
14:55 K900: Why are you building ancient spirv-tools
14:55 YuGiOhJCJ: because I have an ancient version of llvm
14:56 YuGiOhJCJ: I have llvm-18.1.8, so I selected SPIRV-LLVM-Translator-18.1.18, that gives me a version of SPIRV-Headers
14:56 YuGiOhJCJ: I installed all these things
14:56 YuGiOhJCJ: on my system
14:56 YuGiOhJCJ: and now I try to install SPIRV-Tools-2024.4
14:57 YuGiOhJCJ: in fact SPIRV-Tools-2025.4 tells me that I have a too ancient version of cmake
14:57 YuGiOhJCJ: that's why
14:57 YuGiOhJCJ: I can build a more recent version of cmake but I am a bit lazy :)
14:58 K900: Uhh
14:58 K900: Why are you on an ancient system
14:58 K900: And what are you doing with that
14:58 K900: And also why
14:59 YuGiOhJCJ: hmm I don't know it's easier to not upgrade so I don't upgrade until I am forced to do it
15:00 K900: Well maybe you can build a Mesa from the appropriate time too
15:00 YuGiOhJCJ: I juste need a recent version of mesa because I will have an AMD RX 9060 XT soon
15:00 K900: If you're going there
15:00 YuGiOhJCJ: *just
15:00 K900: Are you on self-built LFS or something
15:00 YuGiOhJCJ: so I install all the dependencies
15:00 K900: Why are you just not getting all of those things from your distro
15:00 YuGiOhJCJ: because I like open source
15:00 YuGiOhJCJ: I build all my OS from source
15:00 K900: Then run Gentoo or something?
15:01 YuGiOhJCJ: well I like to start with binaries
15:01 YuGiOhJCJ: then upgrade with source
15:01 K900: Then you can build your OS from source, but the actual build instructions will be maintained by people that know what they're doing
15:01 K900: So you're just "sudo make install"-ing shit into a binary based distro?
15:01 K900: Yeah that's an absolutely awful idea
15:01 K900: And I'm surprised your system hasn't exploded yet
15:01 YuGiOhJCJ: yeah but I do it well by building packets
15:02 YuGiOhJCJ: then I install the packets
15:02 YuGiOhJCJ: everything from source code
15:02 K900: Seriously please just get stuff from your distro if you're running a normal distro
15:02 K900: And if you really want to build everything from source, run Gentoo or NixOS or something
15:02 YuGiOhJCJ: man why not an hybrid version of that?
15:03 K900: Because frankly you do not understand how the pieces fit together
15:03 K900: Well enough to maintain what's effectively your own distribution
15:03 YuGiOhJCJ: it's too much time consuming
15:03 YuGiOhJCJ: I prefer an hybrid version like I do
15:04 K900: Building everything from source? You can have prebuilt binaries on Gentoo, or on NixOS for that matter
15:04 YuGiOhJCJ: only upgrade from source when necessary
15:04 YuGiOhJCJ: but start the base install from binaries
15:05 K900: Look I'm not going to debate you
15:05 K900: Either you upgrade your abomination to run a modern LLVM and Vulkan SDK versions
15:06 K900: Or just run something normal
15:06 YuGiOhJCJ: I will take the first option
15:06 K900: That's just the ground truth
15:06 YuGiOhJCJ: I am not sure why I've not selected the last llvm version
15:08 YuGiOhJCJ: 21.1.6 should be good
15:10 YuGiOhJCJ: but to go back to the error message, any idea what is this "SPV_OPERAND_TYPE_OPTIONAL_TENSOR_OPERANDS"?
15:10 YuGiOhJCJ: is it supposed to be part of SPIRV-Headers?
15:10 K900: You're using mismatched versions of spirv-headers and spirv-tools, most likely
15:10 K900: Use the latest vulkan-sdk-1.x.y tag
15:12 kisak: YuGiOhJCJ: if you just need a backup plan to get RDNA4 up and running, mesa 25.0 + llvm 15 will get you there.
15:13 YuGiOhJCJ: kisak, ok but mesa 25.0 can't be built without a vulkan-sdk installed
15:14 YuGiOhJCJ: that's why I am trying to install all these Vulkan things
15:15 kisak: indeed, I mentioned it so you know there's a bit of wiggle room if you find an older dependency requirement that you can work with.
15:17 YuGiOhJCJ: ok maybe I can keep my llvm-18.1.8 installed then
15:17 YuGiOhJCJ: it's already modern enough
15:19 YuGiOhJCJ: I just noticed I've installed this on the past on my system: vulkan-headers-1.3.262, vulkan-loader-1.3.262 and vulkan-tools-1.3.262
15:19 YuGiOhJCJ: this is probably a bit old
15:20 YuGiOhJCJ: but I've not installed thos spirv things in the past
15:29 YuGiOhJCJ: oh yeah nice here we can see the list of all the SDK Components: https://vulkan.lunarg.com/doc/sdk/1.4.328.1/linux/release_notes.html
15:29 YuGiOhJCJ: I guess I don't need all of them