NVIDIA have put out a new Vulkan beta driver with better pipeline creation performance

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?

Quoting: tpauI 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 ********

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. :)

Quoting: tpauI 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.

Quoting: GuestI'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.

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.

This driver comes with vulkan 1.1.96



Cuphead still working (unity games)



^_^

Quoting: mahagrnVidia 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?

Quoting: ShmerlBecause 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?

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.

Quoting: jensSo 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

Quoting: Shmerl

Quoting: jensSo 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

Quoting: jensYou 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.

Here is a relevant quote from Ilia Mirkin, one of the developers of Nouveau:

QuoteReclocking 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.

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

Quoting: ShmerlHere is a relevant quote from Ilia Mirkin, one of the developers of Nouveau:

QuoteReclocking 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.

Quoting: jensOnce 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

Quoting: ShmerlWhat 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?

Quoting: jensSo 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

Quoting: Shmerl

Quoting: jensSo 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

@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