00:04 mriesch: hm i guesshttps://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/tiny/repaper.c#L512 could serve as blueprint for that
06:01 Company: hrm, either I am wrong or v3dv is wrong
06:02 Company: I put a textures[N_TEXTURES_SPECIALIZATION_CONSTANT] into my shader
06:02 Company: and set it to the max number of supported textures by the hardware
06:03 Company: and then I use a large if/else ladder to index it
06:03 Company: if (id < N_TEXTURES_SPECIALIZATION_CONSTANT && id == 3)
06:03 Company: return texture (textures[3], pos);
06:03 Company: else if (id < N_TEXTURES_SPECIALIZATION_CONSTANT && id == 4)
06:03 Company: ...
06:04 Company: and now I blew this up to 32 entires - but the rpi has 16 texture units
06:05 Company: and it seems to implode because it looks like it's trying to lower the texture (textures[16..31]) calls
06:05 Company: which should be dead code because the if (id < N_TEXTURES_SPECIALIZATION_CONSTANT) doesn't trigger
06:06 Company: and then dead code elimination should get rid of it
06:06 Company: is that a bug in v3dv or in my interpretation of how specialization constants work?
08:42 pq: Company, how does 'id' get its value in the shader sources?
08:45 javierm: mriesch: https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/solomon could also be an example for what you want to achieve
08:46 Company: pq: input variable
08:46 Company: so it's dynamically uniform, but not constant
08:48 pq: but if it's uniform and not constant at shader compile time, then how could the shader compiler know it can do that dead code elimination?
08:50 pq: maybe you need a #define'd constant for the max id instead of using id itself for the dead code thing?
08:52 Company: it's Vulkan, so I can't #define
08:52 Company: all I can do is use specialization constants
08:52 pq: well, any way you set compile time constants there
08:52 Company: that's why I'm asking about specialization constants
08:53 Company: and their semantics
08:53 pq: ok
08:53 Company: if it turns out I need to know at spirv compile time, I'm a bit screwed, because I don't have a builtin spirv compiler
08:54 Company: I compile the spirv at build time
09:00 dj-death: Company: the way it's implemented right now is that specilization constants are just replaced with constants while parsing spirv if I remember correctly
09:00 dj-death: Company: so it's a bit surprising that v3dv won't remove the dead branches
09:01 Company: maybe it does the lowering before dead code elimination
09:01 dj-death: Company: unfortunately that's stuff you need to debug looking at NIR optimization passes
09:01 Company: but I'm also curious about what *should* happen
09:02 Company: doesn't help if I fix v3dv and then other drivers have the same issue, too
09:02 dj-death: Company: possible... but really DCE should run way before stuff gets lowered
09:02 Company: particularly closed ones
09:03 dj-death: maybe it's more subtle
09:03 dj-death: it could be that the driver relies on the variable array size
09:03 dj-death: code might be get culled, but the array size is not shrinked and ...
09:03 Company: hehe
09:04 Company: first I want to figure out what *should* happen
09:04 dj-death: it's implementation specific at this point
09:05 Company: I was hoping some spec says something about it
09:10 Company: because otherwise I'd just limit myself to 16 texture units because that's required by the spec
09:11 Company: and then I don't need to play around with specializations there
09:52 wv: I'm still on imx53/mesa/freedreno. Investigating why I have some color shift when drawing pixels https://pasteboard.co/0pX8YFTrtrGh.png
09:53 wv: But while investigating, we stumbled upon something strange/interesting. It appears that the last column and last row of a surface are always black
09:53 wv: Whether that's on weston surfaces, or just via plain drm
09:54 wv: but only on imx53. We verified on imx6 too, and the issue seems not to be apparent there (at first sight)
09:58 tursulin: mlankhorst, mripard, tzimmermann: could you merge one single patch to drm-misc-next please? https://lists.freedesktop.org/archives/dri-devel/2023-November/429029.html is the patch in question
10:37 hakzsam: anyone knows if more 23.2 releases will happen?
10:37 cmichael: eric_engestrom, ^
10:42 mripard: tursulin: I'm on it
10:42 mripard: you don't have commit access to drm-misc?
10:42 mriesch: javierm: cool, thanks for the pointer
11:20 tursulin: mripard: thanks for merging it! no, I don't have commit access.
11:27 dj-death: jenatali: any bad experience with header files in clc?
11:31 dj-death: jenatali: I have this #include "libanv_shaders.h"
11:31 dj-death: jenatali: and somehow clc is failing with this message :
11:31 dj-death: error: error reading 'libanv_shaders'
11:32 dj-death: weirdly missing the .h suffix
11:35 Company: dj-death: your idea of looking at nir instructions was great, thx
11:35 Company: not because it answered my question, but because it showed me a subtle bug in my code that lead to the code not being dead and therefor not being eliminated
11:35 dj-death: Company: oh nice
11:36 Company: so Mesa does eliminate the code just fine now
11:36 Company: I'd still like to know if the spec requires it though
11:38 dj-death: I don't think so
11:44 alyssa: dj-death: libanv_shaders.h eh?
11:45 dj-death: alyssa: yeah, giving it a try
11:45 dj-death: alyssa: no clue as to why the GRL shaders just work and this one fails
11:45 alyssa: wheeee.
11:45 alyssa: good luck ^^
11:45 alyssa: I didn't have any #include issues fwiw,
11:46 alyssa: but why are you including the generated clc output from the cl code itself?
11:46 dj-death: yeah, I have no idea...
11:46 alyssa: that seems.. circular..
11:46 dj-death: alyssa: I'm just include a shared header between the host/gpu stuff
11:46 alyssa: libagx_shaders.h is generated at buildtime
11:46 alyssa: so header name collision at the very least?
11:47 dj-death: I'm generating libanv_shaders_code.h
11:47 alyssa: ah
11:47 dj-death: like clang is crapping itself double freeing data
11:47 dj-death: wtf...
11:47 alyssa: dj-death: are you setting include paths properly from meson.build?
11:47 dj-death: yeah
11:48 alyssa: alright..
11:48 dj-death: fun fact, if I move the include to #include "plop.h"
11:48 dj-death: it'll report an error
11:48 dj-death: file not found
11:51 alyssa: ?!
11:51 dj-death: alyssa: https://paste.debian.net/1297314/
11:53 alyssa: karolherbst: ^^
11:53 karolherbst: pain
11:54 karolherbst: let's see...
11:55 dj-death: why am I not running into this with GRL??
11:55 karolherbst: kinda looks like an llvm bug
11:55 karolherbst: jenatali might have some ideas here ^^
11:56 alyssa: dj-death: dumb but consider renaming the .h :p
11:56 karolherbst: what version of llvm is that?
11:57 karolherbst: anyway.. we just call unique_ptr::release on memory and then it's up to LLVM to manage that
11:57 karolherbst: and it seems like it fails to do that
11:58 karolherbst: I haven't seen an error like that with llvm-16
11:58 karolherbst: and llvm-15 is EoL
11:58 karolherbst: so you might want to file a bug against your distribution
11:58 dj-death: oh...
11:59 dj-death: this is something to do with --prefix apparently
11:59 karolherbst: anyway.. you need to specify all include paths explicitly
11:59 dj-death: yeah I did
12:00 karolherbst: sooo
12:01 karolherbst: generally in CL it's advised to provide all files as buffers in RAM, so scanning for real files could cause issues as that's not well tested
12:01 alyssa: wfm.
12:01 dj-death: yeah forget it
12:02 dj-death: it's all about me failing to parse the -- I think
12:09 dj-death: 232M /home/djdeath/src/mesa-src/mesa-test/build/src/intel/compiler/intel_clc
12:09 dj-death: alyssa: is it as bad for you?
12:10 dj-death: alright file generated
12:10 dj-death: nice
12:10 dj-death: lunch is deserved.
12:21 mripard: tursulin: you should ask for one, you have done far more work than required :)
12:48 alyssa: dj-death: no
12:48 alyssa: alyssa@blossom:~$ du -h /home/alyssa/mesa/build/src/asahi/clc/asahi_clc
12:48 alyssa: 17M /home/alyssa/mesa/build/src/asahi/clc/asahi_clc
12:57 Company: success - finally got Vulkan running on the rpi. Though it does seem to fall over if the process wants to use both GL (with GStreamer) and Vulkan (with GTK)
13:05 kusma: Does anyone know what to do when the CI has decided that the hardware jobs aren't needed (...but they totally are?) https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25968#note_2156549
13:05 biju: jmondi: Could you please take a look at https://lore.kernel.org/dri-devel/20231102150744.28736-1-biju.das.jz@bp.renesas.com/T/#m0f70c6a7b678e8559c402fcb1914574758477ec
13:06 alyssa: kusma: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26060
13:07 alyssa: perhaps relevant
13:07 kusma: Oooh
13:07 kusma: Yeah, that's probably it. Thanks! I totally thought this was due to the source-deps rules
13:08 kusma: Of course, the "upgrade expected to occur until"-window was way passed even when the MR was merged :P
13:10 kusma: Oh, I get it. This one restores it. It's very Monday for me, it seems ;)
14:27 dj-death: alyssa: maybe you have release build
14:28 alyssa: dj-death: don't think so
14:44 austriancoder: ci_run_n_monitor.sh aborts with KeyError: 'rustfmt' - I am the only one seeing this on current main?
15:02 DavidHeidelberg: austriancoder: I'm not in a front of computer, but gallo[m] MR should solve that (it's a occasional issue)
15:03 austriancoder: DavidHeidelberg: thx
15:03 DavidHeidelberg: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25940
15:13 gfxstrand: Moment of truth... Do all the containers rebuild properly and does NVK pass CI?
15:16 gfxstrand: Ugh... Still not in pypi. I thought it was. My brain must have done an ADHD and got things screwed up.
15:21 gfxstrand: daniels: How horrible would it be to point pip at a git sha for the container build?
15:21 gfxstrand: Or a git tag, rather.
15:21 gfxstrand: (But I'm fine with a SHA if that's better)
15:30 daniels: gfxstrand: that's totally fine if it works - we already do it for e.g. ci-fairy
15:31 daniels: just stick a comment above it saying 'this is 1.2rc2ish'?
15:33 gfxstrand: daniels: Ok, cool
15:58 gfxstrand: Time to try again...
16:08 jfalempe: tzimmermann, after running some profiling on a server with aspeed, there are a lot of page faults. When I run glxgears, there are 100k pgfault/s, and 70% of the CPU is in this function: https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_gem_shmem_helper.c#L509
16:09 jfalempe: curiously, it's only when running Wayland, with Xorg, there are almost no page fault.
16:11 tzimmermann: jfalempe, shmem does unmap pages ASAP
16:12 tzimmermann: we'd need a shrinker to delay that
16:12 tzimmermann: i once did a prototype, and I think there was a patchset on dri-devel to implement shrinker support for shmem helpers
16:13 tzimmermann: on the difference between xorg and others, IDK
16:15 jfalempe: tzimmermann, that means a kind of delayed unmap ?
16:16 tzimmermann: jfalempe, exactly. we keep pages mapped . linux will call the shrinker callback if it needs free memory. then we unmap.
16:16 tzimmermann: jfalempe, that looks like the patchset: https://patchwork.freedesktop.org/series/102550/
16:18 jfalempe: tzimmermann, ok thanks, that looks a big task. I was also wondering if it's possible to map the whole buffer instead of 4k page at a time.
16:32 gfxstrand: Well, the container built.
16:44 gfxstrand: Ugh... the meson upgrade breaks the rusticl build
16:44 gfxstrand: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/51253570
16:44 gfxstrand: karolherbst, dcbaker ^^
16:48 gfxstrand: Looks like link_with isn't causing a dep to build
16:51 alyssa: https://rosenzweig.io/uff.txt
16:51 alyssa: karolherbst: dj-death: oh no.
16:51 karolherbst: classic clang moments
16:52 karolherbst: alyssa: `-I/home/alyssa/mesa/build/src/asahi/lib/.[`?
16:52 karolherbst: why the .[?
16:52 alyssa: uhh
16:52 karolherbst: that one also a bit sus: -I/home/alyssa/mesa/src/asahi/lib/.
16:52 alyssa: karolherbst: because i'm bad at typing
16:52 karolherbst: :(
16:53 alyssa: ok with that fixed it finds the file
16:53 alyssa: but with valgrind spewing errors deep in llvm.
16:57 gfxstrand: ugh... libgallium.a exists so meson is building it. It's just not linking in properly?!?
17:01 karolherbst: alyssa: wanna fix llvm?
17:01 karolherbst: :P
17:04 gfxstrand: It has a `-l static:+verbatim=src/gallium/auxiliary/libgallium.a` flag
17:08 karolherbst: odd
17:08 gfxstrand: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/51253570
17:08 gfxstrand: Yeah, it's really strange. The file is right there.
17:09 karolherbst: yeah...
17:09 karolherbst: seems that way
17:13 gfxstrand: IDK why NAK is okay but rusticl isn't
17:13 karolherbst: maybe something with updated meson?
17:14 karolherbst: never seen that error, so no idea
17:16 gfxstrand: Yeah, it's definitely something with the meson update
17:17 gfxstrand: Let's look at 1.2.1 does
17:22 gfxstrand: Ugh... unresolved import `libc_rust_gen` with mesa/main and meson 1.2.1
17:22 karolherbst: pain
17:22 karolherbst: I think 1.2.1 was also broken?
17:22 karolherbst: I'm on 1.2.3
17:29 gfxstrand: Yeah, 1.2.3 doesn't work either
17:29 karolherbst: mhhh
17:29 karolherbst: odd
17:29 karolherbst: `unresolved import `libc_rust_gen`` that sometimes happen if the lib was built with an older rust compiler
17:30 karolherbst: tried a clean build?
17:30 gfxstrand: But I just torched my build dir
17:30 gfxstrand: Like rm -r _build
17:30 karolherbst: mhhh
17:30 karolherbst: pain
17:30 karolherbst: mind pasting the entire log?
17:32 gfxstrand: Oh, now it built. :rolling_eyes:
17:32 gfxstrand: Okay, I see what's happening.
17:33 gfxstrand: Meson started adding paths for link things
17:33 gfxstrand: So the working version does `-l static=gallium -L src/gallium/auxiliary` but the new does `-l static=src/gallium/auxiliary -L src/gallium/auxiliary`
17:41 gfxstrand: https://github.com/mesonbuild/meson/issues/12484
17:41 gfxstrand: Guess we get to wait for more meson bugs to be fixed. :weary:
17:48 ccr: :/
20:42 dj-death: is there a way to tell a NIR variable represent both a sampler & texture?
20:45 gfxstrand: Not easily, no.
20:46 gfxstrand: I've tried to split that multiple times but failed to get it totally clean.
20:47 dj-death: gfxstrand: hmm :(
20:48 dj-death: gfxstrand: maybe you know a way to tell from NIR shader whether a particular binding will be used a image-only/sampler-only/image-sampler-combined?
20:48 gfxstrand: dj-death: You can chase all the derefs.
20:48 dj-death: gfxstrand: I thought I figured that out a while ago, but I must have forgotten
20:48 dj-death: ah okay
20:48 gfxstrand: dj-death: Even there, though, Vulkan lets you alias so you aren't just looking for NIR variables, you're looking for bindings.
20:48 dj-death: for buffers it's easier
20:50 dj-death: gfxstrand: so if a shader uses only a binding as a sampler, can you assume that maps exactly to a SAMPLER type decriptor?
20:50 gfxstrand: Nope
20:50 dj-death: dammit :)
20:50 gfxstrand: Could still be a combined image/sampler and the image part is unused
20:51 dj-death: alright then
20:51 dj-death: oh
20:52 dj-death: so I might be looking at a CTS bug then
20:52 gfxstrand: combined image/samplers were a mistake, IMO
20:52 dj-death: because if the descriptor is mutable and includes a COMBINED version
20:52 dj-death: then it has to write it as combined
20:53 dj-death: or there is an issue with descriptor buffers
20:54 dj-death: if you create a layout with combined, write it as sampler
20:54 dj-death: how is the implementation supposed to know where to find the data?
20:55 dj-death: because the layout has space for image+sampler
20:55 dj-death: but the vkGetDescriptorEXT() doesn't have the information about the layout
20:55 dj-death: so it doesn't know that there is an additional offset for where to put the sampler
20:56 gfxstrand: is combined allowed with descriptor buffer?
20:58 dj-death: gfxstrand: I have a comment in Anv that says no :)
20:58 dj-death: gfxstrand: but I can't find the reference in the spec
20:58 dj-death: and validation layers don't scream
20:58 gfxstrand: Ah, the eternal Vulkan spec issue...
20:59 dj-death: I think it's allowed
20:59 dj-death: proposals/VK_EXT_descriptor_buffer.adoc:Buffers containing `VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER` descriptors must have been created with both
21:00 dj-death: I guess I'm off to write a spec bug
21:01 gfxstrand: Yeah, they're definitely allowed
21:01 gfxstrand: There's this weird array property that affects them.
21:02 dj-death: I don't know that Anv can do combined-image-sampler with mutable and descriptor buffers
21:02 dj-death: I mean the information to put/fetch the data in the right place just isn't there
22:02 alyssa: i heard you like ci speedups https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26084