580 release feedback & discussion

Bug report: The Finals - game freeze with specified Ray Tracing - RTXGI and Effect settings on 3060 Mobile

Brief Description

the game The Finals will randomly freeze during a match, or more frequently loading screen, if Ray Tracing - RTX Global Illumination (RTXGI) is set to any Dynamic one and Effects is set to High or Epic in-game.

Steps to Reproduce:

  1. Set RTXGI to Static, and set Effects to Low, then restart the game. (This is required for steps below; you can start with other settings and start playing the game to capture freeze but it needs way more time, while these steps can reproduce freeze much faster)
  2. Go to in-game Practice Range.
  3. Go to video setting. First, set RTXGI from Static to Dynamic - Low; then, set Effects from Low to High or Epic. (If set Effects first then RTXGI, game won’t freeze for now, but will still freeze in further game session)

Once Effects is set to High or Epic, game will freeze instantly and then crash due to game thread hang detected.

Frequency:

100% reprocducable on my laptop with steps above.

not sure if 570 have this issue, but I have met this with both 575 and 580.

System Configuration:

  • System: Arch Linux Linux 6.16.4-2-cachyos
  • Desktop Environment: KDE Plasma 6.4.4
  • GPU: Nvidia RTX 3060 Mobile
  • Monitor: eDP-1: 1920*1080@144Hz

nvidia-bug-report.log.gz (550.7 KB)

@amrits @aplattner

LFC is still broken: Wildly fluctuating refresh rate and flicker at low framerates , Gsync compatible VRR - Low Framerate Compensation (LFC) transition not seamless, unlike on Windows

Has the team been able to reproduce this bug? I’ve been able to reproduce it on my roommates computer, and on several distros on my computer. It seems hardware agnostic. Every linux distro has weird LFC behavior.

No issues when I boot into windows and use the same test software (vrrtest). LFC works perfectly on windows. When dropping below the threshold on linux (48hz for me) my refresh rate fluctuates between 48, 68 and 165 (my monitors native refresh rate). On windows it properly uses the doubled or tripled low fps as the refresh rate.

nvidia-bug-report.log.gz (827.0 KB)

Thanks, I can repro issue locally.

Shall update once I have feedback from engineering on repro setup.

1 Like

Hi @robula1990

We have been not able to duplicate issue locally so far.

Would like to know after how many times of gameplay you observe the crash.
Does issue occur in solo play/training mode.

Could you paste the output of sysctl vm.max_map_count? Something similar happened to me because the number wasn’t big enough.

already set that value higher than default, so shouldn’t be a issue:

➜  ~ sysctl vm.max_map_count
vm.max_map_count = 2147483642
➜  ~ cat /etc/sysctl.d/98-max_map_count.conf 
# Increase the default vm.max_map_count value
vm.max_map_count = 2147483642

Are you going to address what seems to be a typo in the nvidia_icd.josn file or are you going to keep ignoring it?

There was a discussion about that earlier. It’s definitely not a typo so there must be something else going wrong here.

1 Like

new nvidia driver released, this should hopefully fix the gtk4 issue

it also added smooth motion support to the rtx 40 series, so thank you Nvidia developers for this!

4 Likes

I don’t see a 1.4.312 version listed or am I missing something?

1 Like

Version of the spec exists, it just didn’t get a SDK release (that doesn’t matter)

Edit: to reiterate, the drivers support features up to the 1.4.312 spec and that’s why it lists that version – if you list something higher that would essentially be lying about what it supports as far as I know. That setting it higher helps something seems like an accident (maybe it tried to use an extension that doesn’t exist given it doesn’t support higher versions and fell back to something else that works better, I wouldn’t know)

2 Likes

Fair enough, I guess I can’t help here.

It could be possible that the root-source of that bug is actually in the Vulkan Loader code. Between 1.4.312 and 1.4.321 there have been quite a few commits including some that fix regressions caused in refactors. So a bug may have been introduced after 1.4.303 and fixed by 1.4.321, but not yet fixed in 1.4.312.

1 Like

If you want to reproduce, these are the steps I used to reproduce it on any linux system running nvidia.

  1. make sure Variable Refresh Rate/Gsync is on and download some sort of VRRtest software (vrrtest)
  2. Then turn on the refresh rate display in your monitors OST.
  3. Open the test software and set the target fps to 48 or below (or whatever refresh rate your monitors LFC kicks in at)

You should see the reported monitor refresh rate shifting around erratically and not aligning with a proper LFC framerate (unlike on windows where LFC behaves as expected and tightly follows a multiple of the low target framerate)

580 is broken on Einstein@Home, this seems to be a common issue

575 works fine.

See my post here

https://forums.developer.nvidia.com/t/no-signal-with-vrr-when-framerate-is-low/334140/7

1 Like

Yeah it might be a freesync monitor gsync compatible thing (I think my monitor is just gsync compatible), that makes sense. However I don’t have any issues with black screens, only mild but annoying flicker. So these feel like seperate bugs, but maybe under the surface they are the same thing? All I know is LFC seems to be broken in Linux.

Again everything works wonderfully on windows though so it seems like a driver bug. Or maybe I am not aware of some reason why LFC can’t be implemented properly in Linux or something. I don’t know.

I believe they are the same issue and that some people just get black screens. I do have the flickering like you but I think it is because the refresh is all over the map and it looks like changes in brightness when in reality it is massive swings in refresh.

1 Like

Interesting. You are probably right, they are probably caused by the same underlining issue.

Again it works on windows for some reason so its definitely software on my setup (gigabyte M32Q + 3080). I might boot up windows again to do some testing. I also did some testing on my roommates computer and got the same thing (LFC works on windows, has erratic behavior with the constant refresh rate switching on linux)

Hopefully the issue with LFC on freesync/gsync compatible monitors can be replicated on nvidia’s end. Is this currently being tracked?

From the release notes:

  • Fixed a bugregression introduced in 580.65.06 that could cause Vulkan applications to hang on Wayland.

I’m confirming with 580.82.07 GTK4 apps no longer hang on exit with the default Vulkan rendering backend.

  • nVidia internal tracking Bug #5436037

Thanks for getting this regression stomped.

Now, back to testing [560.35.03] GTK4 apps background CPU usage with Vulkan renderer - #36 by Tekstryder

580 series shaping up well!

4 Likes