01:22 fdobridge_: <e​sdrastarsis> https://gitlab.freedesktop.org/mesa/mesa/-/issues/10440
01:22 fdobridge_: <e​sdrastarsis> lol
01:28 fdobridge_: <a​irlied> not sure if I should close as spam or not 😛
01:42 fdobridge_: <o​rowith2os> probably should
01:42 fdobridge_: <o​rowith2os> there is absolutely no logic or sense in that issue
03:41 Ellenor: 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:06 fdobridge_: <g​fxstrand> I've dealt with it.
04:08 fdobridge_: <g​fxstrand> 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:16 fdobridge_: <o​rowith2os> 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:16 fdobridge_: <o​rowith2os> smh
04:16 fdobridge_: <o​rowith2os> hostname too
04:24 fdobridge_: <g​fxstrand> I suspect they didn't know how to change the .so name or they would have. 😅
04:31 fdobridge_: <r​edsheep> Reminds me of a certain programming language, I am sure they would be a fan: https://en.wikipedia.org/wiki/Brainfuck
04:39 fdobridge_: <g​fxstrand> Yeah, probably
05:37 fdobridge_: <!​DodoNVK (she) 🇱🇹> I wonder if :triangle_nvk: actually has issues with some of Steam's secret components though
07:12 fdobridge_: <!​DodoNVK (she) 🇱🇹> What is this weird shader? :frog_gears:
07:12 fdobridge_: <!​DodoNVK (she) 🇱🇹> https://cdn.discordapp.com/attachments/1034184951790305330/1196351274518585354/message.txt?ex=65b74ff2&is=65a4daf2&hm=e6ccd7640444f2d89e4feed39e1c11e3059648c335f3b430d332c9500b27b89d&
07:16 fdobridge_: <k​arolherbst🐧🦀> indirect array access
07:17 fdobridge_: <k​arolherbst🐧🦀> _however_ I think this should be a bcsel 😄
07:17 fdobridge_: <k​arolherbst🐧🦀> maybe we should lower such indirects to a if ladder for small sizes?
07:17 fdobridge_: <!​DodoNVK (she) 🇱🇹> I think NAK explodes on that empty block
07:17 fdobridge_: <k​arolherbst🐧🦀> nv hardware can't really do indirects here, so it needs to be lowered to some form of memory
16:16 fdobridge_: <g​fxstrand> Oh, it's entirely possible. But without even knowing what game they were trying to run, it's impossible to reproduce.
16:17 fdobridge_: <k​arolherbst🐧🦀> this should happen with any game or even on startup of steam
16:17 fdobridge_: <g​fxstrand> Yeah, we probably should. It's easy enough to do.
16:17 fdobridge_: <k​arolherbst🐧🦀> steam tries to fetch information of the vulkan driver, so worst case just open the system information inside steam
16:17 fdobridge_: <g​fxstrand> Oh, and I should wire up the large constants pass.
16:18 fdobridge_: <g​fxstrand> 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:18 fdobridge_: <g​fxstrand> Still, making it a cbuf is pretty easy now that I have that wired up.
16:18 fdobridge_: <k​arolherbst🐧🦀> just upload it to the same one holding the descriptor stuff or something 😛
16:19 fdobridge_: <g​fxstrand> Eh, it's probably easier to make it its own cbuf and put the constants at the end of the shader.
16:19 fdobridge_: <k​arolherbst🐧🦀> yeah.. probably
16:19 fdobridge_: <g​fxstrand> Otherwise, we're pushing that data on every draw
16:19 fdobridge_: <g​fxstrand> But, yeah, easy to hook up.
16:30 fdobridge_: <!​DodoNVK (she) 🇱🇹> Actually it happens with vkcube too (`vulkandriverquery` just opens a Vulkan device, does some extension querying and quits according to `ltrace`)
16:50 fdobridge_: <!​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:58 fdobridge_: <m​henning> 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:15 fdobridge_: <k​arolherbst🐧🦀> you can probably set those via the `PRIV_REG` mme thing 😄
18:06 fdobridge_: <g​fxstrand> Ugh... That's... annoying. 🫤
18:08 fdobridge_: <!​DodoNVK (she) 🇱🇹> I have 2 solutions
18:09 fdobridge_: <!​DodoNVK (she) 🇱🇹> Hack up nir.h with a million padding variables or disable the explicit padding feature :frog_gears:
18:18 fdobridge_: <h​untercz122> i'm hitting same issue oh
18:18 fdobridge_: <h​untercz122> i thought i screwed up 32-bit nvk builds somehow
18:29 fdobridge_: <g​fxstrand> Oh, so it's the explicit padding feature that's broken?
18:29 fdobridge_: <g​fxstrand> https://tenor.com/view/charlie-brown-good-grief-sighs-gif-10296718
18:34 fdobridge_: <!​DodoNVK (she) 🇱🇹> I only need the padding on 32-bit so 🤷‍♀️
18:34 fdobridge_: <!​DodoNVK (she) 🇱🇹> I mean the extra padding variables in nir.h
18:50 fdobridge_: <g​fxstrand> This should tide us over for now: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27078
18:51 fdobridge_: <g​fxstrand> Yeah, I've seen bindgen bugs parsing NIR before.
18:52 fdobridge_: <g​fxstrand> I'm not really that surprised that it `--explicit-padding` would have hit them.
18:52 fdobridge_: <g​fxstrand> 😩
18:52 fdobridge_: <k​arolherbst🐧🦀> I also hit a couple of bindgen bugs :ferrisUpsideDown:
18:52 fdobridge_: <k​arolherbst🐧🦀> but they generally were fixed in newer versions
18:54 fdobridge_: <g​fxstrand> Anyway, there's a GCC pragma which we can use to detect padding instead. IDK if it'll actually error, though.
18:55 fdobridge_: <k​arolherbst🐧🦀> `-Werror=adding
18:55 fdobridge_: <k​arolherbst🐧🦀> `-Werror=adding` (edited)
18:55 fdobridge_: <k​arolherbst🐧🦀> `-Werror=padding` (edited)
18:55 fdobridge_: <k​arolherbst🐧🦀> ehhh `padded` I guess
18:55 fdobridge_: <k​arolherbst🐧🦀> let's see...
18:56 fdobridge_: <k​arolherbst🐧🦀> ohhh
18:56 fdobridge_: <k​arolherbst🐧🦀> it's a error push..
18:56 fdobridge_: <k​arolherbst🐧🦀> @gfxstrand https://godbolt.org/z/vT3qonEc9
18:56 fdobridge_: <!​DodoNVK (she) 🇱🇹> It should fix issue 10440 too (that's a really low-quality issue though)
18:56 fdobridge_: <k​arolherbst🐧🦀> so yeah.. seems to work
18:57 fdobridge_: <g​fxstrand> Yeah, I'm not going to dignify that issue with a `Closes:` tag.
18:57 fdobridge_: <k​arolherbst🐧🦀> ~~It's already closed anyway~~
18:59 fdobridge_: <m​arysaka> 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:59 fdobridge_: <m​arysaka> ~~would be awesome to autogen those somehow tbh~~
19:00 fdobridge_: <g​fxstrand> 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:00 fdobridge_: <g​fxstrand> Yeah. I deleted those since we have the GCC thing.
19:03 fdobridge_: <!​DodoNVK (she) 🇱🇹> I wonder if GCC could compile NAK
19:04 fdobridge_: <g​fxstrand> I don't really want to support gcc-rs at the moment
19:13 fdobridge_: <k​arolherbst🐧🦀> I'm already waiting for the first "doesn't compile with gcc-rs" bug, just to close it....
19:15 HdkR: It's okay, my project also doesn't compile with GCC :)
19:31 fdobridge_: <!​DodoNVK (she) 🇱🇹> Are you waiting for the first PR though?
19:40 fdobridge_: <a​irlied> I see talk of porting bindgen to gcc also 🙂
19:44 fdobridge_: <k​arolherbst🐧🦀> Is that even possible? I thought the whole idea of GCC was to not much such an API available
19:46 fdobridge_: <a​irlied> I think gcc plugins can help
19:46 fdobridge_: <a​irlied> https://github.com/rust-lang/rust-bindgen/issues/1949
19:47 fdobridge_: <k​arolherbst🐧🦀> I see...
19:50 fdobridge_: <g​fxstrand> https://www.youtube.com/watch?v=DQTz0cjZANw
20:14 fdobridge_: <e​sdrastarsis> I think Stray needs this: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26990
20:16 fdobridge_: <e​sdrastarsis> Deep Rock Galactic, Resident Evil 7, Resident Evil 2 Remake and Resident Evil 3 Remake (All running on dx11) also needs this
20:22 fdobridge_: <g​fxstrand> Yeah. Unfortunately it breaks a bunch of CTS tests and neither @airlied or I have had the time to track them down.
20:23 fdobridge_: <!​DodoNVK (she) 🇱🇹> I'm getting memory model flashbacks
20:25 Lyude: airlied: probably going to start pulling in some of asahi's drm stuff as well btw
20:26 fdobridge_: <g​fxstrand> Nah. I think it'll be okay. We just need to play around with it.
20:28 fdobridge_: <!​DodoNVK (she) 🇱🇹> I mean the feature works with games but fails CTS (this is what happened with memory model before)
20:34 fdobridge_: <a​irlied> I got into nil and got a bit lost in 3d vs 2d
20:35 fdobridge_: <m​ohamexiety> 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:35 fdobridge_: <k​arolherbst🐧🦀> yeah.. 3d is kinda a mess
20:44 fdobridge_: <g​fxstrand> We'll get it sorted. I doubt it's that hard once we figure out what's going wrong.
20:45 fdobridge_: <g​fxstrand> 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:45 fdobridge_: <k​arolherbst🐧🦀> copies would have been my guess
20:45 fdobridge_: <k​arolherbst🐧🦀> because that's the part where 3d is really weird
20:46 fdobridge_: <k​arolherbst🐧🦀> can we force meta for all of 3d and see if it works?
20:49 fdobridge_: <k​arolherbst🐧🦀> or maybe meta is already used for all copies involving a 3d image?
20:49 fdobridge_: <g​fxstrand> I don't think we need to
20:49 fdobridge_: <g​fxstrand> It's just copying data
20:49 fdobridge_: <k​arolherbst🐧🦀> mhhh right...
20:50 fdobridge_: <g​fxstrand> If copying to a texture and then texturing works, I think we can DMA them fine.
20:50 fdobridge_: <k​arolherbst🐧🦀> yeah, fair enough
20:50 fdobridge_: <k​arolherbst🐧🦀> mhhh
20:50 fdobridge_: <k​arolherbst🐧🦀> what kind of tests are failing? The one you point out is doing surface loads in compute shaders, right?
20:51 fdobridge_: <g​fxstrand> I don't have a full list
21:00 fdobridge_: <g​fxstrand> Wait... `image_load`?!? WTH?
21:01 fdobridge_: <k​arolherbst🐧🦀> what's bad about that? image load/store not valid for compressed formats?
21:02 fdobridge_: <g​fxstrand> Nope
21:03 fdobridge_: <k​arolherbst🐧🦀> I can see why it wouldn't work with `SULD.D`, but `SULD.P`? maybe?
21:04 fdobridge_: <g​fxstrand> There's no point in load/store on them
21:05 fdobridge_: <k​arolherbst🐧🦀> doing an image store on compressed images would be funky indeed
21:06 fdobridge_: <g​fxstrand> You can but you have to make a unit view of it.
21:06 fdobridge_: <k​arolherbst🐧🦀> I see...
22:35 fdobridge_: <g​fxstrand> You can but you have to make a uint view of it. (edited)
22:35 Lyude: 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:04 dakr: 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:11 airlied: yeah I feel we should try and minimise the wholesale use of another branch
23:11 airlied: and try and nail down what we should concentrate on getting upstream
23:13 airlied: also I'd appreciate reviewing anything we do pull over so you are least somewhat familiar with it
23:15 Lyude: makes sense to me
23:17 Lyude: 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:24 airlied: both :)
23:25 airlied: 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:25 Lyude: gotcha
23:26 Lyude: 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?