Don't want to see articles from a certain category? When logged in, go to your User Settings and adjust your feed in the Content Preferences section where you can block tags!
We do often include affiliate links to earn us some pennies. See more here.

It seems to be a busy weekend! NVIDIA have put out a new version of their Vulkan beta driver and it's an interesting one.

Today, NVIDIA 415.22.05 became available and as expected of this driver series it adds in new Vulkan extensions. Specifically, it adds support for VK_KHR_depth_stencil_resolve, VK_EXT_buffer_device_address, VK_EXT_memory_budget, VK_EXT_memory_priority (only for Windows currently) and VK_EXT_pci_bus_info.

The extra interesting bit is the improvement they listed in this driver version. They mention that it has "Better pipeline creation performance when there is a cache hit" so it will be an interesting driver to test out. Good to see NVIDIA continue working on performance!

Find the driver info here.

For those on Ubuntu wishing to test out the beta driver, there is this PPA which sadly hasn't been updated since October last year. Hopefully they will get moving on that sometime soon. I'm unsure how other distributions handle beta drivers like this, hopefully they make it easy.

Article taken from GamingOnLinux.com.
14 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly checked on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly. You can also follow my personal adventures on Bluesky.
See more from me
The comments on this article are closed.
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
48 comments
Page: 1/3»
  Go to:

tpau Jan 6, 2019
I still wonder why they don't go the AMD way and share development of the base driver with the opensource community.
Would make the proprietary part smaller and easier to maintain and make the OS enthusiasts happy.
Is there any convincing reason why the signed firmware is held back?
pete910 Jan 6, 2019
View PC info
  • Supporter Plus
I still wonder why they don't go the AMD way and share development of the base driver with the opensource community.
Would make the proprietary part smaller and easier to maintain and make the OS enthusiasts happy.
Is there any convincing reason why the signed firmware is held back?

Because their ********
mahagr Jan 6, 2019
nVidia drivers are bad quality which is likely the main reason why they do not open up the code. I'm frustrated on their drivers as they force the card to run on maximum power for 45 seconds every time there's an opengl draw call. Basically it means that if you install Ubuntu and use default Gnome (which uses opengl X composite extension), your graphics card never goes into powersave state and consumes ~4x more power than it should. They have the same issue in Windows, but because of architectural differences it's not as bad in there.

I guess they do that because of nobody has bothered to implement proper power saving feature and because of not running the card in maximum power makes the cards to look bad in benchmarks. IMHO they really should fix the issue and allow cards to run on optimal clocks as laptops get more and more common. :)
Shmerl Jan 6, 2019
I still wonder why they don't go the AMD way and share development of the base driver with the opensource community

Because it's Nvidia. Their managements are jerks and don't get what open source collaboration is. Otherwise they would have opened their kernel driver already.
Thormack Jan 6, 2019
I'm waiting the new AMD RX3000 graphics cards and I'll be done with Nvidia and their'e proprietary drivers.

More or less same here.

We might also have the Intel gaming GPU as a choice in the future.
Avehicle7887 Jan 6, 2019
I see many people saying Nvidia drivers are bad etc without mentioning a few key points. Sure they are closed source and not as friendly as others in the Linux world but:

- They've offered Linux support for a long time, I still remember NV drivers back when Ubuntu was all the rage (Ubuntu 10.04 etc).
- Performance of their drivers is competitive, and it took a while for (Mesa) AMD to catch up (and now sometimes perform better).
- They have contributed fixes to their drivers to help with DXVK.
- Their drivers can be used on some old distros without too much fuss, not something you can easily do with OSS ones.

I'm not saying they are perfect either, the crappy Prime support on mobile GPUs is why I don't buy laptops with NV GPUs, I'd rather have Intel HD if no AMD alternative is available. However they are far from the bad quality type that some people make them out to be.
mrdeathjr Jan 6, 2019
This driver comes with vulkan 1.1.96

![](https://i.imgur.com/QB4iBLb.png)

Cuphead still working (unity games)

![](https://i.imgur.com/lMW5GMJ.png)

^_^
jens Jan 6, 2019
  • Supporter
nVidia drivers are bad quality which is likely the main reason why they do not open up the code.

And you base your assumptions on what exactly?
jens Jan 6, 2019
  • Supporter
Because it's Nvidia. Their managements are jerks and don't get what open source collaboration is.

So you had an interview with somebody from the Nvidia management?
jens Jan 6, 2019
  • Supporter
I get that people are not happy with the way NVidia is handling things for Linux, but name calling and assuming that their engineers are amateurs is just cheap talk and usually gets you nothing. They do things the way it fits for them, for quite some people this workflow and choices seems to work too. If you don't like their way, just move on.

Back on topic: "Better pipeline creation performance when there is a cache hit" sounds indeed interesting, I would be curious to know how much performance win it yields in real life scenarios.
Shmerl Jan 6, 2019
So you had an interview with somebody from the Nvidia management?

It's not developers' decision, or you expected otherwise for some reason? Actual Nvidia Linux developers said as much, that it's their management that has to do something for better collaboration.

And it is jerk behavior from that management, either we move on or it, we should call it what it is.


Last edited by Shmerl on 6 January 2019 at 7:15 pm UTC
jens Jan 6, 2019
  • Supporter
So you had an interview with somebody from the Nvidia management?

It's not developers' decision, or you expected otherwise for some reason?

You called their management people jerks, so I guess you ever talked to one of them and can justify your statement? See above, if you don't like their decisions, just fine and you are rightful to do that. But calling someone a jerk you have never talked to (my assumptions) is just cheap and below every level.


Last edited by jens on 6 January 2019 at 7:16 pm UTC
Shmerl Jan 6, 2019
You called their management people jerks, so I guess you ever talked to one of them and can justify your statement?

I did. Because they are not upstreaming their kernel driver and preventing nouveau from doing it for them efficiently.
Shmerl Jan 6, 2019
Here is a relevant quote from Ilia Mirkin, one of the developers of Nouveau:

Reclocking must be done in firmware. NVIDIA now requires signed firmware to access a lot of useful functionality. They will never release the firmware in a nice redistributable manner, so the avenues for implementing it become much harder:

(a) Figure out a way to extract the firmware from their released drivers (harder than it sounds) and how to operate it to do the things we need
(b) Find a bug in their firmware to use to load our own code into the secure environment (any such exploit would be patched, but once we have a version of the firmware that's exploitable with signatures, we can just keep loading it instead of whatever's the latest)

Of course all that gets us is ... firmware which can toggle stuff GPU-side. Then we have to develop the scripts to actually perform the reclocking to pass on to the firmware. This is the hard part -- due to the wide variety of hardware, ram chips, etc there can be a lot of variation in those scripts. A single developer might only have 1% of the boards out there, but by fuzzing the vbios and seeing how the blob driver reacts, we can get much more significant coverage.

As part of the signed-everything logic, the blob driver now also verifies that the VBIOS hasn't been tampered with, which means that developing reclocking scripts will require different techniques.

Moral of the story... just get an Intel or AMD board and move on with life. NVIDIA has no interest in supporting open-source, and so if you want to support open-source, pick a company that aligns with this.
+ Click to view long quote

Yes, I call that jerks, because it's totally in their ability to do it. They don't want to, since they want to control the market by using their driver. Functional nouveau will totally bust that ability, since it will let users themselves decide how to use their hardware.


Last edited by Shmerl on 6 January 2019 at 7:23 pm UTC
jens Jan 6, 2019
  • Supporter
Here is a relevant quote from Ilia Mirkin, one of the developers of Nouveau:

Reclocking must be done in firmware. NVIDIA now requires signed firmware to access a lot of useful functionality. They will never release the firmware in a nice redistributable manner, so the avenues for implementing it become much harder:

(a) Figure out a way to extract the firmware from their released drivers (harder than it sounds) and how to operate it to do the things we need
(b) Find a bug in their firmware to use to load our own code into the secure environment (any such exploit would be patched, but once we have a version of the firmware that's exploitable with signatures, we can just keep loading it instead of whatever's the latest)

Of course all that gets us is ... firmware which can toggle stuff GPU-side. Then we have to develop the scripts to actually perform the reclocking to pass on to the firmware. This is the hard part -- due to the wide variety of hardware, ram chips, etc there can be a lot of variation in those scripts. A single developer might only have 1% of the boards out there, but by fuzzing the vbios and seeing how the blob driver reacts, we can get much more significant coverage.

As part of the signed-everything logic, the blob driver now also verifies that the VBIOS hasn't been tampered with, which means that developing reclocking scripts will require different techniques.

Moral of the story... just get an Intel or AMD board and move on with life. NVIDIA has no interest in supporting open-source, and so if you want to support open-source, pick a company that aligns with this.
+ Click to view long quote

Once again, feel free to disagree what Nvidia is doing and be happy with your choice for your preferred hardware vendor.
I made my point that I would refrain from name calling, especially if one has never spoken to one of their (management) people.
Shmerl Jan 6, 2019
Once again, feel free to disagree what Nvidia is doing and be happy with your choice for your preferred hardware vendor.

I did exactly that by using AMD. I surely disagree, and see nothing wrong in saying that Nvidia's behavior is nasty. What I find strange on the other hand, are attempts to whitewash it, especially coming from Linux users who should know better.


Last edited by Shmerl on 6 January 2019 at 7:29 pm UTC
jens Jan 6, 2019
  • Supporter
What I find strange on the other hand, are attempts to whitewash it, especially coming from Linux users who should know better.

So I'm a jerk too because I don't like name calling and respect others decisions, even if I don't agree?
Shmerl Jan 6, 2019
So I'm a jerk too because I don't like name calling and respect others decisions, even if I don't agree?

That's a shaky moral stance I'd say ("I respect any decisions no matter what they are"). I don't respect decisions that are done for anti-competitive purposes, which is the case here.


Last edited by Shmerl on 6 January 2019 at 7:39 pm UTC
jens Jan 6, 2019
  • Supporter
So I'm a jerk too because I don't like name calling and respect others decisions, even if I don't agree?

That's a shaky moral stance I'd say ("I respect any decisions no matter what they are"). I don't respect decisions that are done for anti-competitive purposes, which is the case here.

No NVidia (or Intel/AMD whatever) manager has ever beaten me, so I really feel no need to call one a jerk :). I'd state that I don't agree, vote with my wallet and just move on.


Last edited by jens on 6 January 2019 at 7:55 pm UTC
mrdeathjr Jan 6, 2019
@Liamdawe

Please moderate theme, discussion goes to other things non related with this release driver

^_^


Last edited by mrdeathjr on 6 January 2019 at 7:49 pm UTC
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.