00:41 airlied[d]: _lyude[d]: also make sure the eDP remains working across suspend/resume, it didn't seem reliable for me
00:44 karolherbst[d]: _lyude[d]: okay, soo.. imagine this: you have a laptop where both GPUs can drive the eDP display, but it's mostly used for like fullscreen apps. But the user is sneaky and hibernates the system while the nvidia GPU is in use. Now you boot, the stored hibernation image gets loaded and....
00:45 karolherbst[d]: not that we support any of this, however.. if we would, that for sure would be an issue if you care about flicker free boot 😄
00:48 airlied[d]: if you change BIOS settings across hibernate, the kernel is meant to invalidate the hibernation image
00:49 karolherbst[d]: I meant the dynamic changing thing
00:49 karolherbst[d]: like for fullscreen gaming
00:49 airlied[d]: oh we are trying to fix the static one first 😛
00:49 karolherbst[d]: on modern laptops the OS can flip eDP across GPUs
00:49 karolherbst[d]: heh
00:49 karolherbst[d]: yeah well if you mess with the bios while hibernation... well yeah
01:23 _lyude[d]: airlied[d]: Oh interesting
01:23 _lyude[d]: I wonder if I'll run into this on my new machine
01:23 _lyude[d]: wait you meant just 2.1 right
01:26 airlied[d]: no HDMI doesn't work for me at all
01:26 airlied[d]: if it's plugged in at boot
01:27 airlied[d]: at least with the eDP inheritance off
01:27 airlied[d]: we try to configure head 0 to HDMI, head 1 to eDP and get a core channel notifier timeout
01:27 airlied[d]: which I think means the pipeline wasn't shutdown correctly before we moved stuff
01:30 _lyude[d]: oh dear
01:32 _lyude[d]: though.
01:33 _lyude[d]: Do you have any idea if this happens on desktops as well?
01:40 airlied[d]: probably not because I expect it's the eDP turn off that is the problem, not the HDMI turning on
01:40 airlied[d]: but I haven't plugged in a desktop card in a while
09:00 violet_purple_red[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1446426012383449250/Screenshot_from_2025-12-05_10-59-50.png?ex=6933f0b2&is=69329f32&hm=4b27e82b1bcb2f2a60eaaed7ab998ef804025edd1dfdd40d3c4604d0b6c441c9&
09:00 violet_purple_red[d]: interesting.
09:00 violet_purple_red[d]: could it be that there is a limitation to the vram usage of nvk?
09:01 violet_purple_red[d]: this only happens on nvk, on prop driver I play wukong just fine.
09:01 violet_purple_red[d]: I do have 12gb of vram after all
09:05 violet_purple_red[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1446427241096548433/Screenshot_from_2025-12-05_10-47-13.png?ex=6933f1d7&is=6932a057&hm=e5614b58872517803a37ed6722cfe045eb193cc1fb1102aac09a1f4de22518f4&
09:05 violet_purple_red[d]: karolherbst[d]: I think that high cpu usage is because of shader compilation in the background. because I switch between the drivers, so it has to recompile the shaders for nvk. I just ran Enlisted which is a native Vulkan game, it worked fine until I switched to meduim graphics settings and it crashed with the following message. I hope this helps
09:13 violet_purple_red[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1446429171831144592/image.png?ex=6933f3a3&is=6932a223&hm=d3ed47c886ddb42134c5823d651b39ae3b2bb182ad1c7b9ec108c8ae8a11db6e&
09:13 violet_purple_red[d]: oh and another thing Enlisted runs only with legacy runtime, it crashes when I try to run it with scout runtime of steam. here is the message I get:
09:31 violet_purple_red[d]: I should probably file reports about this...
09:31 violet_purple_red[d]: *sigh*
10:12 mohamexiety[d]: violet_purple_red[d]: No, this is a red herring. Something else crashed earlier on and the reporting thought this meant that you ran out of VRAM
10:13 violet_purple_red[d]: mohamexiety[d]: Yeah that's why I want to see why exactly it crashes
10:13 violet_purple_red[d]: Proton log probably will help
10:15 violet_purple_red[d]: Though again Wukong is a directx 12 game so there's that
10:15 violet_purple_red[d]: I am not sure if it even supports dx11
10:36 phomes_[d]: I looked into that crash with wukong earlier. It crashed because it expects ray tracing and NVK does not have that yet. The error handling in the game just mistakes it for a vram issue
10:37 violet_purple_red[d]: phomes_[d]: but I have it disabled
10:37 violet_purple_red[d]: does it still load it even if I don't use it?
10:44 phomes_[d]: I am not sure. That was just what I found last time I looked at it. I can take a look again next week
10:49 phomes_[d]: I remember now. I gave it a quick look because A1RM4X noticed the problem in one of his youtube vídoes
10:53 phomes_[d]: btw for vram usage I have a wip implementation of rmv support. I should finish that up
10:55 violet_purple_red[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1446454888321122416/message.txt?ex=69340b97&is=6932ba17&hm=039aa77dc9eb070930136a29dff466f4595f2ad1de2170796582d8cb6edebf72&
10:55 violet_purple_red[d]: this is what I was able to retrieve
10:55 violet_purple_red[d]: I just did a proton log and then took only the nvk part of it
10:56 violet_purple_red[d]: what's the most interesting part is this 8557.707:0164:02b8:warn:vkd3d-proton:d3d12_device_mark_as_removed: Device 0000000057820080
10:56 violet_purple_red[d]: is lost (reason 0x887a0005, "VK_ERROR_DEVICE_LOST").
10:56 violet_purple_red[d]: 8557.707:0164:02b8:err:vkd3d-proton:vkd3d_wait_for_gpu_timeline_semaphore: Failed to wait for
10:56 violet_purple_red[d]: Vulkan timeline semaphore, vr -4.
11:56 violet_purple_red[d]: I have a log for cyberpunk now if anyone wants to review it
11:56 violet_purple_red[d]: https://0x0.st/KtDL.log
14:33 mhenning[d]: violet_purple_red[d]: Launching with -dx11 gets it closer https://gitlab.freedesktop.org/mesa/mesa/-/issues/13516
14:36 violet_purple_red[d]: mhenning[d]: Makes sense
14:36 violet_purple_red[d]: Figured it was a dx12 issue
14:49 violet_purple_red[d]: mhenning[d]: also it seems that I am unable to launch the game at all with dx11
17:37 violet_purple_red[d]: if anyone is on gentoo there is a good documentation on how to make your system have two gpu drivers and choose between them based on the kernel you boot
17:37 violet_purple_red[d]: https://wiki.gentoo.org/wiki/Nouveau_%26_nvidia-drivers_switching
21:59 airlied[d]: @lyude I sent a patch switching the nv50_atom thing to a lookup crtc in state
21:59 airlied[d]: _lyude[d]: oops the tag didn't owrk
22:06 _lyude[d]: airlied[d]: oh - I didn't see it go by, could you link it?
22:07 airlied[d]: https://lore.kernel.org/nouveau/aTAsueO-OwP5pd4h@intel.com/T/#t it also could be wrong :-?)
22:14 _lyude[d]: airlied[d]: actually I think it is - there's only one place we want to switch from get_state to get_new_state
22:15 airlied[d]: ah cool, I trust you know more about atomic than I do, I just wasn't sure why we'd be looking up a new state where we hit the warning, the modeset should contain that state
22:17 _lyude[d]: I kinda wish we didn't name the functions like that because it is a little confusing. `get_state` means "get the new state for the thing, adding it to the atomic state if necessary" (which we can't do in prepare_fb, but can do everywhere else) whereas `get_new_state` means "get new state for the thing but only if it's in the atomic state already"
22:18 _lyude[d]: also, regarding the edp issue: it's possible I haven't found it yet, though considering I started from the actual KMS driver source for openrm and not the HAL I'm pretty sure I would have seen it by now - I'm not sure I see openrm reading the display state in anywhere
22:19 _lyude[d]: though I still don't get the feeling this isn't supported, since otherwise I would have expected some sort of error from nvdisplay when we try tearing down the eDP display
22:21 _lyude[d]: I'm going to keep searching for a bit to make sure though
22:26 airlied[d]: MarkConnectorBootHeadActive is the place I see it called
22:28 _lyude[d]: ooooh
22:28 _lyude[d]: interesting.
22:29 _lyude[d]: "init_no_update" hm.
22:31 _lyude[d]: now i'm starting to see some awfully familiar looking evo-display state related structs 🙂
22:50 _lyude[d]: ` // Resume the DisplayPort library's control of the device.`
22:50 _lyude[d]: i think i'm in the right direction now
23:01 _lyude[d]: oh hey! wow this code I found sure looks like it programs the iso buffer from openrm 🙂
23:01 _lyude[d]: also - nvRmResumeDP I think is what we need to do to fix the eDP displays