Mesa NVK Vulkan Driver Now Declared Vulkan 1.3 Conformant, Mesa 24.1 To Build By Default

[partcyborg]

I haven't been on green team for quite a few years now.
How good is nVidia open source stack, compared to closed version ?
Does it support CUDA stuff ?

Wait, so kernel driver is actually open-sourced by nVidia ? Is it part of the official kernel ?

The nvidia kernel driver is now open source. It is not upstream nor will it ever be as it is designed around sharing as much as code as possible with the windows kernel driver. The userland side of nvidia's drivers are still closed source.

[remm]

its still pretty garbage. if you want good open source, stick with amd / intel gpu's.

The problem with Nouveau is that it's pretty much an encouragement to buy NVidia. Actually the new support provided by the firmware is still pretty bad (ABI breakage and so on) and then the driver itself will always lag heavily behind in performance and/or various compatibility issues. So at some point you'll have to get into the proprietary driver hell.

[sarmad]

I haven't been on green team for quite a few years now.
How good is nVidia open source stack, compared to closed version ?
Does it support CUDA stuff ?

Wait, so kernel driver is actually open-sourced by nVidia ? Is it part of the official kernel ?

I wish people who answered your question didn't give such confusing answers. Here is the proper answer:

nVidia did open source their kernel driver, with the user space driver still closed. This, however, is not upstreamed and probably will never be. I'm not sure what nVidia's goal is, but opening the kernel driver was helpful to the Nouveau team in improving the status of the Nouveau driver.

Now, the status of the Nouveau driver is that they finally managed to get reclocking working (through the use of an nVidia provided firmware called GSP). So, with the very latest Nouveau driver, which isn't yet released in any mainstream Linux distro, you should have OpenGL and Vulkan drivers that are conformant with latest versions and with reclocking support, i.e. better performance than it was. But I'm not sure how much better the performance is, reclocking was the biggest hindrance to performance, but I can't imagine it being the only one. We'll have to wait and see. I'm also not sure about stability of these drivers.

In short, open source nVidia drivers are progressing really fast now, but will probably not be in a good shape for daily use until maybe the end of this year at least. That's my guess.

[oibaf]

Nice that you are trying something different than usual beer! 🍾🥂

[Rovano]

https://www.collabora.com/news-and-b...rime-time.html

Nice! Zink+NVK.
Good bye Open GL.

[rmfx]

Congrats on that.
If you achieve 90 percents perf of blob drivers, I’ll use it.

[NeoMorpheus]

And does this driver provide proper hdmi 2.1 support?

[dlq84]

And does this driver provide proper hdmi 2.1 support?

You think the NVK team has more leverage against the HDMI Forum than AMD?

https://www.phoronix.com/news/HDMI-2.1-OSS-Rejected

[STiAT]

I hope I'll be able to try this on Fedora 40. I'd love to get rid of the proprietary linux driver...

[toughy]

you are using linux 6.8, right?

Yes. On Arch Linux I compiled drm-next and drm-tip.

On Fedora I can see in gdb function nouveau_ws_context_create() returns -19 (which is -ENODEV no such device). This function uses `drmIoctl(fd, DRM_NOUVEAU_CHANNEL_ALLOCATE,...)`, which is a wrapper around ioctl(fd, DRM_IOCTL_NOUVEAU CHANNEL_ALLOCATE, ...). The fd refers to file /dev/dri/render128, which belongs to group render, that my user belongs to as well.

I can not find the ioctl() implementation for the DRM_IOCTL_NOUVEAU_CHANNEL_ALLOCATE, and I do not know where else to look, the macro definition is simply defined but not used in drm-next repository.

Where can I find the right repository and branch for the latest kernel-mode GPU driver ?

[Edit: everything works now, it turns out an additional patch was still needed to fix GSP-RM for GeForce RTX 2080 Ti GPUs]