Time for a bit of modernisation. With the upcoming Mesa 25.1 release, Collabora developer Faith Ekstrand announced a big change for NVIDIA GPU users. If you're not using the proprietary NVIDIA driver, that is.
The old Nouveau OpenGL driver will no longer be used by default, and instead they're going to be switching it out of the box to use Zink + NVK. A merge request for Mesa to do the change for "turing and above", that being the likes of the GeForce RTX 20xx series and GeForce GTX 16xx series and newer, was opened back in May 2024 with it just about to be pulled in now.
Confused? As a reminder — Zink is an OpenGL implementation on top of Vulkan. While NVK is a Vulkan driver for NVIDIA GPUs. Ekstrand mentioned how Zink has "matured a lot" and they're "fairly confident that Zink+NVK will be an improvement over Nouveau GL across the board".
Mesa 25.1 is due a fourth release candidate on May 7th, or the 25.1 final release if it's deemed ready. So not that long to wait on this.
Read more in the Collabora news post.
Last edited by Leprotto on 11 Mar 2025 at 4:45 pm UTC
Edit: Oops. I actually meant to ask about the Pascal chipset but knowing the timeline for Maxwell would be great too.
Last edited by Caldathras on 12 Mar 2025 at 4:43 pm UTC
Zink still lack va-api support
I think someone should create VA-API over Vulkan video for that.
Looks like there is some work on it:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31517
Last edited by Shmerl on 11 Mar 2025 at 5:55 pm UTC
struct native_req_assets *native_req_assets_get(struct native_info *native_info);
Since DLSS is some proprietary Nvidia blob, the question goes other way around. Is there a possibility for DLSS to support nova+nvk? I wouldn't count on it.
Not familiar with how DLSS accesses the GPU though. If it's using some standard Vulkan path - it might work. If it's not, Nvidia will have to contribute whatever is missing. Or someone else who cares to reverse engineer it.
Last edited by Shmerl on 11 Mar 2025 at 7:53 pm UTC
Wine is a shining example how with enough effort lack of downstream support can be circumvented.
I do agree that the chance is low.
One would either need to trick the verification system NVIDIA uses to detect their own drivers and reverse engineer the apis or implement their own version through a minefield of patents, reverse engineering, AI copyright problems, etc.
Which one is easier depends on whether you're talking to a lawyer or an engineer.
to choose the perfect pixel to render when translating polygons to pixels a gpu can use supersampling (which sort of extracts more neighbouring pixels from the polygon then melds them into one)
then there's anti-aliasing which helps get rid of jagged edges by sort of displaying several pixels into one or making each pixel semi-affected by its neighbours
and probably a bunch of old-ish techniques that let the GPU think in higher-res then compress the resulting visual to lower-res in a smoother fashion
now there's upscaling techniques like DLSS and FSR that let the GPU think in smooth lower-res and expand the output to a not-quite-as-smooth higher-res
are we, in real world scenarios, partially downscaling then partially scaling things back up instead of doing it all in one scale?
is all this extra logic worth it or are there cases where eg: 4k without the contradictory bells and wistles is faster and looks better than 1080p with everything maxed?
is anyone keeping track of all the ups and downs and how well they go along? game engines, probably, right? driver logic?
Last edited by Marlock on 11 Mar 2025 at 9:13 pm UTC
in a world with infinite competent human resources, it's likely that Zync would never make sense
in the real world it seems like it's living up to some of its big ticket goals and peoples expectations, eg:
ensure (wherever vulkan exists) a catch-all complete and compliant OpenGL implementation where specific implementations are quirky, broken, slow or missing
make a single effort count tenfold
surpass some suboptimal implementations despite its overhead
heck, even make some magic happen, like providing and using shared context so hibrid approaches like Vukan+OpenGL (done and used in X-Plane + plugins) and OpenGL+OpenCL (in the works iirc) become possible
kudos for the vision and for the deliveries!
Last edited by Marlock on 11 Mar 2025 at 9:24 pm UTC
I'll be interested to see some games like Minecraft benchmarked with Zink on Nvidia GPUs.
If the bridge solution is on par with native drivers, it could be the end of having to maintain two APIs!
But, lets say we hit 99.5% of the performance, the remaining large concerns would be suddenly breaking compatibility with some obscure (or professional-class) application that was using it?
Basically someone would have to pay for Certification against all the professional OpenGL applications.
And there's outstanding features, such as VAAPI video decode acceletation, etc...
Some of the simpler/older algorithms could probably be coded as Compute Shaders, but you'd not get the right kind of performance if you skip the various hardware blocks.
I feel starting at e.g. Nouveau was probably the right call. Lets fix up the basics needed by modern X/Wayland compositors.
Next up would be some of the less-well-supported ARM video drivers, there the video acceleration blocks are quite important.
It's a long journey, but honestly it seems very much like a good journey.
See more from me