A project I have a very keen eye on is NVK, the open source NVIDIA Vulkan driver developed by the community (not NVIDIA), and it seems like progress on it is going rather well. Developer Faith Ekstrand wrote a bit on the Collabora blog, detailing work that has been done since the original introduction post back in October last year.
Some highlighted feature improvements:
- Support for Maxwell and Kepler GPUs. Karol Herbst posted a merge request adding handling various state setup bits needed for shaders on older hardware back in August. However, even though Karol's branch existed for a while, it stopped working when I added a hard dependency the MME (Macro Method Expander) for draws and clears. Pre-Turing hardware support was finally unblocked by Mary and her work enabling the MME on older hardware. I also spent a week or two in December on Maxwell bug-fixing and it's not too far off Turing these days in terms of CTS pass rates.
- Geometry, Tessellation, and transform feedback. While not required for Vulkan 1.0, these are pretty important features for running modern games. The codegen compiler back-end already supports them so that part was done. In November or so, George Ouzounoudis did the work to plumb them through NVK and enable the corresponding Vulkan features.
- Thomas Anderson implemented VK_KHR_draw_indirect_count as well as flipping on a bunch of smaller extensions.
- Echo has been playing around with NVK+DXVK a bit and has succeeded in getting some games playing. It's still early days and requires some hacks. However, there are a few titles working and I was able to demo Hollow Knight and F1 2017 at the Collabora meet-up in May.
- Mohamed Ahmed is currently working on VK_KHR_sampler_ycbcr_conversion as his GSoC internship project.
There's also support for a great many more extensions, which means they're close to bumping up the version of Vulkan supported from 1.0 to potentially 1.3.
A lot of work is still to go, as it's not yet passing the conformance tests but all the work that has gone into the driver has meant "60% more" tests actually run compared with last year. No current timeline on when to expect NVK to be upstreamed into Mesa directly though, as it's coming along with a needed new kernel API.
As for the current performance? That's still to be worked on, as most of the work is just going into getting it all working with multiple problematic performance areas noted in the blog post. Work is also ongoing on a new back-end compiler for NVIDIA hardware, code-named NAK or Nvidia Awesome Kompiler.
There's a lot more in the post that's worth a full read.
Fun to see especially for me, as today is another day of booting up the GamingOnLinux work machine to be greeted by NVIDIA proprietary driver problems. Although it's not alone in problems. Today is just bug day apparently.
This is great but I'm just afraid that Nvidia will one day decide that they don't want this to be a thing and start requiring some kind of signed packages.It already needs a signed firmware in order to boot the graphic card, the same as amd.
I already moved to AMD but I've got one Nvidia laptop around, will definitely give it a try once it's ready.
It's not 100% opensource graphic stack for the firmware, but it's more flexible than having all the stack propietary.
live tend to give me a bit of trouble with nouveau.
Trying or installing with Intel integrated and then switching to discrete is a bit of a hassle.
I will be able to pass it on to other PCs.
Last edited by Torqachu on 27 June 2023 at 3:35 pm UTC
This is great but I'm just afraid that Nvidia will one day decide that they don't want this to be a thing and start requiring some kind of signed packages.
I already moved to AMD but I've got one Nvidia laptop around, will definitely give it a try once it's ready.
A must recommendation to pick AMD for new gamers (and other kind of users too) on Linux. That's for sure at moment.
It already needs a signed firmware in order to boot the graphic card, the same as amd.
It's not 100% opensource graphic stack for the firmware, but it's more flexible than having all the stack propietary.
I think concern is that Nvidia gives no guarantees about stability of interfaces to use that firmware. They can easily bork things for the open stack by changing something, like they for years were not allowing Nouveau to reclock in the first place. So the fact that now it's possible still relies on Nvidia being in a better mood, and they are nasty in general.
So of course it's great that reverse engineering efforts are now able to achieve more and there is some work on the kernel interface, but it's still on shaky ground unlike with AMD who are working with upstream kernel directly.
If Nvidia will work with upstream for a change, that would be much better.
Last edited by Shmerl on 27 June 2023 at 9:09 pm UTC
Fun to see especially for me, as today is another day of booting up the GamingOnLinux work machine to be greeted by NVIDIA proprietary driver problems.
Did your order of 7900 XTX not work out in the end?
So is there hope for my old gtx660?
live tend to give me a bit of trouble with nouveau.
Trying or installing with Intel integrated and then switching to discrete is a bit of a hassle.
I will be able to pass it on to other PCs.
GTX 660 is Kepler, so NVK could work on it. However, performance will be very low due to missing reclocking support – only Turing GPUs and later will support it thanks to the GSP firmware (NVIDIA's own open kernel driver).
The lack of reclocking can make a GTX 660 slower than most integrated graphics nowadays.
Last edited by Calinou on 28 June 2023 at 10:06 am UTC
still slower then propriatary driver 470 (officially driver 390 is the last one supporting the 660 but driver 470 still works, nothing newer thought)
See more from me