HDR is not working with Borderlands 4 when using GE Proton with Wayland and HDR enable flags.
PROTON_LOG emits this error under wlroots compositors:
[destroyed object]: error 5: max luminance must be greater than min luminance
And this under Kwin:
[destroyed object]: error 5: min_lum can't be higher or equal to max_lum
Error indicates that the Vulkan implementation is attempting to use set_mastering_luminance with minimum luminance equal to or greater than the maximum luminance level it’s also attempting to set.
FYI the Wayland levels are integers, and minimum should be 10,000 times the decimal Nits level. Thus, a Wayland compositor would be dividing min by 10000 before performing this comparison. In which case something is definitely off if min is greater than or equal to max.
Strangely, this doesn’t seem to make sense with how vkd3d-proton converts it:
Never mind, it does make sense, if you look at Mesa’s WSI implementation:
(line 1303, since this forum can’t embed it properly)
I think your initial suspicion was right, because Mesa implements it correctly, doesn’t it? 10000*min_luminance is indeed what the CM proto specifies, but vkd3d-proton implements 0.0001*min_luminance?
I’m not sure how this worked in the past though if it regressed with this driver, but maybe it followed a different code path in vkd3d-proton that has now changed because of the vulkan HDR ext support? Not too familiar with vkd3d…
They’re both implemented correctly. The vkd3d-proton is scaling it from DXGI levels to Vulkan levels, and the Mesa code I linked to is scaling it to Wayland levels.
The issue here is that apparently a lot of games will just send invalid HDR metadata, and while Mesa’s WSI implementation filters out invalid settings before they reach the compositor, Nvidia does not, so the compositor terminated the application with a Wayland error.
Ah, you’re totally right, I missed that DXGI min luminance levels were also different… ref: dxgi docs. Looks like Mesa just doesn’t send the metadata if it’s invalid and will result in proto error.
I guess this is fixable on either dxvk/vkd3d or driver level? vkd3d fix might make more sense since it really should be the clients not violating the protocol… although Nvidia side fix would be more catch all, and I guess there’s no harm in the fix so maybe it’s less overall “work” for the driver to handle it like Mesa does.
I wonder how Windows deals with this? Looks like Microsoft now recommends that apps do not send HDR metadata anymore, but I’m not sure what it does for still sent invalid metadata (I guess it might just internally discard it like Mesa, probably for similar reasons).
Thank you for the update on 5374195! If there’s any way we can help, please let us know. For example, if it would be of any help, I have a few other VRR capable displays and TVs I can test and log, not just the innocn I submitted in 580.
I am guessing it’s a lot of manual work getting all the LFC implementations working across all BOE, AUO, CSOT, LG, Samsung etc etc. panels.
hi, i also enabled the new kernel param for the open drivers. This seems to have actually completely fixed suspend on my system. Previously my system would fail to wake but I just left my PC suspended for about 9 hours and just woke it up to see it still working fine.
My sleep related params are nvidia.NVreg_TemporaryFilePath=/var/tmp nvidia.NVreg_PreserveVideoMemoryAllocations=1 nvidia.NVreg_UseKernelSuspendNotifiers=1
I also made sure to disable the systemd services related to nvidia stuff, i.e. nvidia-resume, nvidia-suspend, etc etc, as those are not required when using this kernel param. This is indicated by the fact that the /proc/driver/nvidia/suspend file does not exist in this case.
Thanks for the insight. I wanted to share I notice this problem across two seperate monitors, a GIgabyte M27Q rev1, and an gigabyte OLED mo27q28g. You should be able to easily reproduce the problem if you have one of these on hand, the oled is quite new and only came out a few months ago but the M27Q has been out for years.
related also, but this game still encounters graphical glitches for me. Sometimes a black void starts filling the world, but can be restored by switching graphic presets to a different one and back.
and also the bloom issue i mentioned in the 590 thread somewhere seems to still occur. Here is the below video of that. Makes the game unplayable really
I’ve had this for years with Display Stream Compression on both a 3090 and 4090 in KDE (flickering in the bottom right of the screen, background objects will flicker through to the foreground). It still happens on 595. I submitted a bug report to KDE but they said it was an nvidia driver problem with DSC. There is also an open thread here on this forum about it started by someone else
There are packaging changes required for the new Sleep/Suspend mechanism.
Here you can find the changes required on Archlinux, but likely can be also ported to other packaging.
Main Changes:
systemd-suspend overrides for suspend, hibernate and co are not required anymore
NVreg_TemporaryFilePath=/var/tmp can be dropped
Pass NVreg_UseKernelSuspendNotifiers=1 to options
Disable all services: nvidia-resume nvidia-hibernate nvidia-suspend nvidia-suspend-then-hibernate
I have tested the new suspend mechnaism and it worked very very well so far on the Open Module. The wakeup is faster and works more reliable.
Did not test yet on Laptops.
Created a bug report thread but linking here as well, experiencing crashing with Armored Core VI any proton version unless using one with the heap patches (shadow bugs in garage occur with heap patches and ray tracing enabled though as I understand these are still WIP):
After thinking suspend was finally fixed on my end, it seems like it’s still not the case. I had an about 20 minute or so suspend cycle, and on wake my graphical wayland session was just displayed black and completely unresponsive. I was able to cycle to TTY2 to grab an nvidia-bug-report after the problems. The log seems to show my lockscreen (hyprlock) and my browser (librewolf) completely crashing
Hey ptr, yeah I am using the new kernel param, and I don’t have the Nvidia systemd services installed, let alone enabled. I do have the temporary file path kernel param though, would that affect it? I was able to do an overnight suspend yesterday which worked just fine. It’s very hit and miss on my case on the open drivers, whereas on closed with gsp disabled it has always been much more consistent
Tested this on 595. VRR breaks when below 48hz (Right when the card should be telling my monitor to run a a multiple of the fps, it occilates between 48hz and a number that is random but seems to be an attempt at setting the correct multiple (at 47hz it was running at 63hz, at 30hz it was running at 80hz)
What is the model of your monitor? One of the Nvidia employees earlier mention that different panels may behave differently, so we probably need to be tracking that in these reports.
Can confirm this exact behaviour, sometimes it jumps to 4x the FPS, when it only needs to be 2x, then sometimes jumps to max etc etc. At above 48hz / vrr limit it is actually quite stable however so I’ll give them that.