00:10 fdobridge: <r​edsheep> Do you mean like if you're running out of vram? Unless something is really wrong I don't expect baldur's gate to allocate more than 24 GB
00:12 fdobridge: <a​irlied> if you have REBAR then I've no idea, without REBAR we are running out of BAR space
00:13 fdobridge: <r​edsheep> It looks like I do have rebar working, my BAR 1 is 32 GB
00:14 fdobridge: <g​fxstrand> Even with ReBAR, the kernel can still move stuff for $reasons and that can race with the map.
00:14 fdobridge: <g​fxstrand> Even with ReBAR, the kernel can still move stuff for $reasons and that can race with the fault handler. (edited)
01:21 fdobridge: <a​irlied> at least in the case I'm chasing looks like we stop getting irqs for some reason after evicting
01:52 fdobridge: <g​fxstrand> That would explain some of the full system GPU stops I'm seeing.
02:27 fdobridge: <g​fxstrand> The whole thing seems to just go out to lunch until eventually something goes wrong enough that the kernel driver starts bugging.
06:19 fdobridge: <a​irlied> after a day of staring at it, I have to say I've even less idea what is screwing up 😛
07:03 fdobridge: <a​irlied> added a printf and now it never evicts at all, love it
07:20 fdobridge: <g​fxstrand> 😭
07:30 fdobridge: <g​fxstrand> This one is entertaining. Why are we calling `nvkm_ioctl()` inside of a fault handler?!?
07:30 fdobridge: <g​fxstrand> https://cdn.discordapp.com/attachments/1034184951790305330/1211938471162150962/message.txt?ex=65f004a8&is=65dd8fa8&hm=f6c4931c935cc07bc838357156b3a6a6900a7281a23bd3a6159a99ea9228e419&
07:31 fdobridge: <g​fxstrand> I guess they all are
07:31 fdobridge: <g​fxstrand> Is it weird that that feels sketchy?
07:43 fdobridge: <g​fxstrand> Oh, here's a new one I haven't seen before:
07:43 fdobridge: <g​fxstrand> `[ 1439.369378] nouveau 0000:65:00.0: fifo: PBDMA0: 80004000 [GPPTR SIGNATURE] ch 4 [017f657000 deqp-vk[3095]] subc 0 mthd 0000 data 00000000`
07:46 fdobridge: <!​DodoNVK (she) 🇱🇹> This almost looks like the old OW2 crash
08:20 fdobridge: <k​arolherbst🐧🦀> soooooooo..... there is something interesting about that one
08:21 fdobridge: <k​arolherbst🐧🦀> either your push buffers are corrupted (which they shouldn't, because that's still verified they aren't, right?), which either means the GPU got confused and accesses random memory for processing or the kernel screwed up either memory management or the ringbuffer for
08:21 fdobridge: <k​arolherbst🐧🦀> pushbuffers
08:21 fdobridge: <k​arolherbst🐧🦀> or fencing
08:23 fdobridge: <k​arolherbst🐧🦀> but like.. if the userspace side is sound, it's definitely a kernel bug
08:25 fdobridge: <t​om3026> a quote from torvalds. "WE DO NOT BREAK USERSPACE!" then you know where the fault lies 😄
08:26 fdobridge: <t​om3026> on a more serious note is there any docs what all these Xid NUMBER actually means/hints at? or is that all nvidia internal info
08:26 fdobridge: <k​arolherbst🐧🦀> I think it's the channel id
08:32 fdobridge: <!​DodoNVK (she) 🇱🇹> I wonder if getting Xid 109 on NVK is possible :triangle_nvk:
08:32 fdobridge: <a​irlied> @gfxstrand that is normal, nvkm_ioctl is the interface between the nouveau code and the nvkm code
08:34 fdobridge: <t​om3026> oh look https://docs.nvidia.com/deploy/pdf/XID_Errors.pdf there is "some" docs atleast
08:36 fdobridge: <t​om3026> i think i so far only seen 13 and 32 occur
08:41 fdobridge: <k​arolherbst🐧🦀> ohhh
08:43 fdobridge: <!​DodoNVK (she) 🇱🇹> https://docs.nvidia.com/deploy/xid-errors/index.html
08:55 fdobridge: <c​langcat> But gotta go shopping for toiletries and shoes.
08:55 fdobridge: <c​langcat> Wait thus isn't wife
08:56 fdobridge: <!​DodoNVK (she) 🇱🇹> ~~nouveau merch when?~~
08:56 fdobridge: <c​langcat> Nouveau branded toiletries. XD
08:56 fdobridge: <t​om3026> flush the bugs away one dump at a time
09:43 fdobridge: <S​id> 👀
11:00 bremby: Hi. I'm looking for some support with some graphical artifacts I'm getting. Here's my post on ArchForums: https://bbs.archlinux.org/viewtopic.php?id=292832 Any help would be appreciated :)
11:05 karolherbst: bremby: "nouveau.config=NvGspRm=1" might help, but I think there is some weird fencing going wrong, but no clue yet whos fault that is
11:06 karolherbst: also.. might be better on a wayland compositor as well
11:06 bremby: karolherbst: where do I put that line? :D
11:07 karolherbst: kernel command line
11:07 bremby: ok, any bad side effects that I might expect, or is it completely safe to try?
11:08 karolherbst: nouveau might not load if you are missing the firmware, might cause other issues, but you can always recover by removing in inside the grub menu or booting wiht `nouveua.noaccel=1`
11:09 karolherbst: but a side effect should be, that it would also reduce power consumption when using the nvidia GPU or give you more perf when you need it
11:09 karolherbst: so my hope is, that it just speeds up the GPU enough you won't see those artefacts
11:09 bremby: ok, I'll try, thanks
11:10 karolherbst: _but_ I think something with synchronization is borked between amdgpu and nouveau and I don't think anybody knows what's up there, as it seems to work with intel + nouveau
11:10 karolherbst: might also be just an unfixable bug in X
11:10 bremby: btw, is there no way to simply force the same refresh that happens when I simply move focus from one monitor to the other?
11:10 karolherbst: what do you mena?
11:10 karolherbst: *mean
11:12 bremby: well I have a laptop with its internal display and a large 4K monitor. These artefacts appear on the monitor only, not on the display. When I type on the monitor and see the artefacts, all I need to do to remove them is to just switch focus to a window on the laptop display
11:12 karolherbst: mhhh...
11:12 bremby: on i3 that just means moving my mouse to the display, or just using MOD+<screen number>
11:13 karolherbst: sounds like something X related maybe? Dunno for sure
11:13 karolherbst: could be that it forces something it otherwise doesn't
11:13 karolherbst: but also feels like something which would be very expensive to always do
11:14 karolherbst: all the multi monitor stuff is pretty bonkers in X anyway
11:14 bremby: so I've heard :D
11:16 karolherbst: you could try with sway just to see if wayland would be any better there
11:16 fdobridge: <t​om3026> wayland was on par with the nvidia blob on my 5800 ryzen and 3060 dgpu using multi monitor, never checked on X
11:17 fdobridge: <t​om3026> besides the obvious vulkan/wine/CTS issues
11:18 fdobridge: <t​om3026> and i couldnt do 144hz over hdmi, which the blob did. https://gitlab.freedesktop.org/drm/nouveau/-/issues/307 but as @redsheep mentioned is probably some reduced modeline or what he called it that nouveau doesnt quite implent yet
11:18 karolherbst: oh yeah.. that issue
11:19 karolherbst: booting with `drm.debug=0x6` should tell
11:22 fdobridge: <t​om3026> well i sadly cant, i kinda poured water all over it. soon a month ago. it didnt grow to a 21" doing so worth noting. so im now on a legion 7i using USB-C -> DP
11:22 karolherbst: pain
11:25 fdobridge: <t​om3026> a bit but gave me reason to really upgrade to a proper laptop heh, the 13900hx and 4080 is HEAPS faster then that one
11:25 fdobridge: <t​om3026> almost desktop worthy performance in a bring a long format to when spending time elsewhere
11:26 bremby: karolherbst: the kernel param "nouveau.config=NvGspRm=1" didn't work :(
11:27 karolherbst: like no change or it failed to load nouveau?
11:28 bremby: no change that I can see
11:28 bremby: nouveau is loaded and the kernel param shows up in /proc/cmdline
11:30 fdobridge: <S​id> inb4 this is because of a lack of DSC
11:30 karolherbst: nah, it has nothing to do with DSC
11:30 karolherbst: bremby: yeah... well, the only thing I could suggest then is to try sway
11:31 karolherbst: bremby: though if "nouveau.config=NvGspRm=1" doesn't cause issues, you should just keep it :D
11:31 bremby: okay, I'll see how I can run sway. I've never run any wayland compositor before, so it'll take me some time to figure out
11:31 bremby: and thanks, I'll keep the kernel param, then :)
11:33 bremby: uhhh
11:33 bremby: ArchWiki says this: Note: All proprietary graphics drivers are not supported, including NVIDIA. After NVIDIA driver version 495, sway works if you enable kernel mode setting and run sway with --unsupported-gpu.
11:33 bremby: should I proceed?
11:33 karolherbst: sure
11:33 karolherbst: that's just for the blob driver
11:33 bremby: ok, thx
13:13 fdobridge: <k​arolherbst🐧🦀> I really dislike the ioctl code in `libdrm` :ferrisUpsideDown: but most of the cursedness is because it's outside of mesa, but anyway, the new code will be much better even if it remains like libdrm at heart, just less cursed
14:28 fdobridge: <g​fxstrand> I'm pretty sure something kernel side is screwing up my ring.
14:28 fdobridge: <k​arolherbst🐧🦀> yeah... and I'm sure this is the bug everybody is randomly hitting in one of the other way
14:30 fdobridge: <k​arolherbst🐧🦀> but I gotta say, kernel screwing up the push buffer ring is probably the best explanation for all the funkyness
14:34 fdobridge: <g​fxstrand> Yup
14:36 fdobridge: <g​fxstrand> I mean, it's possible I've got some races somewhere in NVK but also, if I'm racing my own maps, I should be getting SIGBUS or similar, not killing the kernel.
14:36 fdobridge: <k​arolherbst🐧🦀> yeah...
14:36 fdobridge: <k​arolherbst🐧🦀> what if you always allocate a new bo for new content and never reuse old ones? 😄
14:37 fdobridge: <g​fxstrand> It's almost possible I'm stomping my own ring (it is mapped into my address space) but I'd think that would show up in serial runs.
14:37 fdobridge: <g​fxstrand> The kernel doesn't zero things so garbage
14:38 fdobridge: <g​fxstrand> The kernel doesn't zero things, so garbage (edited)
14:38 fdobridge: <k​arolherbst🐧🦀> but then it would be userspace messing up
14:38 fdobridge: <k​arolherbst🐧🦀> I have a very cursed idea
14:38 fdobridge: <k​arolherbst🐧🦀> what if we let the kernel also validate the push buffer on request?
14:38 fdobridge: <k​arolherbst🐧🦀> though no idea how that would actually work...
14:39 fdobridge: <g​fxstrand> Maybe I should port up OGK and see if that's more stable. 😝
14:39 fdobridge: <k​arolherbst🐧🦀> do they even support kernel space submission still?
14:40 fdobridge: <g​fxstrand> I can submit from userspace
14:40 fdobridge: <k​arolherbst🐧🦀> well.. it would still help with checking if it's the kernels fault or not probably
14:41 fdobridge: <g​fxstrand> Yeah, IDK that it's worth it to do that this week but there may be some utility to doing so at some point.
14:42 fdobridge: <g​fxstrand> But also, we know nouveau.ko is blowing up in map faults so we should start by fixing that.
14:44 fdobridge: <k​arolherbst🐧🦀> yeah
14:44 fdobridge: <!​DodoNVK (she) 🇱🇹> And finally resurrect the really old NVK MR :nouveau:
14:47 fdobridge: <k​arolherbst🐧🦀> `double free or corruption (fasttop)` :ferrisCry:
14:52 fdobridge: <!​DodoNVK (she) 🇱🇹> What is fasttop? And is there a fastbottom?
14:52 fdobridge: <k​arolherbst🐧🦀> I have no idea
15:36 fdobridge: <g​fxstrand> ESO let's gooooooo!.....
15:37 fdobridge: <S​id> Elder Scrolls Online?
15:38 fdobridge: <S​id> 🏃‍♀️
15:39 fdobridge: <g​fxstrand> IDK. Do we play Elder Scrolls Online yet?
15:42 fdobridge: <S​id> good question... I couldn't get the EGS copy going when I last tried because I didn't have the patience to figure out what the launcher expected from my wine prefix
15:43 fdobridge: <r​hed0x> iirc it uses d3d11,... so probably?
15:45 fdobridge: <g​fxstrand> For those who are looking for easy tasks: https://gitlab.freedesktop.org/mesa/mesa/-/issues/?scope=all&state=opened&label_name%5B%5D=NVK&label_name%5B%5D=difficulty%3A%20easy
15:45 fdobridge: <p​avlo_it_115> Wow
15:45 fdobridge: <r​hed0x> thanks I'll take a look later :happy_gears:
15:45 fdobridge: <g​fxstrand> If those look easy for you, then leave them for someone newer. 🙂
15:47 fdobridge: <k​arolherbst🐧🦀> ohh subgroup rotate
15:48 fdobridge: <p​avlo_it_115> Will I be able to do something there with my knowledge 🤣 ?)
15:48 fdobridge: <k​arolherbst🐧🦀> unrelated to rotate, but I'm still curious why the intel subgroup rotate things are implemented in their own way 🥲
15:50 fdobridge: <g​fxstrand> Probably
15:50 fdobridge: <g​fxstrand> Intel is magic
15:50 fdobridge: <k​arolherbst🐧🦀> yeah sure
15:50 fdobridge: <k​arolherbst🐧🦀> but I couldn't figure out what's the difference of those spirv ops
15:50 fdobridge: <k​arolherbst🐧🦀> as they kinda sound like the same thing?
15:51 fdobridge: <g​fxstrand> I don't necessarily expect you to be able to do those on your own but they're all simple enough that it'll mostly be crawling around in the code and learning things.
15:51 fdobridge: <k​arolherbst🐧🦀> uhh.. I think I'm gonna port to `VM_BIND` tomorrow :ferrisUpsideDown:
15:51 fdobridge: <k​arolherbst🐧🦀> at least libdrm_nouveau is now fully dropped
15:52 fdobridge: <k​arolherbst🐧🦀> and the imported code doesn't have this cursed ioctl indirection stuff going on
15:52 fdobridge: <g​fxstrand> 🥳
15:54 fdobridge: <k​arolherbst🐧🦀> I haven't tested anything besides glxgears through prime, but hey.. at least that still works
15:55 fdobridge: <k​arolherbst🐧🦀> I think I'm gonna ditch _some_ code, but I left quite a bunch, because like.. `nv30` still needs relocs and stuff
15:55 fdobridge: <k​arolherbst🐧🦀> so uhh...
15:55 fdobridge: <k​arolherbst🐧🦀> that might be painful
15:55 fdobridge: <k​arolherbst🐧🦀> do we have any chipset restriction on `VM_BIND`?
16:00 fdobridge: <m​henning> @gfxstrand When you get a chance, I'd appreciate review for 27798, 27742, and 27595
16:27 fdobridge: <g​fxstrand> Yeah, I'm looking at them. I was trying to CTS them and I keep fighting kernel death. 😩
16:30 fdobridge: <p​homes_> I think that we can just drop the patch for Baldur's Gate 3. It is just a warning that they show
16:30 fdobridge: <p​rop_energy_ball> the mid-review oops!!!
16:34 fdobridge: <t​om3026> is there any linux native games that actually does this? otherwise dxvk/dxvk-nvapi etc already has features to override vendor/version etc
16:37 fdobridge: <p​homes_> Baldur's Gate 3 and X4 Foundations are both using vulkan directly
16:38 fdobridge: <t​om3026> oh hm never considered how vulkan games does in wine, is it straight to the drivers?
16:38 fdobridge: <p​homes_> not sure if they use dxvk in some way still? I launch them through steam
16:39 fdobridge: <t​om3026> d3d9/10/11/12 through dxvk/vkd3d atleast has overrides :p
16:39 fdobridge: <p​homes_> how do I use that?
16:40 fdobridge: <t​om3026> https://github.com/doitsujin/dxvk/blob/master/dxvk.conf#L49
16:40 fdobridge: <p​avlo_it_115> I think there is a layer there
16:40 fdobridge: <t​om3026> hm i thought it had version too
17:00 fdobridge: <p​homes_> I did the sensible thing, and wrote to the X4 authors to see if they can drop the driver version check if nvk is the driver
17:17 fdobridge: <m​ohamexiety> larian are also responsive so you could talk to them too regarding BG#
17:17 fdobridge: <m​ohamexiety> larian are also responsive so you could talk to them too regarding BG3 (edited)
17:18 fdobridge: <m​ohamexiety> and yeah baldur's gate 3 is both vulkan or dx11. I haven't played it on linux but I guess on linux they only expose the vulkan backend
17:18 fdobridge: <m​ohamexiety> (as I'd think there wouldn't be much of a point to go through dxvk if you have native vulkan)
17:20 fdobridge: <d​adschoorse> no, you can use d3d11. it's even the default on deck iirc
17:21 fdobridge: <d​adschoorse> their d3d11 backend has fewer bugs than the vulkan one, but I think both work on radv now
17:21 fdobridge: <r​hed0x> isn't that another case where d3d11 is actually faster than the Vulkan renderer?
17:21 fdobridge: <r​hed0x> like CS2 (:c)
17:22 fdobridge: <m​ohamexiety> huh.. I see. TIL. I had slightly better perf on Vulkan on windows myself, so didn't think it'd be different here. my bad
17:42 fdobridge: <p​avlo_it_115> While vk-cts is being compile, I thought here.. It is still necessary to compile Linux-git
17:42 fdobridge: <p​avlo_it_115> https://cdn.discordapp.com/attachments/1034184951790305330/1212092364777193533/Screenshot_20240227_194021.png?ex=65f093fb&is=65de1efb&hm=0755f101fb9069490e10e19425cc2cabae44769f9388c8d4cc1e9c405e18d7ab&
17:42 fdobridge: <p​avlo_it_115> While vk-cts is being compile, I thought here.. It is still necessary to compile linux-git, yes? (edited)
17:42 fdobridge: <p​avlo_it_115> https://cdn.discordapp.com/attachments/1034184951790305330/1212092364777193533/Screenshot_20240227_194021.png?ex=65f093fb&is=65de1efb&hm=0755f101fb9069490e10e19425cc2cabae44769f9388c8d4cc1e9c405e18d7ab&
17:42 fdobridge: <g​fxstrand> Nah, anything 6.6 or later should have the basics
17:42 fdobridge: <g​fxstrand> If you can get a 6.8 rc, that'd be best
17:44 fdobridge: <p​avlo_it_115> Ok, I'll just compile the kernel :-Р https://aur.archlinux.org/packages/linux-git
17:47 fdobridge: <!​DodoNVK (she) 🇱🇹> Aka linux-mainline
17:48 fdobridge: <p​avlo_it_115> Wow, I didn't even notice that package
17:48 fdobridge: <p​avlo_it_115> thx
18:08 fdobridge: <p​avlo_it_115> I compiled vk-cts, but there is no binary file here.. How to run test?
18:08 fdobridge: <p​avlo_it_115> https://cdn.discordapp.com/attachments/1034184951790305330/1212099005681770526/1f333f48e00aeb04.png?ex=65f09a2a&is=65de252a&hm=ca239b764368aa83f744f08116da8d9f30737bc1380bbef53557497779608b6d&
18:12 fdobridge: <z​mike.> it's in external/vulkancts/modules/vulkan
18:13 fdobridge: <z​mike.> the command is something like `deqp-vk -n <testname>`
18:14 fdobridge: <p​avlo_it_115> Thank you!
18:20 fdobridge: <a​irlied> @karolherbst vmbind is meaningless pre nv50, and I suspect might have undiscovered issues in the nv50-nvc0 space
18:20 fdobridge: <k​arolherbst🐧🦀> yeah... I wouldn't be surprised
18:25 fdobridge: <k​arolherbst🐧🦀> btw.. I found more stuff missing from the UAPI headers...
18:25 fdobridge: <k​arolherbst🐧🦀> `struct drm_nouveau_notifierobj_alloc` e.g.
18:25 fdobridge: <k​arolherbst🐧🦀> it's used in nv30 and nv50
18:30 fdobridge: <a​irlied> I'd really only port nvc0 to vmbind I don't think we care about modifiers on nv50
18:34 fdobridge: <k​arolherbst🐧🦀> yeah.... that's what I'm leaning towards as well
18:46 fdobridge: <a​irlied> @karolherbst will you keep libdrm_nouveau for those or reimplement it anyways?
18:48 fdobridge: <t​riang3l> There's a list of options in the end of <https://github.com/KhronosGroup/VK-GL-CTS/blob/main/external/vulkancts/README.md>, `-n` is a shortcut for `--deqp-case=` (which supports wildcards). Finding case names isn't very convenient, but there are lists of combinations in the `mustpass` directory. Many tests are in `api.txt` and (for graphics) the `pipeline` directory, but there are also various feature-specific lists
18:49 fdobridge: <g​fxstrand> And you can get a list of everything by running with `--deqp-runmode=txt-caselist`
18:54 fdobridge: <t​riang3l> There's a list of options at the end of <https://github.com/KhronosGroup/VK-GL-CTS/blob/main/external/vulkancts/README.md>, `-n` is a shortcut for `--deqp-case=` (which supports wildcards). Finding case names isn't very convenient, but there are lists of combinations in the `mustpass` directory. Many tests are in `api.txt` and (for graphics) the `pipeline` directory, but there are also various feature-specific lists (edited)
18:56 fdobridge: <g​fxstrand> @airlied @karolherbst Any feedback you have is welcome:
18:56 fdobridge: <g​fxstrand>
18:56 fdobridge: <g​fxstrand> https://paste.centos.org/view/86e9dbb2
18:56 fdobridge: <g​fxstrand>
18:56 fdobridge: <g​fxstrand> Or anyone else involved in NVK development, really.
18:58 fdobridge: <a​irlied> Lgtm
19:07 fdobridge: <k​arolherbst🐧🦀> looks good
19:08 fdobridge: <k​arolherbst🐧🦀> that reminds me, I should do some conformance submissions as well :ferrisUpsideDown:
19:08 fdobridge: <p​homes_> 👍
19:09 fdobridge: <r​edsheep> Line 11 says turing is gtx 1060, I think you meant gtx 1600
19:10 fdobridge: <r​edsheep> Let's not get people's hopes up for Pascal lol
19:10 fdobridge: <S​id> pascal ⚰️
19:12 fdobridge: <p​avlo_it_115> :evil_gears:
19:12 fdobridge: <m​ohamexiety> yup, looks good
19:21 fdobridge: <S​id> out of curiosity, is it ok to now start mentioning X game no launchy
19:22 fdobridge: <k​arolherbst🐧🦀> It was always okay, you just had to fix it yourself 😛
19:23 fdobridge: <S​id> what if I told you it's the only game preventing me from switching to nvk full time 👀
19:27 fdobridge: <z​mike.> sounds like you've got ample motivation to fix it yourself
19:28 fdobridge: <S​id> I don't mind trying as long as I can get pointers, yeah
19:29 fdobridge: <!​DodoNVK (she) 🇱🇹> Hopefully they aren't NULL
19:29 fdobridge: <S​id> because funny things: the game doesn't output anything in a DXVK log, and proton log spams this block
19:29 fdobridge: <S​id> ```
19:29 fdobridge: <S​id> 2646.306:0124:014c:warn:seh:dispatch_exception backtrace: --- Exception 0xc000001d.
19:29 fdobridge: <S​id> 2646.306:0124:014c:trace:seh:dispatch_exception code=c000001d flags=0 addr=0000000141FFE178 ip=141ffe178
19:29 fdobridge: <S​id> 2646.306:0124:014c:warn:seh:dispatch_exception EXCEPTION_ILLEGAL_INSTRUCTION exception (code=c000001d) raised
19:29 fdobridge: <S​id> 2646.306:0124:014c:trace:seh:dispatch_exception rax=0000000000286122 rbx=0000000000286122 rcx=0000000000000001 rdx=0000000001000000
19:29 fdobridge: <S​id> 2646.306:0124:014c:trace:seh:dispatch_exception rsi=0000000000000038 rdi=09b0e885b4c6a1c4 rbp=00000000033be960 rsp=00000000033be858
19:29 fdobridge: <S​id> 2646.306:0124:014c:trace:seh:dispatch_exception r8=0000000000286122 r9=000000007ffe0320 r10=000000007ffe0328 r11=0000000000000206
19:29 fdobridge: <S​id> 2646.306:0124:014c:trace:seh:dispatch_exception r12=0000000000000000 r13=0000000000000001 r14=000000000000000d r15=00ffffffffffffff
19:29 fdobridge: <S​id> 2646.306:0124:014c:trace:seh:call_vectored_handlers calling handler at 00006FFFFC9DC760 code=c000001d flags=0
19:29 fdobridge: <S​id> 2646.306:0124:014c:trace:seh:call_vectored_handlers handler at 00006FFFFC9DC760 returned 0
19:29 fdobridge: <S​id> 2646.306:0124:014c:trace:seh:call_vectored_handlers calling handler at 0000000141FFE170 code=c000001d flags=0
19:29 fdobridge: <S​id> 2646.306:0124:014c:trace:seh:call_vectored_handlers handler at 0000000141FFE170 returned ffffffff```
19:29 fdobridge: <S​id> (to all my friends on IRC, I'm sorry)
19:29 fdobridge: <p​avlo_it_115> Is NVK good for maxwell?
19:30 fdobridge: <p​avlo_it_115> Well then I'll collect on gtx 1650
19:30 fdobridge: <p​avlo_it_115> Well then I'll raise money for gtx 1650 (edited)
19:30 fdobridge: <r​edsheep> Once the compiler support is done it's going to be the same old performance issue
19:30 fdobridge: <!​DodoNVK (she) 🇱🇹> Pre-Turing support isn't in the best shape
19:30 fdobridge: <p​avlo_it_115> Well then I'll raise money for gtx 1650
19:31 fdobridge: <p​avlo_it_115> It also needs a new power supply. (edited)
19:31 fdobridge: <p​avlo_it_115> Well then I'll raise money for gtx 1650
19:31 fdobridge: <p​avlo_it_115> It also needs a new power supply..... = ) (edited)
19:35 fdobridge: <!​DodoNVK (she) 🇱🇹> This error needs to be fixed before !27024 can be merged:
19:35 fdobridge: <!​DodoNVK (she) 🇱🇹> ```
19:35 fdobridge: <!​DodoNVK (she) 🇱🇹> ../src/vulkan/runtime/vk_pipeline.c:572:47: error: '_Static_assert' with no message is a C2x extension [-Werror,-Wc2x-extensions]
19:35 fdobridge: <!​DodoNVK (she) 🇱🇹> static_assert(TESS_SPACING_UNSPECIFIED == 0);
19:35 fdobridge: <!​DodoNVK (she) 🇱🇹> ```
20:24 fdobridge: <g​fxstrand> ugh... Why is that not failing for me?!?
20:24 fdobridge: <S​id> okay, this is funny. the game does launch if I use wined3d + zink
20:24 fdobridge: <!​DodoNVK (she) 🇱🇹> Do you use clang?
20:25 fdobridge: <g​fxstrand> No. Does GCC not have `static_assert`?
20:26 fdobridge: <S​id> also we really should figure out reporting the GPU better, this game detected my 1660Ti as a GeForce 470 😅
20:30 fdobridge: <!​DodoNVK (she) 🇱🇹> WineD3D issue
20:31 fdobridge: <S​id> either way, something's funny if the game launches on wined3d+zink but not directly over nvk+dxvk
20:31 fdobridge: <S​id> somewhere, somehow
20:33 fdobridge: <r​edsheep> Does it work with old versions of dxvk, like 1.10.3?
20:33 fdobridge: <S​id> no
20:34 fdobridge: <!​DodoNVK (she) 🇱🇹> How about v1.5.1?
20:34 fdobridge: <S​id> ..
20:34 fdobridge: <S​id> *sigh*
20:34 fdobridge: <r​edsheep> If there's an old version where it does work you can find where it first broke and find out what feature that version starts touching
20:35 fdobridge: <S​id> right
20:35 fdobridge: <S​id> I'll just try out increasingly older proton versions I guess
20:35 fdobridge: <S​id> though
20:35 fdobridge: <S​id> could run into unrelated issues that way
20:35 fdobridge: <s​unrise_sky> @marysaka I've heard you could use some help with mesh shaders. Is this a good place to talk about that?
20:37 fdobridge: <r​edsheep> Yeah, it's doable to set it up yourself to avoid that. I'd assume there's some issue with a feature dxvk touches that wined3d>zink doesn't
20:43 fdobridge: <g​fxstrand> Should I say something about Zink? Maybe something like this:
20:43 fdobridge: <g​fxstrand> > We are also actively triaging the remaining Zink bugs to provide OpenGL 4.6 on top of NVK via Zink. While the old nouveau GL driver will continue to exist and work as well as it ever has, we expect Zink+NVK to be the path forward for modern NVIDIA GPUs.
20:47 fdobridge: <a​irlied> yeah a zink shoutout would be good
20:48 fdobridge: <S​id> still the same with dxvk 1.5.1
20:51 fdobridge: <!​DodoNVK (she) 🇱🇹> I guess the only option is to try to make and replay an apitrace then
20:52 fdobridge: <g​fxstrand> How about this?
20:52 fdobridge: <g​fxstrand> > For OpenGL support, we are still expecting Zink + NVK to be the plan going
20:52 fdobridge: <g​fxstrand> > forward. Not everything works yet but we are also actively triaging the
20:52 fdobridge: <g​fxstrand> > remaining Zink bugs to provide OpenGL 4.6 on top of NVK via Zink. While the
20:52 fdobridge: <g​fxstrand> > old nouveau GL driver will continue to exist and work as well as it ever
20:52 fdobridge: <g​fxstrand> > has, we expect Zink + NVK to surpass it both in terms of performance as
20:52 fdobridge: <g​fxstrand> > well as features and stability.
20:54 fdobridge: <k​arolherbst🐧🦀> sounds good
21:04 fdobridge: <m​arysaka> Sure, I do have one major blocker so far:
21:04 fdobridge: <m​arysaka> NVIDIA hardware only support up to 32 local invocations and 128 is the min required by spec.
21:04 fdobridge: <m​arysaka> So I need some way to handle multiple invocations per hardware invocations while respecting barrier 😅
21:06 fdobridge: <S​id> so I got it to launch with wined3d's vulkan backend
21:06 fdobridge: <S​id> freezes on a loading screen and crashes but does launch
21:07 fdobridge: <r​edsheep> Is it clear that the remaining issues here are zink bugs? If not it might be better to just leave it at "remaining bugs"
21:07 fdobridge: <g​fxstrand> There's probably some NVK bugs, too. I consider the bucket of "Zink bugs" in the context of that blog post to include NVK bugs affecting Zink.
21:10 fdobridge: <S​id> anyhoo, @gfxstrand is there a better way I can try and debug this? dxvk logs aren't telling me anything, but the game does launch on pure nvk + wined3d-vulkan as well as an nouveau+zink
21:10 fdobridge: <S​id> only doesn't on nvk+dxvk
21:11 fdobridge: <s​unrise_sky> Yes, I've heard about that too. I have a few ideas on what to do about it, but am also curious where you are at
21:11 fdobridge: <g​fxstrand> Ugh... Illegal instruction is so not helpful. 😕
21:11 fdobridge: <r​hed0x> @tiredchiku apitrace and try replaying the apitrace with nvk
21:12 fdobridge: <r​hed0x> if that crashes replay the apitrace with --verbose
21:12 fdobridge: <g​fxstrand> Yeah, that's not a bad idea
21:12 fdobridge: <S​id> game's anti cheat does not like apitrace
21:12 fdobridge: <r​hed0x> oh right, multiplayer game
21:12 fdobridge: <r​hed0x> does the ac even notice apitrace?
21:12 fdobridge: <S​id> apparently, blisto just tried it out on LGD#wine
21:12 fdobridge: <!​DodoNVK (she) 🇱🇹> I don't think that works with exotic games like GTA 5 or NFS 2015
21:13 fdobridge: <r​hed0x> maybe try the same thing but with gfxreconstruct on nv prop
21:14 fdobridge: <S​id> okie, I'll try that
21:16 fdobridge: <p​homes_> is perfetto support something we want in nvk?
21:17 fdobridge: <g​fxstrand> If it helps, sure.
21:17 fdobridge: <S​id> perfetto.. that google profiling tool?
21:19 fdobridge: <s​unrise_sky> @marysaka My idea would be to write a NIR pass, conceptually similar to `ac_nir_lower_ngg_ms` (but obviously catering to hw differences) which would lower the shader to something the HW can run. In this pass, I'd write some code to take the shader apart along barriers and insert loops around the parts (with a few extra steps when a barrier is in CF).
21:19 fdobridge: <g​fxstrand> Yeah, @Mary and I talked some about how to do just that. Splitting around barriers is a giant PITA but it should be possible.
21:20 fdobridge: <g​fxstrand> Annoyingly, it has a similar level of complexity as the return lowering pass for ray-tracing.
21:20 fdobridge: <g​fxstrand> Yeah, @marysaka and I talked some about how to do just that. Splitting around barriers is a giant PITA but it should be possible. (edited)
21:20 fdobridge: <p​homes_> yes
21:21 fdobridge: <g​fxstrand> Based on a discussion from the Khronos meetings last week, there may also be some utility in that pass for Compute shaders as well.
21:21 fdobridge: <s​unrise_sky> One of the conclusions from doing these things for RADV is that it's immeasurably better to do this sort of stuff in NIR than in any backend IR
21:22 fdobridge: <g​fxstrand> Yeah....
21:26 fdobridge: <m​arysaka> I had no luck getting something working (mostly hitting my teeth on `nir_cf*`) 😅
21:26 fdobridge: <m​arysaka> (as I was relying on cursor changing as I extract logic)
21:26 fdobridge: <s​unrise_sky> I would be happy to give this a try sometime this week. What do you think?
21:27 fdobridge: <!​DodoNVK (she) 🇱🇹> How many of the performance blockers have been fixed in NVK?
21:28 fdobridge: <s​unrise_sky> I would be happy to give this a try sometime this week. What do you think? Or do you prefer doing it yourself?
21:29 fdobridge: <m​arysaka> If you feel like it go ahead 👍, I'm still on working float16 and cooperative matrix right now
21:29 fdobridge: <m​arysaka> The MR is here https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27196
21:29 fdobridge: <a​irlied> do you have a list?
21:30 fdobridge: <r​hed0x> if anyone has a list its gotta be either you or faith
21:30 fdobridge: <s​unrise_sky> Do you have the same problem with the EXT as NVidia's driver has, regarding copy-propagating the output variables?
21:31 fdobridge: <a​irlied> my list is and will always be ZCULL until someone writes ZCULL support 🙂
21:31 fdobridge: <r​hed0x> whats zcull? early z-test?
21:31 fdobridge: <r​hed0x> I've tried googling it before and all mentions of it just sounded like early-z
21:32 fdobridge: <!​DodoNVK (she) 🇱🇹> https://www.collabora.com/news-and-blog/news-and-events/nvk-update-enabling-new-extensions-conformance-status-more.html
21:33 fdobridge: <a​irlied> yeah I think it's mostly just early-z type stuff
21:34 fdobridge: <a​irlied> I think @gfxstrand has fixed a lot of those already
21:35 fdobridge: <S​id> oh boy gfxreconstruct, might have to defer start
21:38 fdobridge: <S​id> yippee
21:38 fdobridge: <S​id> 6.3 gig trace acquired
21:39 fdobridge:<z​mike.> laughs in 337000
21:40 fdobridge: <!​DodoNVK (she) 🇱🇹> ~~Zink Petabyte Project when?~~
21:41 fdobridge: <g​fxstrand> Yeah, ZCULL and color compression are quickly making their way to the front of my list.
21:42 fdobridge: <g​fxstrand> I think I may even know how to RE color compression now.
21:42 fdobridge: <g​fxstrand> I think I may even know how to R/E color compression now. (edited)
21:42 fdobridge: <k​arolherbst🐧🦀> zcull is going to be fun
21:42 fdobridge: <S​id> oh
21:42 fdobridge: <S​id> ```
21:42 fdobridge: <S​id> [sidpr@constructor pc]$ gfxrecon-replay gfxrecon_capture_20240228T030157.gfxr
21:42 fdobridge: <S​id> [gfxrecon] WARNING - Extension VK_EXT_surface_maintenance1 is not supported by the replay device and may cause issues during attempted replay
21:42 fdobridge: <S​id> [gfxrecon] FATAL - API call at index: 2 thread: 1 vkCreateInstance returned error value VK_ERROR_EXTENSION_NOT_PRESENT that does not match the result from the capture file: VK_SUCCESS. Replay cannot continue.
21:42 fdobridge: <S​id> [gfxrecon] WARNING - Rendering was restricted to surface index 0, but a surface was never created for that index; replay created 0 surface(s)
21:42 fdobridge: <S​id> Replay has encountered a fatal error and cannot continue: the specified extension does not exist```
21:43 fdobridge: <g​fxstrand> Uh... we might not have surface_maintenance1 yet. I don't know that we have to do any work for it in NVK but I've not looked into it.
21:43 fdobridge: <S​id> welp
21:43 fdobridge: <S​id> I guess I'll have to wait for that then
21:44 fdobridge: <r​hed0x> uh i guess we could make a dxvk build that doesnt use those extensions
21:44 fdobridge: <g​fxstrand> Or you can hack Mesa to turn them on and hope that's good enough.
21:44 fdobridge: <S​id> ..wait a minute
21:44 fdobridge: <S​id> could that be it
21:44 fdobridge: <S​id> could the game be refusing to work because that extension is missing
21:44 fdobridge: <r​hed0x> nah, dxvk will check whether its supported before using it
21:45 fdobridge: <S​id> because
21:45 fdobridge: <!​DodoNVK (she) 🇱🇹> DXVK v1.5.1 definitely doesn't use it
21:45 fdobridge: <S​id> I do have 3 .gfxr files, meaning the game does something dumb with dxgi when putting up its window
21:45 fdobridge: <S​id> which also explains why I have a d3d9 log and no d3d11 log when I try to log this via dxvk
21:45 fdobridge: <r​hed0x> fwiw I dont think radv supports that extension either
21:46 fdobridge: <g​fxstrand> It does
21:47 fdobridge: <s​unrise_sky> @marysaka Another question, how do you deal with task payloads? AFAIK NVidia uses some sort of shared memory for those, which is copied to the mesh shader's shared memory space somehow. Do you use this mechanism or do you implement it some different way?
21:47 fdobridge: <r​hed0x> ctrl+f on mesamatrix let me down then :c
21:47 fdobridge: <r​edsheep> What I had found about zcull from my research sounded more like z compression
21:48 fdobridge: <m​arysaka> I use the same mechanism yes it goes via ISBE
21:48 fdobridge: <m​arysaka> shared memory also use it
21:48 fdobridge: <S​id> tbh, I think I'd like to test this out
21:49 fdobridge: <r​hed0x> sec
21:49 fdobridge: <S​id> I still feel like the game not working is just because of that ext missing on nvk
21:49 fdobridge: <S​id> gut feeling and all that
21:50 fdobridge: <S​id> ...I'm assuming wined3d-vulkan does not use that ext, which is why the game launches when using that
21:50 fdobridge: <r​hed0x> the game worked on dxvk long before that extension existed
21:50 fdobridge: <m​arysaka> I should probably do some writeup about how everything is handled tbh
21:51 fdobridge: <S​id> well, yeah, might just be something else entirely
21:51 fdobridge: <S​id> since I couldn't get it going even with dxvk1.5.1
21:51 fdobridge: <r​hed0x> https://cdn.discordapp.com/attachments/1034184951790305330/1212155040500944917/no_surface_maintenance.zip?ex=65f0ce5a&is=65de595a&hm=d1d9577efb98a53032b16bf4e97ead517a53ac0549e11f3163abff9320486d49&
21:51 fdobridge: <s​unrise_sky> Can you give me some more info on how that works? Your branch doesn't use the shared mem lowering flags for `nir_lower_task_shader`
21:52 fdobridge: <r​edsheep> Is there a vulkan profile for wined3d-vulkan that could be used to highlight the exact extension differences?
21:52 fdobridge: <S​id> just so I'm sure, I have to re-create a gfxreconstruct capture with this, right?
21:52 fdobridge: <S​id> it is 0322
21:52 fdobridge: <S​id> I'm not smart in the evening
21:52 fdobridge: <S​id> I'm not sure...
21:53 fdobridge: <r​hed0x> i dont think just looking at the list of extensions is gonna get us anywhere tbh
21:54 fdobridge: <S​id> tbh
21:54 fdobridge: <S​id> ..nvm, I lost that train of thought before it left the station
21:57 Sid127: ok, placed those dlls in the game folder, time to gfxreconstruct this with winedlloverrides
22:00 Sid127: don't mind me hopping between platforms, opening firefox and waiting for discord.com to load is more annoying than opening weechat in my terminal
22:02 fdobridge: <!​DodoNVK (she) 🇱🇹> What train was it?
22:02 Sid127: something about list of extensions
22:03 Sid127: uhm
22:04 Sid127: ok, I definitely didn't do something wrong
22:05 Sid127: `VK_INSTANCE_LAYERS=VK_LAYER_LUNARG_gfxreconstruct WINEDLLOVERRIDES="dxgi,d3d11=n,b" marigold -npt %command%`
22:05 Sid127: with the DLLs next to the game exe
22:05 Sid127: and yet the replay complains about the same ext
22:05 Sid127: hm
22:07 fdobridge: <r​hed0x> https://cdn.discordapp.com/attachments/1034184951790305330/1212158992529489990/no_surface_maintenance2.zip?ex=65f0d208&is=65de5d08&hm=c69e83bbd131d386c90353fe204ebfe54744349bdb9ae2b6ca744c5fa0c23c48&
22:07 fdobridge: <r​hed0x> idk if the first build had all occurances of the extension removed
22:07 Sid127: fun
22:07 Sid127: be back in.. 10 mins :D
22:11 Sid127: gonna do dll override to n instead of n,b for good measure this time
22:15 Sid127: nope, still the same error sadly
22:18 fdobridge: <r​edsheep> I just can't shake the mental image of @gfxstrand having a fist fight with Marge Simpson today.
22:18 fdobridge: <r​edsheep>
22:18 fdobridge: <r​edsheep> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27024
22:20 fdobridge: <S​id> amazing
22:20 fdobridge: <S​id> anyway, I think I'm gonna stop here for today...
22:20 fdobridge: <!​DodoNVK (she) 🇱🇹> I wonder what's the closest character to Faith in Simpsons 🐸
22:21 fdobridge: <r​edsheep> It's not exactly a show with very many smart people
22:22 fdobridge: <S​id> so there's likely an analog to me
22:25 fdobridge: <S​id> what, there's no token Indian?
22:26 fdobridge: <r​edsheep> Oh there certainly is but... Not a good fit.
22:27 fdobridge: <g​fxstrand> Lisa isn't a total idiot but she's also a bit of a brat so not really me.
22:27 fdobridge: <S​id> ah
22:28 fdobridge: <S​id> @airlied fear me
22:28 fdobridge: <S​id> prime sync bug might be back
22:28 fdobridge: <S​id> when running opengl via zink
22:29 fdobridge: <S​id> I can't test on -rc anymore, since I use zfs, but I'll update to latest 6.7 tag and check again
22:30 fdobridge: <r​hed0x> check the proton log whether it loads your dll
22:30 fdobridge: <r​hed0x> and whether dxvk loads the extension
22:31 fdobridge: <S​id> okie
22:31 fdobridge: <m​ohamexiety> tbh if the extension isn't used you could probably get away with just hacking `nvk_phyiscal_device` to set it to `true`
22:31 fdobridge: <m​ohamexiety> this would let you know if the issue is in that extension or something else
22:32 fdobridge: <S​id> yeah, I'll do that tomorrow..
22:33 fdobridge: <S​id> it does
22:33 fdobridge: <S​id> ```
22:33 fdobridge: <S​id> 494.072:0128:012c:trace:loaddll:build_module Loaded L"Z:\\home\\sidpr\\.local\\share\\Steam\\steamapps\\common\\quakechampions\\client\\bin\\pc\\dxgi.dll" at 00006FFFFBE50000: native
22:33 fdobridge: <S​id> 494.073:0128:012c:trace:loaddll:build_module Loaded L"Z:\\home\\sidpr\\.local\\share\\Steam\\steamapps\\common\\quakechampions\\client\\bin\\pc\\d3d11.dll" at 00006FFFFCB10000: native```
22:33 fdobridge: <S​id> and it does
22:33 fdobridge: <S​id> ```
22:33 fdobridge: <S​id> info: Enabled instance extensions:
22:33 fdobridge: <S​id> info: VK_EXT_surface_maintenance1
22:33 fdobridge: <S​id> info: VK_KHR_get_surface_capabilities2
22:33 fdobridge: <S​id> info: VK_KHR_surface
22:33 fdobridge: <S​id> info: VK_KHR_win32_surface
22:33 fdobridge: <S​id> ```
22:34 fdobridge: <S​id> I could just take a capture from dxvk 1.5.1
22:34 fdobridge: <r​hed0x> ok I am an idiot
22:35 fdobridge: <S​id> nah
22:35 fdobridge: <r​hed0x> (I didnt save the source file before compiling it)
22:35 fdobridge: <r​hed0x> >.<
22:35 fdobridge: <S​id> heh, happens
22:35 fdobridge: <r​hed0x> its late 🙃
22:35 fdobridge: <S​id> I'm not judging, I had to ask if I had to take a new capture with the dlls
22:36 fdobridge: <r​hed0x> in case you wanna give it another go
22:36 fdobridge: <r​hed0x> https://cdn.discordapp.com/attachments/1034184951790305330/1212166404326035466/no_surface_maintenance3.zip?ex=65f0d8ef&is=65de63ef&hm=898e0ad8877e272761e4ec30cbf78477a8d6e9e2f75e96760f16342fb586103b&
22:36 fdobridge: <a​irlied> Yes there are some 6.7.x kernels where it was reintroudced due to regressions, not sure which 6.7.x got the new fix
22:37 fdobridge: <S​id> I'm currently on 6.7.5, I'll check 6.7.6 and let you know soon™️
22:38 fdobridge: <S​id> also rhedox I believe outside of my shitposting and you asking about the x11 nvidia thing last night this is the first time we've properly interacted 🙃
22:39 fdobridge: <!​DodoNVK (she) 🇱🇹> 6.7.5 actually got this (6.7.6 pulls in extra nouveau fixes though)
22:39 fdobridge: <!​DodoNVK (she) 🇱🇹> I mean the fix
22:40 fdobridge: <g​fxstrand> @marysaka Is fp16 ready for another review?
22:41 fdobridge: <m​arysaka> I started addressing some comments you made yesterday but still haven't finished
22:42 fdobridge: <S​id> fresh trace captured, 6.7.6 compiling
22:42 fdobridge: <g​fxstrand> Okay, let me know when you want me to look again.
22:42 fdobridge: <S​id> gonna go watch a youtube video while this compiles and test both things
22:42 fdobridge: <m​arysaka> Will try to wrap that tomorrow
22:42 fdobridge: <S​id> favorite creator released a new patreon exclusive :>
22:55 fdobridge: <r​edsheep> Wooo !27024 merged
22:55 fdobridge: <r​edsheep> That was such a pain to try and carry, so glads that's over
22:57 fdobridge: <r​edsheep> Can't imagine it was fun to rebase so many times either
22:59 fdobridge: <g​fxstrand> It wasn't
22:59 fdobridge: <g​fxstrand> Literally everything that touched pipelines caused conflicts.
22:59 fdobridge: <g​fxstrand> And it still makes CTS blow up more often but I'm 90% sure that's just because it's running more tests and/or they're a bit more mean to whatever thing it is we're doing that makes the kernel fall over.
23:00 fdobridge: <g​fxstrand> All the tests pass so I don't think it's NVK. We just have some flakes and the all-too-frequent kernel death.
23:01 fdobridge: <S​id> what are we missing for vkd3d btw?
23:02 fdobridge: <S​id> can't wait to throw Alan Wake 2 at NVK and see what explodes
23:02 fdobridge: <g​fxstrand> sparse and descriptor buffer
23:02 fdobridge: <a​irlied> how are sparse images looking?
23:05 fdobridge: <r​edsheep> It seems to be coming along on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26719
23:10 fdobridge: <m​ohamexiety> it's done, that branch works. I am just cleaning up atm. there was an implementation detail with `SINGLE_MIPTAIL_BIT` I overlooked that I fixed and will push the latest changes in a bit
23:11 fdobridge: <S​id> :O
23:11 fdobridge: <r​hed0x> and mesh shaders
23:11 fdobridge: <S​id> mesh shaders just got merged
23:11 fdobridge: <S​id> ~30 mins go
23:11 fdobridge: <S​id> ago*
23:11 fdobridge: <r​hed0x> wat, didnt they just talk about how theres still a bunch of challenges with them
23:11 fdobridge: <m​ohamexiety> no that's probably not mesh shaders given the earlier discussion
23:11 fdobridge: <S​id> euh?
23:11 fdobridge: <r​hed0x> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27196
23:12 fdobridge: <r​hed0x> clearly not merged
23:12 fdobridge: <S​id> oh wait
23:12 fdobridge: <S​id> derp
23:12 fdobridge: <S​id> sorry
23:12 fdobridge: <S​id> 0442, I confused mesh shaders with GPL
23:12 fdobridge: <r​hed0x> EXT_ESO + EXT_GPL != mesh shaders :P
23:12 fdobridge: <S​id> this is like a shitty captain's log now
23:13 fdobridge: <r​edsheep> Is anybody working on descriptor buffer? I haven't noticed work around that
23:14 fdobridge: <S​id> I feel terrible for reasons™️ and debugging/testing stuff is helping me distract myself much better than staring at the ceiling in bed would have
23:15 fdobridge: <r​edsheep> Seems like that and RT are the biggest parts that are far from done for the latest games, really exciting
23:15 fdobridge: <m​ohamexiety> hope you feel better soon
23:15 fdobridge: <S​id> thanks
23:16 fdobridge: <S​id> just waiting on zfs dkms module before rebooting
23:17 fdobridge: <m​ohamexiety> not sure if you saw it before but descriptor buffer comes with some interesting challenges on NV: https://discord.com/channels/1033216351990456371/1034184951790305330/1177638160193306704
23:36 fdobridge: <S​id> well
23:36 fdobridge: <S​id> that was a dead end
23:36 fdobridge: <S​id> https://cdn.discordapp.com/attachments/1034184951790305330/1212181562376847472/gfxrecon.log?ex=65f0e70d&is=65de720d&hm=d3abf79f9892c67633506136f66846413d90f2e9772c752da698ddcbd1d3af4f&
23:37 Lyude: https://gitlab.freedesktop.org/lyudess/linux/-/blob/0db221e2a98629b8f41859d3b921b2cc5ac66622/rust/kernel/drm/kms.rs#L18 ← going to send this to dri-devel and friends tomorrow to start getting feedback, but I dumped all of the current plans I have for the kernel's rust KMS bindings here complete with detailed explanations
23:40 fdobridge: <S​id> um.. what
23:40 fdobridge: <S​id> `mesa/src/vulkan/runtime/meson.build:24:23: ERROR: File vk_shader.c does not exist.`
23:41 fdobridge: <S​id> 32 bit builds fine...
23:42 fdobridge: <S​id> o nvm
23:42 fdobridge: <S​id> I see
23:43 fdobridge: <S​id> just dodo's pkgbuild stuff
23:44 fdobridge: <S​id> also kernel 6.7.6 explodes worse than 6.7.5 for me...
23:44 fdobridge: <t​riang3l> yaaay I'm abandoning the common `vk_pipeline_layout` tomorrow! 🥳 🐸
23:46 fdobridge: <!​DodoNVK (she) 🇱🇹> I already removed the problematic code
23:46 fdobridge: <S​id> https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=vulkan-nouveau-git#n62
23:47 fdobridge: <S​id> the rm fails
23:47 fdobridge: <S​id> and, well, memory budget patch is still there
23:50 fdobridge: <S​id> but yeah, looks like this game has a hard dep on sparseResidency
23:50 fdobridge: <S​id> unless that was also not used in dxvk 1.5.1
23:51 fdobridge: <!​DodoNVK (she) 🇱🇹> That's fixed in my other package
23:52 fdobridge: <S​id> ..which other package
23:55 fdobridge: <!​DodoNVK (she) 🇱🇹> https://github.com/Dodo-PKGBUILDs/vulkan-nouveau-git
23:59 fdobridge: <S​id> right, but