> never ... help nouveau

https://lwn.net/Articles/568038/

1) Those documents are no longer available (or the link is broken)

2) The contribution was actually not very helpful for nouveau, much of the information was already known. nvidia has done practically nothing since then to support nouveau in any meaningful way, with the exception of a one-off patchset to implement some support for Tegra.

I suspect you just found the first link that seemed to validate the point you are trying to make, without actually understanding what is actually (not) going on.

1)link is broken

http://download.nvidia.com/open-gpu-doc/DCB/1/DCB-4.0-Specif...

> nvidia has done practically nothing since then to support nouveau in any meaningful way

There's an awful lot of stuff in that directory for that to be the case.

> suspect you just found the first link that seemed to validate the point you are trying to make, without actually understanding what is actually (not) going on.

Funny, I think the same thing when people say "nvidia never helps nouveau."

Good thing nvidia hardware has not changed one bit since they released that limited amount of information in 2013!

There's a reason I said "that directory" not "that file."

Cutting through the sarcasm, here's some Volta info: https://download.nvidia.com/open-gpu-doc/Display-Ref-Manuals...

As reported on in phoronix:

https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-V...

https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-V...

"Before getting too excited, this is strictly about the display hardware and not about the 3D engine, etc." - from the link you gave. So still a show but not a real help.

that was 1 doc out of many on http://download.nvidia.com/open-gpu-doc/

multiple docs have been updated in this past year

It happened once and 5 years ago. And not a big deal anyway.

It is only a small piece of documentation Nouveau developers need. Looks more like a show than a genuine help. Also it is a link from 2013...

Isn't the current problem that modern cards will never exit a very low power boot up state with dogshit performance since that requires a signed firmware of some sort?

I think that sums it up nicely. Nvidia want the opensource driver to work just well enough that you can get a picture to install the proprietary one.

May be when Intel will throw in their discrete GPUs with open drivers, Nvidia will stop jerking around and will collaborate with nouveau developers.

Currently Nvidia are complete jerks when it comes to helping nouveau with documenting their hardware.

full disclosure that I work for nvidia, but not on drivers. many driver devs internally do actually contribute to nouveau as well. please don't make baseless claims simply because you're angry.

Well, they're not doing a very good job then. I just upgraded to Ubuntu 18.10 on my machine with a Titan X Maxwell, and guess what? Booted to a black screen. Related to Nvidia's refusal to work with everyone else on Wayland support, no doubt.

The sad thing is that this experience is typical and expected for me by now. Nearly every time I install or upgrade Linux, I have to spend hours troubleshooting Nvidia driver issues. Cumulatively, several days of my life have been wasted on this. People are angry because Nvidia has made and continues to make bad decisions that result in a poor experience on Linux.

> Related to Nvidia's refusal to work with everyone else on Wayland support, no doubt.

this is more complicated than I can really comment on, but from my understanding it was not an issue of nvidia's refusal to work on it so much as it was an issue of nvidia not being allowed a seat at the table to discuss it. the wayland protocol was effectively demanding a ground up rewrite with no ability for compromise purely because nvidia being closed source meant they weren't entitled to an opinion. which is... wow

I'm sorry that's the typical experience you've had with the driver, though I'm a little surprised by that actually. I don't run x on ubuntu, but I know there were some issues in the past where they were attempting to "smartly" configure the driver for certain setups and instead end up causing headaches. Though that is really my main issue with ubuntu in general, that they try to "help" you because they know best, and also one of the reasons I don't run it. I just use the runfile installer and let it auto-generate the base xconfig.

I'm not blaming developers. It's clearly Nvidia management's fault. Developers don't decide this.

And it's not baseless. Where is their documentation on reclocking for desktop GPUs? Once they hid it behind signed firmware, doing it from nouveau became a major pain, because it requires complete blind reverse engineering. All this effort could be spent on making the drivers better instead, if Nvidia would have provided documentation.

It's the reason you can't use nouveau for gaming today on anything recent.

you talk about enabling signed firmware like it was done for a proprietary reason and not a massive security one. take a look at the fake Pascal gpu's on ebay where people are flashing unsigned firmware to old Fermi cards to fake windows into thinking they're actual Pascal cards...

that said, youre right that it's not good that the nouveau driver is so far behind the proprietary one, and Im not trying to say that nvidia isn't at fault for that, just that it's a more complicated issue that people tend to portray it as.

also:

http://download.nvidia.com/open-gpu-doc/MemoryTweakTable/1/M...

http://download.nvidia.com/open-gpu-doc/MemoryClockTable/1/M...

The problem is not just in the signed nature of the firmware, but in the fact that there is no normal way to control it to achieve needed results like card reclocking, which is required to run it in anything but minimal performance mode. And there is no documentation on any of this for different boards. What stopped Nvidia from giving access to these features and documenting it for developers? I don't buy the security argument. Reclocking works just fine through open AMD drivers for instance.

As Nouveau developers put it:

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

In the end, crippling reclocking can easily be seen as an anti-competitive stance against nouveau, to prevent it from competing with the blob.

First Intel needs to learn how to make discrete GPUs that are actually worthwhile to target.

Anyone should, it doesn't mean that Nvidia won't feel the pressure that will affect their anti-competitive tactics.

This is correct. What's the point of open sourcing this library when you can't even use their cards on the open source operating system. From what I understand, it wouldn't be that difficult for them to allow the community to develop a proper driver for their devices on Linux, they just don't want to. I think it's fair to point out the hypocrisy of this announcement.

> What's the point of open sourcing this library when you can't even use their cards on the open source operating system.

The point is that these two are completely orthogonal. It's like saying: what's the point of writing open source software for an x86 when the x86 RTL is closed source.

With an open source PhysX library, you can make PhysX work in any environment.

> With an open source PhysX library, you can make PhysX work in any environment.

Not if their drivers on other environments dont support it. Consoles are all AMD, and NVIDIA only has 3-4% more market share on PC, while intel has around 70% of the market share. That's a really low number of platforms for a proprietary piece of tech.

PhysX works on a CPU, and the GPU acceleration is optional.

It's actual garbage on CPU tho, it's made to be GPU accelerated. There's many more physics engines that arent proprietary to certain hardware that run way better than physx

> It's actual garbage on CPU tho, it's made to be GPU accelerated

Have you a source for this? Plenty of AAA games ship with CPU PhysX only. My experience with GPU PhysX is that it's not worth the resource usage, and the overhead and limitations (e.g. to do with collision filtering) make it not really suitable for general purpose use.

> There's many more physics engines that arent proprietary to certain hardware that run way better than physx

Again, PhysX isn't locked to any hardware. The GPU acceleration (which most games don't use) is locked to an NVidia GPU, but the CPU physics engine isn't. There is Havok and Bullet physics, both of which have pros and cons but aren't necessarily "better" than PhysX. If you have any numbers or sources to prove otherwise, I'd love to see them.