01:22fdobridge_: <esdrastarsis> https://gitlab.freedesktop.org/mesa/mesa/-/issues/10440
01:22fdobridge_: <esdrastarsis> lol
01:28fdobridge_: <airlied> not sure if I should close as spam or not 😛
01:42fdobridge_: <orowith2os> probably should
01:42fdobridge_: <orowith2os> there is absolutely no logic or sense in that issue
03:41Ellenor: I'd recmomend closing as aggressive violation of ToS, not spam. it might be someone with a real issue that they don't understand and are frustrated by, but it's quite possible they just hate 3d graphics on UNIX.
04:06fdobridge_: <gfxstrand> I've dealt with it.
04:08fdobridge_: <gfxstrand> Honestly, I'm kinda impressed just how much work they put to to make a steam dump spit out the word "fuck" that many times. That took effort. 😂
04:16fdobridge_: <orowith2os> they could've changed `libvulkan_nouveau.so` and the `/home` path for some more extra "fuck"s, not as much effort as I'd expect
04:16fdobridge_: <orowith2os> smh
04:16fdobridge_: <orowith2os> hostname too
04:24fdobridge_: <gfxstrand> I suspect they didn't know how to change the .so name or they would have. 😅
04:31fdobridge_: <redsheep> Reminds me of a certain programming language, I am sure they would be a fan: https://en.wikipedia.org/wiki/Brainfuck
04:39fdobridge_: <gfxstrand> Yeah, probably
05:37fdobridge_: <!DodoNVK (she) 🇱🇹> I wonder if :triangle_nvk: actually has issues with some of Steam's secret components though
07:12fdobridge_: <!DodoNVK (she) 🇱🇹> What is this weird shader? :frog_gears:
07:12fdobridge_: <!DodoNVK (she) 🇱🇹> https://cdn.discordapp.com/attachments/1034184951790305330/1196351274518585354/message.txt?ex=65b74ff2&is=65a4daf2&hm=e6ccd7640444f2d89e4feed39e1c11e3059648c335f3b430d332c9500b27b89d&
07:16fdobridge_: <karolherbst🐧🦀> indirect array access
07:17fdobridge_: <karolherbst🐧🦀> _however_ I think this should be a bcsel 😄
07:17fdobridge_: <karolherbst🐧🦀> maybe we should lower such indirects to a if ladder for small sizes?
07:17fdobridge_: <!DodoNVK (she) 🇱🇹> I think NAK explodes on that empty block
07:17fdobridge_: <karolherbst🐧🦀> nv hardware can't really do indirects here, so it needs to be lowered to some form of memory
16:16fdobridge_: <gfxstrand> Oh, it's entirely possible. But without even knowing what game they were trying to run, it's impossible to reproduce.
16:17fdobridge_: <karolherbst🐧🦀> this should happen with any game or even on startup of steam
16:17fdobridge_: <gfxstrand> Yeah, we probably should. It's easy enough to do.
16:17fdobridge_: <karolherbst🐧🦀> steam tries to fetch information of the vulkan driver, so worst case just open the system information inside steam
16:17fdobridge_: <gfxstrand> Oh, and I should wire up the large constants pass.
16:18fdobridge_: <gfxstrand> On Volta+, we can do the Intel trick of making it part of the shader. On older hardware, it'll have to be a cbuf.
16:18fdobridge_: <gfxstrand> Still, making it a cbuf is pretty easy now that I have that wired up.
16:18fdobridge_: <karolherbst🐧🦀> just upload it to the same one holding the descriptor stuff or something 😛
16:19fdobridge_: <gfxstrand> Eh, it's probably easier to make it its own cbuf and put the constants at the end of the shader.
16:19fdobridge_: <karolherbst🐧🦀> yeah.. probably
16:19fdobridge_: <gfxstrand> Otherwise, we're pushing that data on every draw
16:19fdobridge_: <gfxstrand> But, yeah, easy to hook up.
16:30fdobridge_: <!DodoNVK (she) 🇱🇹> Actually it happens with vkcube too (`vulkandriverquery` just opens a Vulkan device, does some extension querying and quits according to `ltrace`)
16:50fdobridge_: <!DodoNVK (she) 🇱🇹> Actually it's a segfault that doesn't make any sense that's only present since 94d96dac601ff2126996ac37a0b637961d06dfab (it only happens on 32-bit though)
16:58fdobridge_: <mhenning> airlied: Oh, it's totally possible my information is outdated. openrm does have calls into gsp to set a zcull context switching mode and calculate buffer sizes (?) but I haven't looked too carefully
17:15fdobridge_: <karolherbst🐧🦀> you can probably set those via the `PRIV_REG` mme thing 😄
18:06fdobridge_: <gfxstrand> Ugh... That's... annoying. 🫤
18:08fdobridge_: <!DodoNVK (she) 🇱🇹> I have 2 solutions
18:09fdobridge_: <!DodoNVK (she) 🇱🇹> Hack up nir.h with a million padding variables or disable the explicit padding feature :frog_gears:
18:18fdobridge_: <huntercz122> i'm hitting same issue oh
18:18fdobridge_: <huntercz122> i thought i screwed up 32-bit nvk builds somehow
18:29fdobridge_: <gfxstrand> Oh, so it's the explicit padding feature that's broken?
18:29fdobridge_: <gfxstrand> https://tenor.com/view/charlie-brown-good-grief-sighs-gif-10296718
18:34fdobridge_: <!DodoNVK (she) 🇱🇹> I only need the padding on 32-bit so 🤷♀️
18:34fdobridge_: <!DodoNVK (she) 🇱🇹> I mean the extra padding variables in nir.h
18:50fdobridge_: <gfxstrand> This should tide us over for now: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27078
18:51fdobridge_: <gfxstrand> Yeah, I've seen bindgen bugs parsing NIR before.
18:52fdobridge_: <gfxstrand> I'm not really that surprised that it `--explicit-padding` would have hit them.
18:52fdobridge_: <gfxstrand> 😩
18:52fdobridge_: <karolherbst🐧🦀> I also hit a couple of bindgen bugs :ferrisUpsideDown:
18:52fdobridge_: <karolherbst🐧🦀> but they generally were fixed in newer versions
18:54fdobridge_: <gfxstrand> Anyway, there's a GCC pragma which we can use to detect padding instead. IDK if it'll actually error, though.
18:55fdobridge_: <karolherbst🐧🦀> `-Werror=adding
18:55fdobridge_: <karolherbst🐧🦀> `-Werror=adding` (edited)
18:55fdobridge_: <karolherbst🐧🦀> `-Werror=padding` (edited)
18:55fdobridge_: <karolherbst🐧🦀> ehhh `padded` I guess
18:55fdobridge_: <karolherbst🐧🦀> let's see...
18:56fdobridge_: <karolherbst🐧🦀> ohhh
18:56fdobridge_: <karolherbst🐧🦀> it's a error push..
18:56fdobridge_: <karolherbst🐧🦀> @gfxstrand https://godbolt.org/z/vT3qonEc9
18:56fdobridge_: <!DodoNVK (she) 🇱🇹> It should fix issue 10440 too (that's a really low-quality issue though)
18:56fdobridge_: <karolherbst🐧🦀> so yeah.. seems to work
18:57fdobridge_: <gfxstrand> Yeah, I'm not going to dignify that issue with a `Closes:` tag.
18:57fdobridge_: <karolherbst🐧🦀> ~~It's already closed anyway~~
18:59fdobridge_: <marysaka> I guess I will rebase again on it later, but wanted to mention there is a typo on one of the assert for ``nak_shader_info__bindgen_ty_1__bindgen_ty_3`` (there is two ``nak_shader_info__bindgen_ty_1__bindgen_ty_2``)
18:59fdobridge_: <marysaka> ~~would be awesome to autogen those somehow tbh~~
19:00fdobridge_: <gfxstrand> Cool. The diagnostic push doesn't cause it to error but we build with `-Werror` in CI so the combo should be good enough.
19:00fdobridge_: <gfxstrand> Yeah. I deleted those since we have the GCC thing.
19:03fdobridge_: <!DodoNVK (she) 🇱🇹> I wonder if GCC could compile NAK
19:04fdobridge_: <gfxstrand> I don't really want to support gcc-rs at the moment
19:13fdobridge_: <karolherbst🐧🦀> I'm already waiting for the first "doesn't compile with gcc-rs" bug, just to close it....
19:15HdkR: It's okay, my project also doesn't compile with GCC :)
19:31fdobridge_: <!DodoNVK (she) 🇱🇹> Are you waiting for the first PR though?
19:40fdobridge_: <airlied> I see talk of porting bindgen to gcc also 🙂
19:44fdobridge_: <karolherbst🐧🦀> Is that even possible? I thought the whole idea of GCC was to not much such an API available
19:46fdobridge_: <airlied> I think gcc plugins can help
19:46fdobridge_: <airlied> https://github.com/rust-lang/rust-bindgen/issues/1949
19:47fdobridge_: <karolherbst🐧🦀> I see...
19:50fdobridge_: <gfxstrand> https://www.youtube.com/watch?v=DQTz0cjZANw
20:14fdobridge_: <esdrastarsis> I think Stray needs this: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26990
20:16fdobridge_: <esdrastarsis> Deep Rock Galactic, Resident Evil 7, Resident Evil 2 Remake and Resident Evil 3 Remake (All running on dx11) also needs this
20:22fdobridge_: <gfxstrand> Yeah. Unfortunately it breaks a bunch of CTS tests and neither @airlied or I have had the time to track them down.
20:23fdobridge_: <!DodoNVK (she) 🇱🇹> I'm getting memory model flashbacks
20:25Lyude: airlied: probably going to start pulling in some of asahi's drm stuff as well btw
20:26fdobridge_: <gfxstrand> Nah. I think it'll be okay. We just need to play around with it.
20:28fdobridge_: <!DodoNVK (she) 🇱🇹> I mean the feature works with games but fails CTS (this is what happened with memory model before)
20:34fdobridge_: <airlied> I got into nil and got a bit lost in 3d vs 2d
20:35fdobridge_: <mohamexiety> problem with something like this is you don't know/aren't entirely sure it actually works fine with games and it's not just subtly erroring out somewhere. then again the cts fail seems related to compressed colors so dunno
20:35fdobridge_: <karolherbst🐧🦀> yeah.. 3d is kinda a mess
20:44fdobridge_: <gfxstrand> We'll get it sorted. I doubt it's that hard once we figure out what's going wrong.
20:45fdobridge_: <gfxstrand> My first suspicion was that we need to disable Z tiling but it didn't seem to do anything when I tried. I also suspect copies may be busted somehow.
20:45fdobridge_: <karolherbst🐧🦀> copies would have been my guess
20:45fdobridge_: <karolherbst🐧🦀> because that's the part where 3d is really weird
20:46fdobridge_: <karolherbst🐧🦀> can we force meta for all of 3d and see if it works?
20:49fdobridge_: <karolherbst🐧🦀> or maybe meta is already used for all copies involving a 3d image?
20:49fdobridge_: <gfxstrand> I don't think we need to
20:49fdobridge_: <gfxstrand> It's just copying data
20:49fdobridge_: <karolherbst🐧🦀> mhhh right...
20:50fdobridge_: <gfxstrand> If copying to a texture and then texturing works, I think we can DMA them fine.
20:50fdobridge_: <karolherbst🐧🦀> yeah, fair enough
20:50fdobridge_: <karolherbst🐧🦀> mhhh
20:50fdobridge_: <karolherbst🐧🦀> what kind of tests are failing? The one you point out is doing surface loads in compute shaders, right?
20:51fdobridge_: <gfxstrand> I don't have a full list
21:00fdobridge_: <gfxstrand> Wait... `image_load`?!? WTH?
21:01fdobridge_: <karolherbst🐧🦀> what's bad about that? image load/store not valid for compressed formats?
21:02fdobridge_: <gfxstrand> Nope
21:03fdobridge_: <karolherbst🐧🦀> I can see why it wouldn't work with `SULD.D`, but `SULD.P`? maybe?
21:04fdobridge_: <gfxstrand> There's no point in load/store on them
21:05fdobridge_: <karolherbst🐧🦀> doing an image store on compressed images would be funky indeed
21:06fdobridge_: <gfxstrand> You can but you have to make a unit view of it.
21:06fdobridge_: <karolherbst🐧🦀> I see...
22:35fdobridge_: <gfxstrand> You can but you have to make a uint view of it. (edited)
22:35Lyude: airlied, dakr actually - would there be any issues with me just basing the rvkms branch off asahi's branch for now? seems like it might be a bit less work then cherry-picking the stuff we need for rvkms on its own
23:04dakr: Lyude, if the goal is to land rvkms and push the Rust infrastructure forward, I feel like picking only the bits that are required is worth the effort.
23:11airlied: yeah I feel we should try and minimise the wholesale use of another branch
23:11airlied: and try and nail down what we should concentrate on getting upstream
23:13airlied: also I'd appreciate reviewing anything we do pull over so you are least somewhat familiar with it
23:15Lyude: makes sense to me
23:17Lyude: airlied: do you mean me reviewing things or the other way around? if so I could probably use some eyes on https://gitlab.freedesktop.org/lyudess/linux/-/commit/03b0787f200f51f488dd03e26d3292107206fd98 and https://gitlab.freedesktop.org/lyudess/linux/-/commit/434ddb253c2fdceca25eff323d467235284fafa2
23:24airlied: both :)
23:25airlied: I'd like to know we are comfortable with any bindings we are using are good rust and integrate well with the C side
23:25Lyude: gotcha
23:26Lyude: also - I am realizing now that those are from the RFL branch, I will look at adding the original commits for those since I assume we probably want those over the ones from the asahi branch?