NVIDIA 535.54.03 Linux Driver Released With Vulkan Updates, DMA-BUF v4 Wayland Protocol

[phoronix]

Phoronix: NVIDIA 535.54.03 Linux Driver Released With Vulkan Updates, DMA-BUF v4 Wayland Protocol

Following last month's NVIDIA 535 Linux driver beta that was launched at the end of May, NVIDIA has now released the 535.54.03 Linux driver as the first stable R535 driver in this new series...

https://www.phoronix.com/news/NVIDIA-535.54.03-Linux-Driver

[Sanjuro]

Have they fixed the stuttering on desktop?

Having just glxgears or vkcube running makes resizing windows or browsing menu stutter like crazy.
Or visit https://www.vsynctester.com/ and run vkcube

[andyprough]

Nice! I'm sure it's released under the GPL. Or maybe an MIT license. Or maby an Apache license. Or some kind of BSD license.

No?

By downloading, installing, copying, or otherwise using the SOFTWARE, you agree to be bound by the terms of this LICENSE. ... The SOFTWARE is not sold, and instead is only licensed for use, strictly in accordance with this document. ... No Reverse Engineering. Customer may not reverse engineer, decompile, or disassemble the SOFTWARE, nor attempt in any other manner to obtain the source code.

Oh well, that's OK, I can download and use it while I sue nVidia for the right to reverse engineer it or get at the source code. Right?

If Customer commences or participates in any legal proceeding against NVIDIA, then NVIDIA may, in its sole discretion, suspend or terminate all license grants and any other rights provided under this LICENSE during the pendency of such legal proceedings.

Oh well, that's OK, at least if it damages my computer nVidia will pay to make me whole, right?

TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, IN NO EVENT SHALL NVIDIA OR ITS SUPPLIERS BE LIABLE FOR ANY SPECIAL, INCIDENTAL, INDIRECT, OR CONSEQUENTIAL DAMAGES WHATSOEVER (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF BUSINESS PROFITS, LOSS OF DATA, BUSINESS INTERRUPTION, LOSS OF BUSINESS INFORMATION, OR ANY OTHER PECUNIARY LOSS) ARISING OUT OF THE USE OF OR INABILITY TO USE THE SOFTWARE, EVEN IF NVIDIA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Oh well, at least nVidia can't use the software to collect personal information about me, right?

Customer also acknowledges that from time to time, NVIDIA may collect, use, and disclose such information about Customer and/or Customer's system in connection with the SOFTWARE in accordance with NVIDIA's privacy policy

Oh well, their privacy policy can't be all bad, right?

We collect installation and configuration details about your software, hardware, and network configuration (e.g., version of operating system, applications installed, type of hardware, network speed, IP address). ... We collect information about the features and applications used in connection with our products or services, including the software or games you are using.

[MorrisS.]

It seems an excellent improvement. It would be interesting to know about both KMS and compositors explicit sync development.

[avis]

Nice!

Do not by or use. Be happy. AMD and Intel have got you covered. Too much pain about nothing.

People who use NVIDIA drivers overall are quite content. Full Wayland support is coming some time in the future.

[Monsterovich]

Have they fixed the stuttering on desktop?

Having just glxgears or vkcube running makes resizing windows or browsing menu stutter like crazy.
Or visit https://www.vsynctester.com/ and run vkcube

Here is the ticket for this bug:

https://forums.developer.nvidia.com/t/vulkan-app-with-vk-present-mode-fifo-khr-vsync-causes-desktop-stuttering-across-entire-system-when-moving-or-resizing-any-window-linux-x11/185015/6

V-Sync works in OpenGL but stutters the entire desktop in Vulkan.

[Scramblejams]

I stuck with Nvidia for a long time on Linux because it was a better experience for me than AMD, but finally I got tired of all the stuttering during window resizing, window switching, etc. with heterogeneous multimonitor on my distro of choice. (Kwin's triple buffering got rid of most of it, but I wasn't willing to jump from Mint to KDE at the time because of other reasons.) Moved to a recent AMD GPU and have been much happier -- though I had to also move to Wayland to get rid of the last hitching -- but I know my games would sure love to get that Nvidia edge back.

Looking forward to the day when Nvidia's driver is competitive with amdgpu on multimonitor Wayland setups.

[Developer12]

I stuck with Nvidia for a long time on Linux because it was a better experience for me than AMD, but finally I got tired of all the stuttering during window resizing, window switching, etc. with heterogeneous multimonitor on my distro of choice. (Kwin's triple buffering got rid of most of it, but I wasn't willing to jump from Mint to KDE at the time because of other reasons.) Moved to a recent AMD GPU and have been much happier -- though I had to also move to Wayland to get rid of the last hitching -- but I know my games would sure love to get that Nvidia edge back.

Looking forward to the day when Nvidia's driver is competitive with amdgpu on multimonitor Wayland setups.

When that happens it probably won't be nvidia's driver anymore.

[piotrj3]

Here is the ticket for this bug:

https://forums.developer.nvidia.com/t/vulkan-app-with-vk-present-mode-fifo-khr-vsync-causes-desktop-stuttering-across-entire-system-when-moving-or-resizing-any-window-linux-x11/185015/6

V-Sync works in OpenGL but stutters the entire desktop in Vulkan.

I am not sure but it kinda feels... half intended?

VK_PRESENT_MODE_FIFO_KHR specifies that the presentation engine waits for the next vertical blanking period to update the current image. Tearing cannot be observed. An internal queue is used to hold pending presentation requests. New requests are appended to the end of the queue, and one request is removed from the beginning of the queue and processed during each vertical blanking period in which the queue is non-empty.

Now i would understand if entire presentation (of everything post composition) was running in this mode aka internal queue holds buffers and synchronize it to screen. But i don't understand how a case of one vs many aplications work here. eg. you have 1 aplication window that is running in that mode, but before it gets sent to screen you have to go pass composition step and that composition gets against that FIFO queue.

https://community.khronos.org/t/vkqueuepresentkhr-blocks/7560

As you can see, acquiring the image is instantaneous. Instead, vkQueuePresentKHR seems to be the synchronization point for my code

This seeems like simply Nvidia treats your main window like priority window with minimal latency, and ignores correctness of tearing outside. Which sort of is somewhat viable interpretation.

In my opinion, in non full-screen mode you are supposed to use VK_PRESENT_MODE_MAILBOX_KHR instead. Or use VK_PRESENT_MODE_IMMEDIATE_KHR and let Vsync be handled by Wayland or driver directly.

[Monsterovich]

This seeems like simply Nvidia treats your main window like priority window with minimal latency, and ignores correctness of tearing outside. Which sort of is somewhat viable interpretation.

No, V-Sync in a particular application shouldn't affect other applications in any way. OpenGL driver doesn't have this bug.

There was a similar issue on Windows:

https://forums.developer.nvidia.com/t/vsync-stutter-on-windows-optimus-laptop-with-external-primary-monitor/180355/3

In my opinion, in non full-screen mode you are supposed to use VK_PRESENT_MODE_MAILBOX_KHR instead. Or use VK_PRESENT_MODE_IMMEDIATE_KHR and let Vsync be handled by Wayland or driver directly.

This bug also appears in VK_PRESENT_MODE_MAILBOX_KHR. VK_PRESENT_MODE_IMMEDIATE_KHR is not an option, because of screen-tearing. I use Xorg, Wayland sucks.