01:18 gfxstrand[d]: Maybe if Kronos doesn't blow up and can get around to looking at Zink bugs again by the end of next to.
01:19 gfxstrand[d]: No promises, though.
01:19 gfxstrand[d]: I don't even know where to start with the steam thing
01:42 zmike[d]: file ticket
02:05 mhenning[d]: gfxstrand[d]: I am also very puzzled by that one
02:05 gfxstrand[d]: I'm sure it's something insane
02:06 gfxstrand[d]: Most likely another 3 line patch with a 3 page commit message.
02:06 mhenning[d]: yeah that sounds about right
05:01 tiredchiku[d]: hmm nothing in dmesg
05:16 mhenning[d]: okay, please file a report
05:17 tiredchiku[d]: yeah, just checking weston real quick first
05:18 tiredchiku[d]: tried poking around coredumpctl as well but everything just points to libc
05:18 tiredchiku[d]: though, plasma logging says it couldn't initialize the xcb backend for QT_QPA_PLUGIN, which matches what rhed0x saw in gdb
05:19 tiredchiku[d]: :o weston works
05:27 tiredchiku[d]: okay
05:27 tiredchiku[d]: pure x11 sessions also work
05:27 tiredchiku[d]: it's xwayland stuff that seems to be failing?
05:29 tiredchiku[d]: so at least that's narrowed down
05:48 airlied[d]: okay looks like convergeance was a cts bug, and rebasing fixed it
08:38 karolherbst[d]: airlied[d]: did you ever run the other benchmarks from the vulkanized coop matrix talk?
08:49 airlied[d]: I've ran a the vk coop and llama-bench at various times, but not sure if I ran llama-bench on nvk that often
08:56 tiredchiku[d]: ookay
08:56 tiredchiku[d]: got a backtrace from sway
08:56 tiredchiku[d]: NVK's fine
08:56 tiredchiku[d]: ..it's loader bullshit because I had the nvidia proprietary drivers on disk
08:57 tiredchiku[d]: and /etc/profile apparently doesn't apply early enough
09:09 tiredchiku[d]: what I don't understand
09:09 tiredchiku[d]: is why VK_ICD_FILENAMES is being ignored
09:10 tiredchiku[d]: even if I log in from a tty, set it, and then try to start plasma wayland or sway
09:10 tiredchiku[d]: set it only to the nouveau icds, that is
09:24 asdqueerfromeu[d]: tiredchiku[d]: Have you tried setting `VK_DRIVER_FILES` too?
09:29 karolherbst[d]: airlied[d]: I see.. well I'll create new numbers from scratch anyway, but yeah.. wanted to do some updated numbers with the patches I have on top
09:30 karolherbst[d]: should probably upstream the barrier stuff next, because that was another big improvement in the vk coop one
09:30 karolherbst[d]: or well.. write the proper code for it..
09:38 karolherbst[d]: I think I'll do that tomorrow or the day after, and get some real work done today as long as it's not 35ºC outside 🫠
11:40 tiredchiku[d]: asdqueerfromeu[d]: yes
11:58 tiredchiku[d]: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13436
12:22 karolherbst[d]: tiredchiku[d]: do `p getenv("VK_ICD_FILENAMES")` in gdb
12:23 karolherbst[d]: ohhhh
12:23 karolherbst[d]: jfc it's a dead lock
12:24 tiredchiku[d]: <a:Stitch_Panic:1345083362506838127>
12:24 karolherbst[d]: also
12:24 karolherbst[d]: it's not the vulkan driver
12:24 karolherbst[d]: it's the EGL driver
12:25 karolherbst[d]: or GLX
12:25 tiredchiku[d]: nvidia doesn't have a separate .so for the vulkan driver
12:25 karolherbst[d]: ahh
12:25 tiredchiku[d]: it's all in libnvidia_GLX.so or whatever it's called
12:25 tiredchiku[d]: you can cat their vulkan icd and it points to the same library
12:26 karolherbst[d]: anyway.. it's a dead-lock inside `eglQueryDevicesEXT` because it's called again from inside nvidia or something
12:27 karolherbst[d]: karolherbst[d]: anyway, what's the out of that one?
12:28 tiredchiku[d]: karolherbst[d]: (gdb) show environment VK_ICD_FILENAMES
12:28 tiredchiku[d]: VK_ICD_FILENAMES = /usr/share/vulkan/icd.d/nouveau_icd.x86_64.json:/usr/share/vulkan/icd.d/nouveau_icd.i686.json
12:29 tiredchiku[d]: for posterity:
12:29 tiredchiku[d]: (gdb) p getenv("VK_ICD_FILENAMES)")
12:29 tiredchiku[d]: 'getenv' has unknown return type; cast the call to its declared return type```
12:29 karolherbst[d]: `p (const char *)getenv("VK_ICD_FILENAMES)")`
12:30 tiredchiku[d]: says 0x0
12:30 karolherbst[d]: so the `VK_ICD_FILENAMES` env var isn't set within the process
12:30 karolherbst[d]: you can try with `set environment VK_ICD_FILENAMES ....`
12:30 tiredchiku[d]: I set it via /etc/profile, yeah
12:30 karolherbst[d]: and then run it
12:31 karolherbst[d]: tiredchiku[d]: well, it's not set for the process
12:31 tiredchiku[d]: :doomthink:
12:31 tiredchiku[d]: then why would it work before that mesa change /genq
12:31 karolherbst[d]: does `echo "$VK_ICD_FILENAMES"` print anything in your sell?
12:31 karolherbst[d]: *shell
12:31 tiredchiku[d]: yes
12:33 tiredchiku[d]: ```[sidpr@makron ~]$ echo "$VK_ICD_FILENAMES"
12:33 tiredchiku[d]: /usr/share/vulkan/icd.d/nouveau_icd.x86_64.json:/usr/share/vulkan/icd.d/nouveau_icd.i686.json
12:40 karolherbst[d]: mhhh
12:41 karolherbst[d]: and launching the compositor from the same shell makes it be unset within gdb?
12:41 gfxstrand[d]: It's a known NVIDIA bug. And Nvidia knows about the bug and I've been told they're working on it.
12:42 gfxstrand[d]: The environment variable thing is just the loader or someone else trying to be suid-safe, I think, and scrubbing environment variables.
12:43 gfxstrand[d]: I have no idea why it bisects to that EGL patch. I've been hitting that ever since we switched the default to Zink.
12:44 karolherbst[d]: gfxstrand[d]: it adds a dead-lock
12:45 karolherbst[d]: `eglQueryDevicesEXT` takes a lock, queries devices, now zink loads nvidia, which does some EGL thing that calls into `eglQueryDevicesEXT` waiting on the same lock
12:45 zmike[d]: I don't have much confidence in NV fixing stuff like this considering my NATIVE_WINDOW_IN_USE bug is still around since 2020
12:45 zmike[d]: Which is why apitrace still won't work on blob
12:46 karolherbst[d]: I think we need to fix this inside mesa maybe...
12:47 karolherbst[d]: though... yeah dunno.. maybe nvidia not calling into EGL/GLX stuff would help
12:47 karolherbst[d]: but not sure if we can actually require this?
12:48 karolherbst[d]: taking global locks is always like... well..
12:48 karolherbst[d]: interesting
12:49 tiredchiku[d]: gfxstrand[d]: the env var was a workaround until that change, as karol described
12:49 asdqueerfromeu[d]: zmike[d]: I think you also mentioned this in your legendary 2022 talk (and as you can see, nothing was really done)
12:51 karolherbst[d]: but yeah.. nvidia just randomly breaks like this in weird and funny ways
12:51 karolherbst[d]: it's really great
12:57 tiredchiku[d]: well
12:57 tiredchiku[d]: guess I'll set up a second boot/chroot/something then
12:59 karolherbst[d]: just move the ICD file somewhere else 😄
13:00 tiredchiku[d]: hm, I suppose that's an option
13:00 tiredchiku[d]: to rename the nvidia icd at boot if it's loading nouveau
13:01 karolherbst[d]: do a weird bind mount thing 😄
13:07 tiredchiku[d]: oh yeah!
13:08 tiredchiku[d]: that works great :D
13:19 gfxstrand[d]: I've wondered if we don't need a way to just skip the loader for Zink.
13:20 gfxstrand[d]: I think there's an extension for that and we should probably use that when we do the Zink override for nouveau. I just haven't gotten around to it
13:31 mohamexiety[d]: do the common nir lowerings for bitfield ops not support truncation? e.g. suppose source is 64bit, storing it in 8bit
13:35 tiredchiku[d]: gfxstrand[d]: would be useful, yeah
13:36 tiredchiku[d]: but we'd still need a way to make the system use nvc0, for the people who still need that
13:53 asdqueerfromeu[d]: @ Sid Have you explored the `sway` capability theory for your environment variable issue?
13:53 tiredchiku[d]: no
14:04 gfxstrand[d]: tiredchiku[d]: Yes but with this extension we would entirely skip loading any other drivers but the system NVK whenever the system Mesa uses Zink because of the nouveau override. Really, the rule would be "use whatever NVK is installed with Zink" so it would work for local builds as well.
14:05 tiredchiku[d]: yeah, that does sound very helpful
14:13 saancreed[d]: tiredchiku[d]: This may be the cause after all, remember that privileged binaries cause the Vulkan loader to ignore some environment variables, and on Arch `kwin_wayland` is installed with `cap_sys_nice=ep`.
14:13 tiredchiku[d]: possibly, yeah
14:14 tiredchiku[d]: but I'd rather not mess with distro packaging to have things work 😅
14:17 saancreed[d]: Can you instead try `VK_LOADER_DRIVERS_SELECT='*nouvaeu*'` then? I think this one shouldn't be ignored even in privileged processes, although the documentation is not very precise there.
14:18 tiredchiku[d]: sure
14:22 tiredchiku[d]: doesn't seem to help
14:23 saancreed[d]: Ah, disappointing. The VK loader debug variable could probably tell you more about the why, if you want to pursue that.
14:24 tiredchiku[d]: well, if we know it's an nvidia side issue and nvidia's aware of it too, I don't have much interest in figuring it out and would rather do other things 😅
14:34 phomes_[d]: gfxstrand[d]: if this means being able to test a build of zink/nvk in meson devenv then that would be huge
14:48 gfxstrand[d]: That would be annoying to get working
14:48 gfxstrand[d]: But maybe possible?
14:57 mhenning[d]: phomes_[d]: I think you can already test zink/nvk in devenv?
15:05 phomes_[d]: it does? Then I have been testing in an unnecessarily complex way 🙂 I think there was something in the past requiring a full install. Maybe it was just necessary to have 25.1 installed to get zink picked as default?
15:07 mhenning[d]: yeah, I've been testing that way for a while
15:59 gfxstrand[d]: Okay, I think my Z/S reworks are in decent shape. Now I have to figure out separate Z/S sparse.
18:17 gfxstrand[d]: Whats the flag to get nvdisasm to dump out dep/barrier info?
18:19 mhenning[d]: it doesn't
18:20 gfxstrand[d]: I thought it did on Blackwell
18:20 gfxstrand[d]: Or am I making that up?
18:20 mhenning[d]: I think a recent update removed that on blackwell
18:20 mhenning[d]: so maybe they released it by mistake?
18:21 mhenning[d]: Unless I'm forgetting something it used to do it for me and doesn't any more
18:21 gfxstrand[d]: Does anyone still happen to have that binary?
18:21 karolherbst[d]: which CUDA version was that from?
18:21 gfxstrand[d]: 12.7, I think?
18:21 mhenning[d]: you could try compiler_explorer
18:22 karolherbst[d]: nvidia has rpm repos for all versions
18:22 mhenning[d]: yeah, it's possible you can still download it from nvidia
18:22 karolherbst[d]: mhh
18:22 karolherbst[d]: seems like 12.7 is gone, but 12.6 and 12.8 exists
18:23 karolherbst[d]: do you have a test binary thing I can try it out with?
18:23 gfxstrand[d]: `00027f69 0000ffff 0c0033ff 004e0c00`
18:23 karolherbst[d]: what SM was blackwell? 120?
18:23 gfxstrand[d]: yup
18:24 karolherbst[d]: did it need a special flag or just `-hex`?
18:24 gfxstrand[d]: Just -hex, I think. Not even that
18:24 karolherbst[d]: ahh
18:24 karolherbst[d]: 12.8 prints it
18:25 karolherbst[d]: the fedora41 repo has it: https://gist.github.com/karolherbst/d9f6d8fcd42889fdc6dc8d92df7430ee
18:25 karolherbst[d]: `sudo dnf install /usr/local/cuda-12.8/bin/nvdisasm`
18:25 karolherbst[d]: ` /*0000*/ TMML.LOD.DXY.NODEP RZ, R2, R0, URZ, 1D, 0x3 &req={2} &wr=0x0 ?WAIT6_END_GROUP;`
18:26 karolherbst[d]: karolherbst[d]: you don't need the entire file, I just have enough so I can go back to SM10 😄
18:26 mhenning[d]: anyway, what it printed wasn't at all surprising to me other than that the names were weird
18:27 gfxstrand[d]: Okay, I've got it
18:27 gfxstrand[d]: 12.8 has it
18:27 gfxstrand[d]: It's gone from 12.9
18:27 karolherbst[d]: my mesa_nvdisasm script has a handy `CUDA_VERSION` handling thing: https://gist.githubusercontent.com/karolherbst/a8d538fc6e649adcd95bcfafb97c7c7e/raw/9957200cf1794a972c2bc9314a8006924b0610b3/mesa_nvdisasm.sh
18:27 karolherbst[d]: so I can do: `echo "00027f69 0000ffff 0c0033ff 004e0c00" | CUDA_VERSION=12.8 mesa_nvdisasm SM120`
18:28 gfxstrand[d]: So does nvdis in nv-shader-toosl
18:28 karolherbst[d]: ahh.. I should probably start using that one
18:28 gfxstrand[d]: and nvfuzz
18:28 karolherbst[d]: anyway.. nvidia keeps all those old cuda versions around, it's funny
18:28 mohamexiety[d]: huh it still did print it for me in 12.9
18:28 karolherbst[d]: maybe somebody should uhm.. have a local clone of the entire thing 🙃
18:29 karolherbst[d]: mohamexiety[d]: not for me..
18:29 karolherbst[d]: maybe minor update removed it?
18:29 mohamexiety[d]: interesting
18:41 gfxstrand[d]: karolherbst[d]: Grabbed
18:51 karolherbst[d]: I mean like everything: https://developer.download.nvidia.com/compute/cuda/repos/ like all the repos, unless you meant that as well 😄
19:08 mohamexiety[d]: mohamexiety[d]: doesnt do it for ptx/cuda/opencl but does it with glsl via nvdump. that's interesting and weird
19:18 gfxstrand[d]: Ugh... I'm pretty sure this cbuf patch is still kinda wrong
19:18 gfxstrand[d]: NVIDIA HW behavior is really annoying here
19:18 karolherbst[d]: what's the issue?
19:19 gfxstrand[d]: Immediate ofsets are signed if and only if the indirect offset is not RZ
19:19 gfxstrand[d]: It's always RN+signed or RN or RZ+unsigned
19:19 karolherbst[d]: right..
19:19 gfxstrand[d]: and I'm pretty sure that rule applies to everything
19:20 karolherbst[d]: sounds about right
19:21 karolherbst[d]: so what if you put in a reg that's 0 but not RZ 😛
19:21 gfxstrand[d]: signe
19:22 karolherbst[d]: but yeah, I can see how that's annoying for a compiler doing optimizations/legalizing
19:22 gfxstrand[d]: Yup
19:22 karolherbst[d]: though...
19:22 karolherbst[d]: so uhm...
19:23 karolherbst[d]: one question: how does it matter in practise
19:23 karolherbst[d]: like.. if you have RZ+unsigned form
19:23 gfxstrand[d]: UBO bounds checking
19:23 karolherbst[d]: then... you just stay in RZ+unsigned form anyway
19:23 karolherbst[d]: if you are in RN+signed, if you get rid of RN because it's 0, then the offset is either a negative value, in which case you replace the entire load with 0
19:23 gfxstrand[d]: 1 << 15 is a valid constant UBO offset but it's -1 when treated as RN+offset
19:23 karolherbst[d]: or you keep the positive offset
19:24 karolherbst[d]: gfxstrand[d]: why would you go from RZ+offset ot RN+offset?
19:24 gfxstrand[d]: What do you mean?
19:25 karolherbst[d]: like when you create the ubo access you know what's what, so the problems are just transitions between the forms, no?
19:25 karolherbst[d]: though I guess it's annoying adding an add to account for the range restriction
19:25 gfxstrand[d]: If you have a 64K UBO (max size) and you have an `ldc c[0x0][0xfffc]`, that's an in-bounds load. However, `ldc c[0x0][r1+-0x4]` will be OOB if `r1 == 0`.
19:26 karolherbst[d]: sure
19:26 karolherbst[d]: don't emit it then
19:27 gfxstrand[d]: Which is fine. I can handle it. It's just annoying because if NAK can ever copy-propagate something NIR can't (very unlikely) then we can potentially get into a weird situation. But, again, that can only happen if NAK propagates something NIR can't which, uh... that's not goona happen.
19:27 karolherbst[d]: right...
19:27 karolherbst[d]: but yeah, I think just preventing that stuff is the way to go there, I don't think it matters for later optimizations much
19:28 karolherbst[d]: like worst case you don't copy prop if the offset is negative
20:04 gfxstrand[d]: Yeah. It's just annoying because we don't really have a good way to encode any of that right now
20:19 gfxstrand[d]: Ugh... Why is bindgen generating 64-bit rust? *sigh*
20:19 gfxstrand[d]: Or rather why is the compiler trying to build it for 64-bit?
20:20 mhenning[d]: oh that's a longstanding issue
20:20 mhenning[d]: you need to set a thing
20:20 mhenning[d]: `BINDGEN_EXTRA_CLANG_ARGS="-m32"`
20:21 gfxstrand[d]: Where does that go?
20:22 mhenning[d]: In my notes I have it for the `meson setup` command but you might need it for ninja too I forget
20:44 karolherbst[d]: there is a cross file property for it now
20:44 karolherbst[d]: let me find it
20:44 karolherbst[d]: gfxstrand[d]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35435#note_2955912
20:46 karolherbst[d]: ohh it's even documented https://mesonbuild.com/Rust-module.html#bindgen
20:46 gfxstrand[d]: Okay, thanks. I was hacking on meson.build but that's better
21:00 gfxstrand[d]: And with that... I think we have Blackwell passing the CTS
21:00 gfxstrand[d]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35843
21:00 gfxstrand[d]: Thanks a bunch, airlied[d] !
21:00 gfxstrand[d]: Once my CTS is done building, I'm going to kick off the official run and go home for the day
21:01 mohamexiety[d]: niceeee!! <a:vibrate:1066802555981672650> <a:vibrate:1066802555981672650>
21:11 airlied[d]: yay!
21:22 gfxstrand[d]: airlied[d]: Any news from NVIDIA on the format modifier? Or should I send a patch?
21:22 airlied[d]: They had a patch, but James had PTO, I expect he might send it out next week, so I'd probably just wait
21:23 gfxstrand[d]: ok
21:23 gfxstrand[d]: I'm happy for James to write and me to review
21:29 gfxstrand[d]: snowycoder[d]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35846
21:30 gfxstrand[d]: I'll try and review the scheduler stuff on Wednesday if I can find the time.
21:36 mohamexiety[d]: ~~1.4 conformance when~~
21:36 mohamexiety[d]: hey we got host copy working on it even
21:37 gfxstrand[d]: Kepler will never even get 1.3
21:37 gfxstrand[d]: tiredchiku[d]: I just filed a Zink issue for what is at the root of a lot of the blob driver insanity: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13441
21:37 gfxstrand[d]: I doubt I'll get to that this week but hopefully in the next week or two.
21:38 tiredchiku[d]: :meowsalute:
21:39 karolherbst[d]: gfxstrand[d]: and here I thought that's impossible
21:39 karolherbst[d]: ohh
21:39 karolherbst[d]: "never"
21:39 gfxstrand[d]: It is
21:39 gfxstrand[d]: hehe
21:39 karolherbst[d]: I read "even" 🙃
21:39 tiredchiku[d]: I might try to take a stab at it myself
21:39 gfxstrand[d]: Yeah, it can't pass the memory model tests.
21:40 karolherbst[d]: right
21:40 gfxstrand[d]: tiredchiku[d]: If you want to crawl through dri/loader stuff, go for it. It's not exactly the most fun corner of Mesa but it's not totally intractable.
21:40 karolherbst[d]: my brain doesn't function in summer 🫠
21:40 gfxstrand[d]: Melting a little?
21:41 mohamexiety[d]: honestly even 1.2 is fine
21:41 mohamexiety[d]: sucks there's not much to do for the HW but it's older than vk 1.0 itself by like 3 years
21:41 gfxstrand[d]: The real question is if we can flip on Zink in another release or two. I'd like to but we need bound cbufs to work.
21:42 tiredchiku[d]: gfxstrand[d]: more familiarity with mesa will never hurt 😅
21:42 gfxstrand[d]: Oh, familiarity with the loader code might hurt. 😛
21:42 tiredchiku[d]: :ah:
22:22 snowycoder[d]: gfxstrand[d]: Don't worry I still need to find time to review mel's round
22:23 snowycoder[d]: gfxstrand[d]: Wohooo! 🔥
22:29 gfxstrand[d]: snowycoder[d]: That's on my short queue, too.
22:29 gfxstrand[d]: Hopefully we can get it all in for 25.2 which branches in 2 weeks.
22:59 airlied[d]: I think it would be good to try and coop mat enablement landed as well before branch if we can
23:00 karolherbst[d]: rb for all the things Mary has written from me 😛
23:01 karolherbst[d]: it does carry a patch to fix latencies for ampere, and it's probably fine to ship it as is, we can always clean it up later
23:02 zmike[d]: gfxstrand[d]: I may be able to find like 14 minutes this week to scramble something together
23:09 gfxstrand[d]: zmike[d]: Feel free to get to it first.
23:10 gfxstrand[d]: The only thing that stopped me the last time I looked at this was figuring out how to plumb the string through.
23:12 karolherbst[d]: that reminded me that I still want to rework how the pipe_loader and zink interact with each other, because for rusticl I have special needs and it's kinda... uhm.. not great atm
23:21 zmike[d]: what if we just deleted all the other drivers so we didn't need pipe_loader anymore?
23:22 karolherbst[d]: make SVM in zink happen and I'll consider it
23:22 karolherbst[d]: though I was considering implementing SVM at home with that bda replay stuff for the lols
23:23 karolherbst[d]: and then make a "we got SVM at home" meme
23:25 karolherbst[d]: "Note that this mechanism is intended only to support capture/replay tools, and is not recommended for use in other applications." :ferrisSneaky:
23:28 karolherbst[d]: zmike[d]: ... sooo uhm.... how does sparse work for real? Could I make a.. let's say... 16GiB sparse allocation and then sub-allocate buffers from it? But also do the allocation with a `VkBufferOpaqueCaptureAddressCreateInfo` thing?
23:28 karolherbst[d]: though I don't even know how sparse actually work
23:29 karolherbst[d]: must the entire sparse thing be valid before you can use it?
23:29 zmike[d]: uhhhh
23:29 zmike[d]: what?
23:29 zmike[d]: no, an entire sparse resource does not have to be bound before it can be used
23:30 karolherbst[d]: mhhhh
23:30 karolherbst[d]: sooo... pipe_screen::alloc_vm could allocate a huge sparse resource, which wouldn't use any device memory, right?
23:30 zmike[d]: right
23:31 karolherbst[d]: and then `pipe_screen::resource_assign_vma` could sub-allocate from the `alloc_vm` space and bind parts of the sparse resource to actual memory
23:31 zmike[d]: I'm not sure why you need special hooks for this when gallium already has existing sparse machinery
23:31 zmike[d]: and I also don't know what you mean by suballocate
23:31 karolherbst[d]: because I need to decide on the virtual address
23:31 zmike[d]: if you make a big sparse buffer just figure it out
23:32 karolherbst[d]: not the driver
23:32 zmike[d]: sounds like you need that memory map placed extension thingy
23:32 karolherbst[d]: yeah
23:32 karolherbst[d]: but I could also abuse the bda replay thing...
23:32 zmike[d]: one of our people already did an implementation in zink
23:32 zmike[d]: I've been meaning to get that upstreamed
23:32 karolherbst[d]: ahhh
23:32 karolherbst[d]: cool
23:32 karolherbst[d]: which vulkan drivers implement it?
23:33 zmike[d]: idk
23:33 zmike[d]: the cool ones I assume
23:33 karolherbst[d]: mhh
23:33 karolherbst[d]: well if it's almost there, then I won't have to bother with abusing bda then
23:36 karolherbst[d]: ohh.. I also need to figure out subgroups on zink.. that's gonna be fun
23:37 zmike[d]: I did subgroups already
23:37 karolherbst[d]: ohh indeed
23:38 karolherbst[d]: I should update the features.txt file at some point 🙃
23:39 gfxstrand[d]: zmike[d]: All the subgroups or just the dumb GL ones?
23:39 gfxstrand[d]: And does it work on Intel? 😂
23:40 karolherbst[d]: zmike[d]: do you think zink could wire up `pipe_caps::context_priority_mask`?
23:40 karolherbst[d]: ahh yeah.. CL subgroups seem to be busted on zink 🥲
23:42 zmike[d]: gfxstrand[d]: I'm a dumb guy doing dumb GL stuff
23:42 zmike[d]: karolherbst[d]: I don't know what this is but maybe
23:42 karolherbst[d]: zmike[d]: queue priorities
23:42 zmike[d]: maybe
23:42 zmike[d]: file tickets
23:43 zmike[d]: my time these days is massively oversubscribed so if I do anything outside of jail it'll be a fast context switch to something I've already plotted out
23:43 karolherbst[d]: heh
23:44 karolherbst[d]: I can probably implement it myself.. shouldn't be too hard
23:44 karolherbst[d]: just need to figure out the vulkan side of things
23:44 karolherbst[d]: mhhhh
23:44 karolherbst[d]: actually...
23:45 karolherbst[d]: it's weird... I could swear the zink subgroup stuff works just fine on my desktop...
23:46 karolherbst[d]: ahh it's only busted on anv 🙃
23:46 zmike[d]: :migraine:
23:46 karolherbst[d]: yeah intel and their weird sub group sizes
23:46 karolherbst[d]: was a real pita to get it to work on iris
23:47 karolherbst[d]: there is `pipe_context::get_compute_state_subgroup_size`
23:47 karolherbst[d]: which zink probably needs to implement correctly, though not sure if vulkan gives you all the necessary info
23:50 gfxstrand[d]: Yeah, it's possible to do it with Vulkan, just a pain.