Comment by babypuncher | Hacker News Reader

Comment by babypuncher | Hacker News Reader

Parent Full thread

I'm not a GPU driver or graphics programmer, so I'll do my best. Hopefully someone more knowledgeable can chime in if I mess something up.

* Last May, Nvidia open-sourced their proprietary kernel module, after moving their proprietary bits into a firmware blob that runs on the GPU itself. As is, this module is not suitable for being mainlined into the Linux kernel, but acts as a starting point for a proper FOSS module.

* Nouveau developers have been able to use code and knowledge from the open-sourced Nvidia module to improve their mainlined kernel module (more low level hardware access, the ability to load said firmware blob, and the ability to control clock speeds/power states).

* The improved, actually useful Nouveau has allowed for the development of a performant user-space Vulkan driver for Nvidia called NVK, which was mainlined into Mesa a few months ago.

* Today's news is that NVK is now Vulkan 1.0 conformant, which means properly written apps that use the Vulkan 1.0 featureset should work and be performant using Nouveau and NVK/Mesa

> Last May, Nvidia open-sourced their proprietary kernel module, after moving their proprietary bits into a firmware blob that runs on the GPU itself. As is, this module is not suitable for being mainlined into the Linux kernel, but acts as a starting point for a proper FOSS module.

There will probably be no new kernel driver. Nouveau can get the job done now via the proprietary GSP.

> The improved, actually useful Nouveau has allowed for the development of a performant user-space Vulkan driver for Nvidia called NVK, which was mainlined into Mesa a few months ago.

It's faster now, but still slow as a brick. A lot of optimization work is required, but I guess the developers will focus on reaching conformance with more Vulkan versions. By implementing some additional extensions, modern OpenGL versions and OpenCL can then run via Zink and RustiCL. This will make the driver actually useful, hopefully attract users, and help to find bugs and optimization opportunities. Eventually, a native OpenGL driver [edit: actually a Mesa State Tracker] might be required since Zink has a lot of overhead.

What is slow in this case? 1% of the NVidia driver performance or 70%? I could stomach some hit to performance to drop the binary blob.

~5% is what Nouveau managed without GSP. According to a Phoronix forum post I can't find right now, with GSP it's something like 10% to 20% percent of the proprietary driver. Michael Larabel will surely publish numbers soon that are a bit more reliable.

Ouch. That's a bit more than I am willing to handle.

Nouveau was already functional for desktop usage though, apart from certain bugs and limitations. If you just can't stand using the proprietary driver and don't need gaming or compute performance, go for it!

Should note, you currently _can_ (or will soon) get gaming and compute through vulkan or rusticl.

It's just not currently very fast, yet.

If you only get 5% of the power of the device why not simply use the CPUs?

Because you want your system installer or LiveUSBs to work without running GPU in VGA mode at 640×480. Also you get this 5% performance when GPU is clocked at 10% power draw.

Yes but you would go pretty far with a integrated intel if you are only getting 5%

It was ~5% because there was no reclocking whatsoever without GSP support.

Nouveau was never most performant driver, but developers still been able to achieve something like 50-80% performance on 6xx 7xx series cards before Nvidia started to signed firmware shenanigans.

It's not like I defending the driver performance, but considering for decades it was purely reverse engineering effort by skeleton team < 10 people their achievements are outstanding.

I agree. For years the effort was destined to only ever achieve 10% max of its potential performance. Also, there were architectural changes which probably rendered previous optimizations ineffectual.

https://www.phoronix.com/forums/forum/linux-graphics-x-org-d...

It depended a LOT on the workload.

valley? 20%

glmark2? 91%

vkmark? 11%

To some degree this is probably just the vulkan driver and compiler being really, really immature. I expect that the gap will become a LOT closer in the next 6 months, or whenever they get past implementing vulkan 1.3 in the compiler and can put some work into cleanup.

How big of a deal would proper native OpenGL support actually be? My understanding is that OpenGL is more or less deprecated, and any performance heavy graphics applications have long since switched to Vulkan. I would think the performance overhead of a translation layer like Zink would go largely unnoticed when running software old enough to need it on a modern GPU.

I think there is already an OpenGL implementation over Nouveau (4.5 level)? So that can exists as is, or Zink can be an option. And remaining 4.6 parts are Vulkan related, so may be it can reach 4.6 without Zink too now.

OpenGL is deprecated on MacOS only. It remains fully relevant on many platforms, else OpenGL 4.6 would have never happened. Existing heavily optimized legacy applications (especially games) are unlikely to ever switch to Vulkan if no clear advantages can be demonstrated.

Zink is very useful and maybe the best option if existing drivers are buggy or not that performant. But the performance impact is usually very apparent.

Not sure what you mean; OpenGL is still alive and kicking. Apple doesn't like it, but on Linux it's still the dominant way of interacting with the GPU. Vulkan will likely overtake OpenGL at some point, but I think we're quite a ways off from that.

I know OpenGL is still used, but it's not used much for performance intensive applications like AAA video games, it's used for things like desktop compositors, largely because the spec hasn't been improved or changed since 2014.

Maybe Zink is uniquely inefficient, but my frame of reference for how fast these translation layers can be is DXVK, which in some cases is even faster than native when translating DX11 to Vulkan.

Can they reclock the memory and processing cores to the rated speeds, voltages to the rated voltages, and fans to the speeds that prevent things from melting? That's been _the_ stumbling block for a long time, although maybe that's changed in the last year or two.

Pretty sure they can when it comes to much older cards and those Turing+. I think there's a weird time in between uhmm generations (like Maxwell maybe) in which it's not possible. I don't think it's possible with my 960M for example, although I might be wrong.

Reply on news.ycombinator.com