01:27 mareko: new freedreno flake? https://gitlab.freedesktop.org/mesa/mesa/-/jobs/36156146
04:06 alyssa: jenatali: At a hardware level, AGX images are write-only.
04:06 alyssa: Well, there's not really an image in the API sense
04:07 jenatali: Uh... were we talking about that?
04:07 alyssa: You can put a texture descriptor in memory (and then load / sample from it) and you can put a writeable image descriptor in memory (and then write to it) and if you want you can do both that alias each other
04:07 alyssa: I'm wondering whether it makes sense to EEE nir_lower_readonly_images_to_tex into handling that?
04:07 alyssa: or just do something in the backend/driver?
04:07 alyssa: that pass seems extremely OpenCL specific so idk
04:08 jenatali: We use it for Vulkan too
04:08 alyssa: so you do
04:08 alyssa: :eyes:
04:09 alyssa: there are a terrifying number of derefs in this pass, I only work on lowered I/O
04:09 alyssa:shrieks
04:09 jenatali: Up until recently in D3D world, images were write-only, and if you wanted to read from them, they had to go down the sampler approach
04:09 jenatali: It's probably not too bad to make it work on lowered I/O
04:09 alyssa: I mean I can probably run the pass before lowering I/O
04:10 jenatali: But also lowering read-write images to read-only and write-only seems like a different thing
04:10 jenatali: And then you can run this to lower the read-only side of it to a texture
04:10 alyssa: Yeah, that's fair
04:10 alyssa: I think I'm going to implement (only) bindless for API-level images
04:11 alyssa: so the bindless handle would be a GPU pointer to a texture descriptor followed by an image descriptor
04:11 jenatali: Makes sense. I get to go add a bindless mode to our backend soon
04:11 alyssa: => from the perspective of that pass, read/write images are also read-only images
04:12 jenatali: For EXT_descriptor_indexing
04:12 alyssa: Nod
04:12 jenatali: Well I'm happy to review any patches you wanna send my way for that pass
04:12 alyssa: sounds good
04:12 alyssa: Strictly AGX has something vaguely resembling a binding table that you can stick image descriptors in
04:12 alyssa: but it's less "binding table" and more "push constants that can only be used as bindless texture handles and nothing else"
04:13 alyssa: (To my knowledge there's no reason to use them over regular push constants, except for not running out of push constants :p)
04:14 alyssa: I use it in the GL driver for textures, IDK if I'm going to try to use it for anything in the VK driver
04:15 alyssa: so far I don't think ella-0's wired up textures yet in agxv so
04:17 alyssa: hm looks like that pass might be more work to adapt, and the lowered I/O version is probably a lot simpler anyway
04:22 jenatali: Yeah if you don't need types it'd be simpler
04:23 alyssa: screw types I'm a C program I can cast everything to void without any consequences whatsoever!f02jszidu84nhs743hfbffaweferf
04:23 alyssa: Segmentation fault.
04:24 jenatali: :P
07:09 Venemo: dcbaker: I took a look now, the patch seems to be already included in the 22.3 branch?
07:11 Venemo: dcbaker: the "ac/nir/ngg: Include culled primitives in query." seems fine, is there another you need help with backporting?
07:37 hakzsam: gfxstrand: sorry, I got distracted by other stuff but I was actually planning to look into it today
10:13 eric_engestrom: Venemo: I think you want 23.0, not 22.3
10:16 Venemo: eric_engestrom: the exact same backport should work on 23.0 too, I think
10:17 eric_engestrom: dcbaker: ^ you can take 18f0d33423b6635d0157 from 22.3
11:06 javierm: tzimmermann: any objections with landing lina's patch? https://patchwork.kernel.org/project/dri-devel/patch/20230205125124.2260-1-lina@asahilina.net/
11:06 javierm: tzimmermann: IMO the change is correct, even if some drivers may not use the API correctly as you pointed out
11:07 javierm: my only doubt was if there was a need for locking in drm_gem_shmem_free() as well, but both lina and danvet think that is not needed
11:09 tzimmermann: javierm, no objection from my side
11:10 javierm: tzimmermann: Ok, thanks. To drm-misc-next-fixes right ?
11:11 javierm: hmm, or just drm-misc-next
11:11 tzimmermann: javierm, drm-misc-fixes
11:12 tzimmermann: the patch has fixes tags for commits that are in upstream already. so drm-misc-fixes
11:12 tzimmermann: unless that creates too many conflicts
11:13 javierm: tzimmermann: yes, but since we are too late in the -rc cycle, I wondered if would be risky to push such change to drm-misc-fixes
11:13 javierm: and this race has been for some time, so it can surely wait for v6.3
11:14 tzimmermann: ok, makes sense
11:14 javierm: tzimmermann: cool, drm-misc-next then and will land in the next merge window
12:04 Lynne: why are dynamic uniform/storage not usable with vkGetDescriptorEXT?
12:16 glehmann: Lynne: https://github.com/KhronosGroup/Vulkan-Docs/blob/main/proposals/VK_EXT_descriptor_buffer.adoc#resolved-should-we-support-dynamic-buffers
12:23 Lynne: I thought that might've been the case
14:28 jfalempe: tzimmermann, may I push my ast fix to drm-misc-fixes ? (with the typo fixed).
14:50 tzimmermann: jfalempe, sure
14:50 jfalempe: tzimmermann, ok thanks.
15:49 kisak: RIP mesa on bionic. Mesa 22.3 will be the last compatible release series.
15:55 ishitatsuyuki: bionic is rip soon, anyway
15:56 eric_engestrom: kisak: why?
15:56 eric_engestrom: (but also, bionic is 5 years old already; I never understood that thing of not updating 99% of the system but wanting the latest version of some components...)
15:57 kisak: gcc lacks std::filesystem support for libclc to complete. There's an additional gcc-7 specific compiler (by age) snafu with intel
15:58 kisak: ^GCC 7.5.0
15:58 jenatali: Bionic always makes me think of Android libc now so I was confused for a minute
15:58 eric_engestrom: jenatali: same
15:59 kisak: there's a naming overlap? one off name conflict?
16:00 jenatali: https://android.googlesource.com/platform/bionic/
16:00 jenatali: Just a one-off conflict, not like Android's naming other things in a way that follows other stuff
16:05 kisak: with the rust dependencies, it makes it difficult to forecast how viable it is to backport mesa to any of the *buntus. At this point I'm thinking of letting tjaalton take the brunt of the packaing for kinetic and jammy, and turning it off in Focal. I have my doubts that anyone will adhere to what rust components are available through traditional distro packaging and expect only the latest
16:06 kisak: micro-version-bumped subcomponent.
16:11 ishitatsuyuki: Why is Rust problematic? Rust's backward ABI support has been excellent
16:12 karolherbst: is this becoming the "let's discuss rust every day" channel or what?
16:12 ishitatsuyuki: In general, Rust crates have few external C dependencies, and the standard library is built against the oldest glibc amongst supported in current distros
16:31 pal1000: dbaker: I nonimate af55e36d798b91b86795544aac2d9e3983cde207 for backport to 22.3. This commit made it into 23.0 prior to branchpoint. MSYS2 uses this for dozen build with clang. I forgot to nominate it sooner but better late than never.
16:34 kisak: pal1000: make a pull request on gitlab, also, dcbaker is not the release maintainer for 22.3, eric_engestrom is.
16:35 eric_engestrom: pal1000: kisak is right, but also for simple ones pinging us here is fine
16:36 eric_engestrom: I've just cherry-picked it and it applied cleanly so it's all good :)
16:36 kisak: ^the intent was so that there would be a record, but I see that it's already in staging
16:37 eric_engestrom: ah you're right, it's easier to find an MR that got the commit merged rather than the record being "someone asked for it on irc"
16:50 pal1000: I found this website that makes irc logs search easy: https://oftc.irclog.whitequark.org/dri-devel
16:57 kisak: ishitatsuyuki: it's not rust itself that's problematic, it's the implied expectation that all build environments use rustup to have the latest build dependencies, and that's not a thing with build farms and reproducable builds.
17:00 kisak: but specifically with mesa + rust + Ubuntu LTS, getting bindgen to the minimum requirements for rusticl requires that I walk a fairly sizable dependency tree which I know nothing about.
17:01 karolherbst: isn't bindgen already packaged for ubuntu?
17:03 kisak:takes a minute to fact check
17:04 MrCooper: FWIW, Debian stable has bindgen 0.55.1, testing has 0.60.1
17:04 kisak: available in 22.04 and newer, unpackaged in 18.04 and 20.04
17:05 kisak: so that was half my builds of 4 distro releases last I evaluated it.
17:07 karolherbst: I don't think anybody will expect rusticl to run on older distros out of the box anyway, especially as I don't think it will actually be production ready until later this year anyway
17:08 karolherbst: but it's a bit odd that it's not packaged for 20.04... oh well
17:08 karolherbst: maybe firefox doesn't need it
17:10 jenatali: karolherbst: Can I get a review/ack on !21168? I pinged you in the MR but since you're here figured I'd ask here too
17:11 ccr: there's always someone who is displeased when something does not compile on their RedHat 6.0 gcc 2.96, and they're going to flame about it on usenet news!
17:14 karolherbst: ahh finally moving to llvm-15 as well? :P
17:16 karolherbst: kisak: anyway.. there is no really strong reason to require bindgen-0.58. They just renamed their arguments and you can probably `sed` them to make it run on older bindgens
17:16 karolherbst: probably
17:18 karolherbst: jenatali: I don't know if we ever talked about it more in depth, but I was wondering if a thread pool for application callbacks (especially event status ones) _might_ be something to make the conversion tests not run forever... wondering if you ever played around with the idea of offloading those callbacks as well
17:23 jenatali: karolherbst: I haven't really touched CL much these days... too busy with GL and VK
17:23 karolherbst: fair
17:23 jenatali: Mainly VK
17:27 gfxstrand: hakzsam: Cool. Thanks!
17:56 jenatali: karolherbst: Should I take that r-b for the whole MR and just go ahead and land it?
18:05 lina: Explicit sync works on asahi now! ^^
18:06 lina: (Except mesa still needs code to keep track of BO lifetimes so right now it requires forcing a syncobj wait after each submit still... but this time in userspace ^^)
18:38 javierm: lina: nice
18:44 karolherbst: jenatali: maybe get another review for the nir bits? Though I think it's fine
18:45 jenatali: Sounds good, will wait for someone else to take a look
19:30 Kayden: so I've got a fossil dump, is there a good way to extract the SPIR-V from it, and ideally convert that to GLSL? (spirv-cross has some tools maybe?)
19:30 Kayden: would love to take a particular shader and cut it down to a piglit test
19:32 pendingchaos: "fossilize-disasm --target asm" then spirv-as+spirv-cross should work
19:33 dj-death: or --target glsl
19:33 dj-death: fossilize-disasm my.foz --output /tmp --target glsl
19:33 dj-death: Fossilize INFO: Dumping disassembly to: /tmp/7d32ffc11451b825.main.021b07ae14d0f300.vert
19:33 dj-death: it works :)
19:33 Kayden: \o/ thanks!
19:54 tjaalton: kisak: kinetic is dead to me, no mesa feature updates to it anymore
19:54 tjaalton: for lts backports stuff will get disabled most likely, if the deps are too far behind
19:57 HdkR: Focal is also dead for my project now, version of clang and libstdc++ is too old without the updates repo
19:58 HdkR: Sadly a year until it leaves general support but they have a new LTS already so I can't care too terribly much
20:11 kisak: fair enough