After double checking my launch options -notexturestreaming seems to be the issue. I decided to boot up windows with the same argument and also got the same black texture. It looks like more of a game engine bug then a driver issue.
Both HDR extensions are in the driver.
No need for VK_HDR_LAYER installed now and/or the ENABLE_HDR_WSI variables. Multiple users are reporting this for enabling HDR in games.
I also tested this and confirm. It was already like this with the Vulkan Beta Drivers.
I notice this only with Ghost of Tsushima, happened on 590 also. The game literally recompiles shaders from scratch every single time I launch, causing a long delay before i can get in game. I ensured I didnât change any variables between launches, however it still occurs.
I saw someone mention Ghost of Tsushima was working, but they didnât mention whether they had shader caching enabled.
The only helpful test I can do is Overwatch once I have access to driver 595, since thatâs a game I play often which doesnât recompile shaders every launch. If there is a regression with 595 it should show up for me pretty quickly. I also wonder if itâs specific to certain games or Proton versions. If I use a manual Proton version, itâs usually from ProtonGE.
I see bug number 5374195 for the VRR report, thanks. Hopefully an Nvidia employee can check the status.
>I notice this only with Ghost of Tsushima, happened on 590 also. The game literally recompiles shaders from scratch every single time I launch, causing a long delay before i can get in game.
>tried the new NVreg_UseKernelSuspendNotifiers=1, driver crashed during suspend, i managed to recover full kernel logs
Thank you both. I will file bugs for tracking these issues.
@faz , do you mind capturing a NVIDIA bug report after you observe the delay. I will share our internal bug IDs for tracking and check if we can reproduce these for investigation.
Can you please try setting SELinux to disabled or permissive and try again? I think youâre running into a problem that was discovered recently where Fedora is blocking the driverâs ability to save vidmem data. I have a pull request to relax that but thereâs a corresponding driver change that will be needed. Let me know if you want to try that and I can post it as a patch.
Itâs still being investigated. The problem is a little more complicated than just âLFC isnât workingâ: different panels have different behavior and the problem involves more than just low framerates.
I donât have one. Iâve been communicating with @vrachatte regarding a report in this thread: 580 release feedback & discussion - #1015 by wierzbiniak95. He was able to reproduce the bug, but I didnât receive a tracking ID. I first encountered the issue on the 580 series; it also persisted on 590.44.01, and is still present now on 595.45.04. (I originally filed the report to NVIDIA team before someone found the bug and made a fix for nvidia-vaapi-driver).
@luanv.oliveira Yes it is probably a bug in nvidia-vaapi-driver, but since it has been broken only on NVIDIA cards for at least two months, I wanted to bring it to NVIDIA team attention
Most repositories donât have the latest nvidia-vaapi-driver yet. Iâll test it as soon as I get the fix
EDIT: A version containing a supposed fix was pushed to the Fedora 43 repository today. Screen recording remains broken on NVIDIA.
That seems to be the case. They were working on the previous version, 580.94.xx, 590.44.01. Now, I canât launch any games; depending on the launcher, there are small differences in behavior.
3028.921:0134:0138:trace:seh:QueryFullProcessImageNameW NT path: L"\\Device\\HarddiskVolume2\\home\\kn\\.local\\share\\Steam\\steamapps\\common\\Proton - Experimental\\files\\share\\xalia\\xalia.exe"
3028.921:0134:0138:trace:seh:QueryFullProcessImageNameW NT path: L"\\Device\\HarddiskVolume2\\home\\kn\\.local\\share\\Steam\\steamapps\\common\\AoE2DE\\AoE2DE_s.exe"
3028.921:0134:0138:trace:seh:QueryFullProcessImageNameW NT path: L"\\Device\\HarddiskVolume2\\home\\kn\\.local\\share\\Steam\\steamapps\\common\\AoE2DE\\BattleServer\\BattleServer.exe"
3028.921:0134:0138:trace:seh:QueryFullProcessImageNameW NT path: L"\\Device\\HarddiskVolume1\\windows\\system32\\conhost.exe"
3028.939:0134:0368:fixme:evr:filter_media_event_sink_Notify iface 0000000008D879D8, event 32, param1 0, param2 0.
3028.944:0134:0138:fixme:quartz:media_seeking_SetPositions iface 000000000AAF8928, current 0.0, current_flags 0x9, stop 0.0, stop_flags 0 stub!
3028.945:0134:0138:fixme:quartz:media_seeking_SetPositions iface 000000000AAF8C50, current 0.0, current_flags 0x9, stop 0.0, stop_flags 0 stub!
3028.945:0134:041c:err:wmvcore:wm_reader_read_stream_sample Failed to allocate sample of 2304 bytes, hr 0x80040211.
3028.947:0134:042c:err:wmvcore:wm_reader_read_stream_sample Failed to allocate sample of 2304 bytes, hr 0x80040211.
3028.948:0134:0424:err:wmvcore:wm_reader_read_stream_sample Failed to allocate sample of 3110400 bytes, hr 0x80040209.
info: Presenter: Actual swapchain properties:
info: Format: VK_FORMAT_B8G8R8A8_UNORM
info: Color space: VK_COLOR_SPACE_SRGB_NONLINEAR_KHR
info: Present mode: VK_PRESENT_MODE_IMMEDIATE_KHR (dynamic: no)
info: Buffer size: 3440x1440
info: Image count: 4
err: Presenter: Failed to create Vulkan swapchain: VK_ERROR_INITIALIZATION_FAILED
info: Presenter: Actual swapchain properties:
info: Format: VK_FORMAT_B8G8R8A8_UNORM
info: Color space: VK_COLOR_SPACE_SRGB_NONLINEAR_KHR
info: Present mode: VK_PRESENT_MODE_IMMEDIATE_KHR (dynamic: no)
info: Buffer size: 3440x1440
info: Image count: 4
Update on bug 5507242: just tested on 3060 mobile with nvidia-open 595.45.04, it seems this is also solved on ampere now, feel free to close this bug tracker and thanks for the fix!
interesting, I still havenât upgraded to 595 but flickering in one corner is something I have noticed with 580 and 590 when fractional scaling is used on Plasma (6.6), and I donât think I have observed it while gaming. Itâs mainly a desktop thing, and is often triggered by web browsers and sites like YouTube. Are you using mangohud or a similar overlay?