00:46 fdobridge: <r​edsheep> I am more than a little surprised that the heaven benchmark still flashes blue on the latest mesa main
00:46 fdobridge: <r​edsheep> Considering main should be passing cts now, right?
00:47 fdobridge: <r​edsheep> Obviously passing cts means absolutely no bugs remain 😛
01:54 fdobridge: <r​inlovesyou> I wish i could get that profiler layer working on dxvk
01:54 fdobridge: <r​inlovesyou> I'll have to check what breaks there & if it works on proprietary
01:54 fdobridge: <r​inlovesyou> Found another game with hilarious slowdowns
01:54 fdobridge: <S​id> have you tried using a debug build of dxvk
01:54 fdobridge: <r​inlovesyou> Yakuza 0
01:55 fdobridge: <r​inlovesyou> Nope, I'll look into that tomorrow or Sunday
01:55 fdobridge: <S​id> if you're using proton experimental, you can switch over to bleeding-edge-debug
01:55 fdobridge: <r​inlovesyou> Does protonup have that?
01:56 fdobridge: <S​id> no idea, I only stick to valve's proton
01:56 fdobridge: <r​inlovesyou> Ah can you get that debug build straight from the official proton repo?
01:56 fdobridge: <r​inlovesyou> Or where
01:58 fdobridge: <r​inlovesyou> Or do i have to build it myself
02:00 fdobridge: <S​id> nope
02:00 fdobridge: <S​id> yup
02:00 fdobridge: <r​inlovesyou> Rip
02:00 fdobridge: <r​inlovesyou> Noted
02:00 fdobridge: <r​inlovesyou> Will do that to investigate what the hell is happening in Yakuza 0
02:02 fdobridge: <r​inlovesyou> It goes from 60 to 15-20 fps when you look at a crowd
02:30 fdobridge: <g​fxstrand> If only...
02:53 fdobridge: <r​edsheep> I think I got renderdoc to work with heaven pretty easily. I was going to try to use it to figure out what was drawing the blue but uh... Renderdoc is complicated
02:56 fdobridge: <a​irlied> catching the flicker is tricky with renderdoc
02:56 fdobridge: <a​irlied> also it's only there with MSAA
03:01 fdobridge: <g​fxstrand> I'm super confused about the fact that it's blue.
03:05 fdobridge: <g​fxstrand> It's weirdly consistent
03:07 fdobridge: <r​edsheep> I think it's some part of sky rendering
03:07 fdobridge: <a​irlied> we used to get blue triangles in heaven
03:08 fdobridge: <g​fxstrand> It's been a long time since I looked at Heaven in detail
03:29 fdobridge: <a​irlied> yeah my impression is blue is possibly the clear color
04:10 fdobridge: <r​edsheep> Last time I was attempting it I think I found some way to get it to be blue more, so I can probably catch it with renderdoc. I will give it a shot tomorrow.
05:23 fdobridge: <g​eorgeouzou> Yes, I have done some things for this, we can do it the "easy" way with texture /sampler indices.
05:23 fdobridge: <g​eorgeouzou> I was trying the other way too by binding the heap as the desc buffer but vkBindDescriptorBuffers makes it too hard for us because it expects raw addresses
05:26 fdobridge: <g​eorgeouzou> I like them 😅, glTexBuffer was the only thing I could use for shader access in Opengl 3.3 back then
07:58 fdobridge: <m​arysaka> oh it runs now? I used to be stuck trying to load my save
07:58 fdobridge: <m​arysaka> (with the context being killed on Yakuza 0 ect)
08:32 fdobridge: <a​huillet> TBOs are a job insurance feature: the complexity of buffer object logic, the complexity of texture logic, the complexity of shared storage, all coupled together by breaking any semblence of orthogonality
08:32 fdobridge: <a​huillet> and you can have texture views too! I hate that and love it at the same time.
08:35 fdobridge: <a​huillet> conceptually the feature makes sense, I'm not criticizing the API design, but the implementation is a minefield of corner case difficulties
15:16 fdobridge: <!​DodoNVK (she) 🇱🇹> Why is NVK dumping almost twice as much SPIR-V shaders as RADV with a clean shader cache?
15:46 fdobridge: <r​inlovesyou> Yeah it certainly runs
16:17 fdobridge: <!​DodoNVK (she) 🇱🇹> And the shader cache folder contains very little files when compared to RADV ⚠️
17:00 fdobridge: <m​henning> Caching isn't fully implemented yet.
17:00 fdobridge: <!​DodoNVK (she) 🇱🇹> In NVK or the common Vulkan code?
17:01 fdobridge: <m​henning> In NVK
17:02 fdobridge: <!​DodoNVK (she) 🇱🇹> Is there a TODO for that? If not then I should create an issue :triangle_nvk:
17:18 fdobridge: <m​henning> mhh, actually now I'm wondering if I'm misunderstanding the state of things
17:24 fdobridge: <m​henning> It definitely seems like we hit cache less often than we should. Looking at the code a little, I'm not sure if we're missing cases where we should be caching intermediate compilation steps or if something is buggy
17:50 fdobridge: <g​fxstrand> Caching should be fine.
17:51 fdobridge: <g​fxstrand> It's probably because we don't do any link optimizations right now.
17:52 fdobridge: <g​fxstrand> Which we should probably fix one of these days. I'm sure it matters for some titles.
17:53 fdobridge: <g​fxstrand> And we have virtually no shader key. RADV has a decent bit.
17:54 fdobridge: <!​DodoNVK (she) 🇱🇹> Why is NVK dumping all the SPIR-V shaders while RADV dumps nothing on a warm cache run though? I'm testing the `MESA_SPIRV_DUMP_PATH` variable
17:54 fdobridge: <g​fxstrand> Right now NVK compiles one binary per unique source shader, modulo one weird MSAS feature no one uses.
17:54 fdobridge: <g​fxstrand> That I don't have a good answer for off-hand.
17:54 fdobridge: <g​fxstrand> That feels wrong
17:55 fdobridge: <g​fxstrand> Oh, maybe I screwed up the disk cache?
18:02 fdobridge: <g​fxstrand> Shouldn't be too hard to figure out with GDB and fossilize
18:26 HdkR: One weird MSAA feature?
19:59 fdobridge: <p​avlo_kozlenko> : D