00:56 fdobridge_: <a​irlied> so how to people test dxvk games? just using steam/proton or building things?
00:59 fdobridge_: <e​sdrastarsis> Proton for Steam games and Lutris/Heroic/Bottles for Non-Steam games
01:21 fdobridge_: <p​homes_> https://cdn.discordapp.com/attachments/1034184951790305330/1192276675174604831/Screenshot_from_2024-01-04_02-12-05.png?ex=65a87d2e&is=6596082e&hm=8a5de14909e5d5b63a139f8fe815b5d99fbba710d9f3a30f9e5262c131015503&
01:28 fdobridge_: <p​homes_> with the rebased pipeline shader cache BG3 is now at least getting this far. I am hitting an assert in nak and also an error message mentioning VkAcquireImageKHR
01:28 fdobridge_: <p​homes_> but it is progress
01:29 fdobridge_: <p​homes_> and noticeable less stutter in serious sam
01:43 fdobridge_: <k​arolherbst🐧🦀> :ferrisBongo:
01:43 fdobridge_: <k​arolherbst🐧🦀> :ferrisBongoHyper:
01:45 fdobridge_: <a​irlied> I'm starting to wonder are phoronix afraid to publish benchmarks because nvidia sponsorship or they just can't get any to run to completion :-
01:45 fdobridge_: <a​irlied> I'm starting to wonder are phoronix afraid to publish benchmarks because nvidia sponsorship or they just can't get any to run to completion 😛 (edited)
01:58 fdobridge_: <k​arolherbst🐧🦀> 😄
01:58 fdobridge_: <k​arolherbst🐧🦀> probably both
04:05 anzel: given a sampled_desc_index/storage_desc_index, would access be through the map member within a nvk_descriptor_table?
15:11 fdobridge_: <g​fxstrand> What's the NAK assert?
15:14 fdobridge_: <p​homes_> https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/nouveau/compiler/nak/assign_regs.rs#L829
15:14 fdobridge_: <g​fxstrand> anzel: It's tricky and the answer is that I'm not really sure yet. The Nvidia implementation indirects through the table just like we do for descriptors today. However, EDB doesn't have buffer views so they end up emitting piles of shader code to deal with those. 😫 The other solution would be to somehow allow the descriptor buffer to be the sampler/image table but that gets tricky for other reasons.
15:14 fdobridge_: <p​homes_> I tried to recreate it with RUST_BACKTRACE=1 but no luck yet
15:15 fdobridge_: <g​fxstrand> Ah, so some lowering/opt pass is going awry.
15:16 fdobridge_: <p​homes_> but also this:
15:16 fdobridge_: <p​homes_> https://cdn.discordapp.com/attachments/1034184951790305330/1192486712115470396/Screenshot_from_2024-01-04_02-50-59.png?ex=65a940cb&is=6596cbcb&hm=e11dd09d9fac03ac37eb18c986132346a61eb564f0355d796d6d28f864f37737&
15:17 fdobridge_: <g​fxstrand> Can you you run it with the fossilize layer and capture the pipelines? That would let me repro the NAK fail.
15:18 fdobridge_: <p​homes_> and also a lot of this in dmesg: fifo: fault 01 [VIRT_WRITE] at 0000000000130000 engine 80 [BAR1] client 08 [HUB/HOST_CPU_NB] reason 02 [PTE] on channel -1 [01ffeca000 unknown]
15:18 fdobridge_: <g​fxstrand> Weird. That's all common code so IDK why that would fail in NVK if it works elsewhere unless it's getting a device lost.
15:23 fdobridge_: <p​ixelcluster> fwiw that error message means it crashed somewhere down the call chain of AcquireNextImage
15:24 fdobridge_: <p​ixelcluster> in case someone thought it was vkresult validation, i thought of that first at least and it's not that :D
15:26 fdobridge_: <p​homes_> I will try this tonight. I have not used that before but I will see what I can figure out
15:40 fdobridge_: <k​onstantinseurer> Can you also try with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26371 ? I encountered a similar error when replaying the radv fossils on NVK.
15:50 fdobridge_: <g​fxstrand> Oh, well that's exciting....
18:16 fdobridge_: <p​rop_energy_ball> This should work now, no?
18:16 fdobridge_: <p​rop_energy_ball> Are you on latest git
18:17 fdobridge_: <p​rop_energy_ball> I marged present wait for nvk a whike ago
18:21 fdobridge_: <!​DodoNVK (she) 🇱🇹> I don't think that error is related to present_wait (the driver is probably just exploding somewhere and throwing a DEVICE_LOST to all of the Vulkan calls)
18:23 fdobridge_: <k​arolherbst🐧🦀> there is always `MESA_VK_ABORT_ON_DEVICE_LOSS=1` :ferrisUpsideDown:
18:24 fdobridge_: <k​arolherbst🐧🦀> I wonder if nvk submits to dead channels and if nvk needs to handle it more gracefully? that `channel -1` is kinda odd
18:27 f_: Uh oh.
18:27 f_: [596624.297517] nouveau 0000:01:00.0: DRM: base-1: timeout
18:27 f_: Laptop screen is very laggy and unusable.
18:27 f_: Still Fermi, of course :)
18:28 f_: It started going all green before..this.
18:28 f_: I'll send some dmesg logs shortly.
18:28 f_: (second display is fine)
18:29 f_: Oh nevermind.
18:29 karolherbst: yeah...
18:29 karolherbst: your display context is broken
18:29 f_: Changing modes fixed it somehow.
18:29 karolherbst: dmesg would help to figure out what went wrong
18:29 karolherbst: ahh yeah, not surprising
18:30 f_: Still want a dmesg?
18:30 karolherbst: yeah
18:30 karolherbst: though I think it might just be the GPU being slow
18:30 f_: Doubt it.
18:30 f_: Second display was totally fine and unaffected.
18:30 karolherbst: it's a fermi with slow clocks probably
18:30 karolherbst: sure, but it is enough if it only happens sometimes
18:31 f_: That's actually the first time it happened
18:31 karolherbst: I've seen such errors being fixed on kepler by ramping up the clocks
18:31 karolherbst: ohh, yeah, could also be something else randomly going wrong
18:31 karolherbst: just two displays and fermi with very slow memory is a great combination to run into "gpu being too slow"
18:31 karolherbst: maybe something more heavy happend in userspace
18:32 f_: I think that ^ sounds about right.
18:33 fdobridge_: <S​id> I think I had something similar once when I tried to apply overscan settings on plasma wayland on my turing card
18:34 f_: Except I was just chatting on IRC :^)
18:34 f_: karolherbst: here you are: https://bin.vitali64.duckdns.org/6596fa0a
18:36 f_: Except my terminal is gpu-accelerated..
18:37 fdobridge_: <S​id> kitty?
18:37 f_: No, alacritty
18:37 f_: Never had slowdowns with it so far.
18:37 fdobridge_: <S​id> ah
18:37 f_: Well..unless I set the font too small :P
18:39 f_: Oh, also forgot:
18:39 f_: $ uname -a
18:39 f_: Linux carousel 6.6.4-artix1-1 #1 SMP PREEMPT_DYNAMIC Mon, 04 Dec 2023 21:43:36 +0000 x86_64 GNU/Linux
18:40 f_: Changing modes to something else and back fixed it for some reason, however.
18:41 f_: (1920x1080 -> 1280x1024 -> 1920x1080)
18:59 karolherbst: Lyude: maybe something for you to look into?
18:59 karolherbst: the dmesg above
20:10 fdobridge_: <k​arolherbst🐧🦀> seems like `vkmark` doesn't benefit from GSP being enabled: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10383
21:10 fdobridge_: <r​edsheep> Have you tested what perf you get with nvk on gsp with that benchmark? I got 3189 points when running it at 1080p, more than 20x faster
21:11 fdobridge_: <k​arolherbst🐧🦀> nah.. I'm just silly
21:11 fdobridge_: <k​arolherbst🐧🦀> it's not on 6.7+
21:13 fdobridge_: <r​edsheep> Ah, ok. 5x short of the performance of an rx 5700 still suggests this is one of the rougher test cases for nvk right now, but not to the degree that I'd call it broken
21:27 fdobridge_: <r​edsheep> Actually, the points in that benchmark just appear to be the average fps. I'd argue anything already getting 3k+ fps probably isn't the most important place to look for where to improve performance.