Mesa 25.1 will default to Zink+NVK instead of the old Nouveau OpenGL driver for NVIDIA on Linux

Awesome news. Zink is really paying off for a single complex OpenGL state tracker instead of many complex OpenGL state trackers each with different bugs.

Does make sense, always kinda expected that one day HW specific opengl drivers would be gone (of course not sure when that day will be, might be decades in the future, might be tomorrow) to be replaced with layers like zink. Also makes sense to try this first with nouveau AFAICT that driver always had problems (of course in large part due to no or at best very limited support from nvidia), and I believe the vulkan counterpart (NVK) is in much better shape (no thanks to nvidia, as far as I know), so all in all nvidia being the first to go zink + vulkan (NVK in this case) is probably the best option to have high quality opensource drivers for nvidia cards.

Doesn't Zink still lack va-api support?


Last edited by Leprotto on 11 Mar 2025 at 4:45 pm UTC

I understand that Kepler support in NVK is going to be a while. Is there a timeline for the Maxwell chipset?

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

Is there a logical possibility for Mesa/Nova/NVK etc to support the software stuff like DLSS etc ? Not asking wen's, just curious to know if it's even something that can be done.

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

@Pyrate I disagree with @Shmerl with that the only way to get supported is downstream support.
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.

so, this is a bit off-topic, but the above comment on DLSS got me thinking...

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

back on topic:
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

Awesome to see! Zink is handy to use even on AMD for some older native titles (BioShock Infinite ran much better with it back when I tested).

I'll be interested to see some games like Minecraft benchmarked with Zink on Nvidia GPUs.

I'll be super interested to see an AMD benchmark between pure OpenGL driver (i.e. radeonsi) and OpenGL over Vulkan driver (i.e. zink+radv).

If the bridge solution is on par with native drivers, it could be the end of having to maintain two APIs!

Apparently `radeonsi` is considered the gold standard in MESA world, so it would be a good metric to track. Once we get to 99.5% of radeonsi performance it would be good.

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.