NVIDIA 440.82 Linux Driver Brings DOOM Eternal Performance Fix, Linux 5.6 Compatibility

[Linuxxx]

If they'll ever fix broken triple buffered vsync in GPU bound scenario?

Could You please elaborate on this particular bug?

Are You seeing this with

Option "TripleBuffering" "1"

in Your xorg.conf or rather with

dxgi.numBackBuffers = 3

inside Your dxvk.conf ?

That being asked, my personal observation on the matter of Triple-Buffering (the traditonal one with two back-buffers [a.k.a. mailbox mode], not the DirectX mode where the additional buffer is just in a queue) is that with modern GPUs packing quite substantial boost clocks in comparison with their base clocks, having them constantly do unneccessary work in the form of frames that might never get displayed will lead to eventual thermal throttling, in which case the boost mode will be unavailable when it might actually be required, such as computing an unusually demanding scene in a game (classic example: a sudden explosion).

Are You generally using triple-buffering when gaming, and how are Your experiences with it?

[insilications]

Any news regarding the big Nvidia Open Source announcement?

[allquixotic]

Freshly built for You about an hour ago:

https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa

Hope it fixes Your problems!

Phew! Just in time, too! Thanks for pointing it out.

[Linuxxx]

Does anyone maintain an Ubuntu PPA with updates to nvidia-dkms and the other libraries/packages for the nvidia driver that has the 440.82 driver? I have had persistent issues with the .64 driver:

• Cinnamon and Gnome Shell DEs: after ~4-6 hours of usage the X server reliably freezes up. Killing and restarting X doesn't fix it; probably some low level driver corruption, so I have to reboot.
• KDE: after using the system for some time (especially after a suspend/resume) whenever a new window is presented (maximized from being minimized, or created new) the rest of the screen except for the new window flickers between black and the correct output at about 1/2 the display refresh rate.
• PULSAR: Lost Colony: after running the game for 1+ hour eventually all level geometry starts to flicker to black (just like the KDE window bug) and eventually disappears entirely, requiring a game restart.

Can't repro any of these issues on a Radeon VII with the oibaf PPA open source graphics stack. The problem with the Radeon VII is the performance is pretty bad in some games, like Kingdom Come: Deliverance, whereas the Nvidia binary driver is fine there. Can't have it all with one driver/card!

Freshly built for You about an hour ago:

https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa

Hope it fixes Your problems!

[allquixotic]

Does anyone maintain an Ubuntu PPA with updates to nvidia-dkms and the other libraries/packages for the nvidia driver that has the 440.82 driver? I have had persistent issues with the .64 driver:

• Cinnamon and Gnome Shell DEs: after ~4-6 hours of usage the X server reliably freezes up. Killing and restarting X doesn't fix it; probably some low level driver corruption, so I have to reboot.
• KDE: after using the system for some time (especially after a suspend/resume) whenever a new window is presented (maximized from being minimized, or created new) the rest of the screen except for the new window flickers between black and the correct output at about 1/2 the display refresh rate.
• PULSAR: Lost Colony: after running the game for 1+ hour eventually all level geometry starts to flicker to black (just like the KDE window bug) and eventually disappears entirely, requiring a game restart.

Can't repro any of these issues on a Radeon VII with the oibaf PPA open source graphics stack. The problem with the Radeon VII is the performance is pretty bad in some games, like Kingdom Come: Deliverance, whereas the Nvidia binary driver is fine there. Can't have it all with one driver/card!

[pipe13]

As I recall, the RPMFusion nvidia build needed a patch for kernel 5.6. Did the negativo17 repo show a 5.6 patch? That could be your difference.

I believe that is the difference. I didn't keep negativo17's source rpms, but I did look at rpmfusion's patch and it was changing the very functions and pointers that negativo17's compiles were failing, and negativo17's dkms and akmod installs both failed in the same way. And I don't remember seeing a "patch" in negativo17's /usr/src/nvidia folder when it was there.

The difference in install times *might* come down to rpmfusion making available a pre-compiled kernel-specific driver e.g. kmod-nvidia-5.6.2-300.fc32.x86_64, which their akmod-nvidia *might* try to download and install before trying to compile it from source. But I don't know that; here's the dnf info:

Name           : kmod-nvidia-5.6.2-300.fc32.x86_64
Epoch           : 3
Version         : 440.64
Release         : 2.fc32
Architecture : x86_64
Size              : 30 M
Source         : nvidia-kmod-440.64-2.fc32.src.rpm
Repository  : @System
From repo  : @commandline
Summary    : nvidia kernel module(s) for 5.6.2-300.fc32.x86_64
URL              : http://www.nvidia.com/
License        : Redistributable, no modification permitted
Description : This package provides the nvidia kernel modules built for the
                      : Linux kernel 5.6.2-300.fc32.x86_64 for the x86_64 family of
                      : processors.

...at any rate, rpmfusion's "dnf install akmod-nvidia" goes quite fast on the running kernel, but e.g. "kmods --kernel 5.6.0-300.fc32.x86_64" on an older kernel takes time to compile that driver before installing.

No matter, it works. I prefer negativo17 for it's cuda packaging, but that can likely wait until Slaanesh releases this new nvidia-440.82. My graphics work fine, and rpmfusion has nvidia's libOpenCL.so.1 for my custom libraries that can use it. Thanks for your advice!

[CommunityMember]

I attempted to install the fc32 nvidia-driver 440.64 from negativo17. dkms failed to compile ..... I abandoned that attempt and installed the xorg-x11-drv-nvidia from rpmFusion-nonfree instead. This works fine
Thanks!

As I recall, the RPMFusion nvidia build needed a patch for kernel 5.6. Did the negativo17 repo show a 5.6 patch? That could be your difference.

As I recall, while akmod and dkms are different build mechanisms and can result in some build time differences, if one is doing essentially the same things it should take about the same time, but I think that RPMFusions approach and negativo17's approach to the builds for nvidia are somewhat different (negativo17 builds more things from scratch) which I suspect contributes to the noticeable different build times. You should be able to review the src rpms to determine what is what.

[pipe13]

Okay. So a few days ago I installed Fedora32 Beta on this 2500k + GTX960 system. No real hassles, the new Blivet-anaconda partition manager wasn't able to assign custom partitions, but the older custom partition interface still worked as usual, updated to 5.6.2-300.fc32.x86_64 kernel. Nouveau worked fine out of the box, and I attempted to install the fc32 nvidia-driver 440.64 from negativo17. dkms failed to compile, gcc-10 whining over a raft of dodgy pointer assignments.

Hey! Looked like typical C code to me!

But on the off-chance that gcc knows something I don't, or that perhaps there was somewhere a header mismatch, I abandoned that attempt and installed the xorg-x11-drv-nvidia from rpmFusion-nonfree instead. This works fine, although I am a little curious at how quickly it went and the apparent lack of the .ko interface compilation I'm accustomed to seeing from dkms.

Does anyone here know if rpmFusion's akmod / akmod-nvidia system works substantially different from dkms? I'm not complaining at the result, only that I'd rather use negativo17's fedora-nvidia repo and Slaanesh -- being Italian -- might have a few other priorities atm and I don't wish to bother him.

Thanks!

[creative]

Added a workaround for Steam Play title DOOM Eternal, which overrides application requested memory locations, to ensure performance-critical resources be placed in video memory.

Looks like there's a major bug in the game. Someone please ping idSoftware.

id software cough.. bethesda could give a rats natch about folks running this abomination of a first person shooter on linux.

I have the game, it's Doom Raider. 25 years of fun playing Doom and looking forward to future Doom games pissed down the drain.

They should have killed any future Doom off right after Doom 2016.

Doom needs to rest in piece and the whole memory of Doom from the first one all the way through the 2016 masterpiece needs to live on though. I don't want to see another new Doom game, Eternal just ruined it for me.

I am ignoring all new Doom games past 2016.

After about eight hours of Doom Eternal I could not stand anymore it's awful.

[digitalsin]

Don't care about any fancy stuff like Wayland etc. The only question - did they fix Alt+Tab issues on any fullscreen Vulkan application? That includes everything using DXVK. I thought this is only Kwin exclusive bug, but the same happens on GNOME 3 and even XFCE. It is even mentioned on Arch wiki. On Intel there is no such issue.

File a bug directly with nVidia. Even if they know the bug exist, likely they fix it only if it is noticed and reported.