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.
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?
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 ********
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. :)
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.
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.
- 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.
![](https://i.imgur.com/QB4iBLb.png)
Cuphead still working (unity games)
![](https://i.imgur.com/lMW5GMJ.png)
^_^
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?
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?
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.
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
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
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.
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:+ Click to view long quote
(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.
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
Here is a relevant quote from Ilia Mirkin, one of the developers of Nouveau:+ Click to view long quote
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.
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.
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
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?
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
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
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
See more from me