Nouveau Lights Up The NVIDIA RTX 3060 GPU Open-Source Support

[oiaohm]

- In 2010, the existing open render stack (mesa, gallium 3D etc) was a godawful dysfunctional mess, so Nvidia then did the wise thing of abandoning ship and roll their own
- The current open render stack is obviously competitive as seen with latest Phoronix benchmarks of Radeon vs Nvidia GPUs

2010 bit is not in fact true.
https://www.phoronix.com/scan.php?pa...ia_15way&num=4 We are seeing this by 2013 in direct public compare benchmarks.

Was the mesa stack in need of work in 2010 yes it was. Was it dysfunctional mess no it was not because there were functional drivers just not the best performing. Gallium3d that open source drivers use today based on what was used in 2010 just cleaned up there has been no major API redesign in this part. DRI2 of 2008 to 2013 was fixed to DRI3 in 2013. Something interesting here GEM of DRI2 that was deprecated/removed in dri3 because it was insecure is something eglstreams has and basically identical. So yes Nvidia walked way in 2010 and kept the dysfunctional parts so 7 years latter we are still attempting to pull nivida kicking and screaming to stop using that interface.

wertigon its kind of a shock when you look under the covers and notice that Nvidia opengl driver for Linux its no roll their own in a lot of places but like some school kids attempt to copy another parties work by renaming a few things and claiming as their own. Yes the MIT license of the open source graphics stack means they can legally do this.

Nvidia linux driver has come a dysfunctional mess because they started arguing with the upstream where they got code from in the first place. Yes intel with Microsoft also did the reference graphics drivers for windows that were shipped to AMD and Nvidia back in the day. Yes Intel is the upstream that did GEM and who Nvidia developers started arguing with in 2009 over attempts to fix up GEM. Yes as early as 2009 Intel developers were suspecting something wrong with GEM just not able to absolutely put their finger on what the problem was.

Surprise right all all the different platforms Nvidia was supporting for the reference driver implementations had a single common denominator Intel. Welcome to cause of trouble. Nvidia developers basically copied Intel developers work in places into the Nvidia graphics driver design without giving effective credit or even correctly realising it because they were constantly seeing the same thing from what appeared to be independent sources as in different platform reference graphics drivers. Of course not giving credit or realising for Nvidia means when Intel was able to confirm major security/stability problem in 2012 with the design of GEM that also applied to all drivers Intel had ever designed. Nvidia did not realise they were 100 percent effected. Yes that 2012 mistake in Intel graphics driver design was confirmed in the wayland development process.

Yes that fix by Intel starting in 2012 ending with DRI3 also results in Nvidia going all in with eglstreams because they still had not worked out what they were going all in on what Intel had designed in the first place and just called defective. So Nvidia here has ignored the true upstream and they ignored the true upstream because they were not even properly aware where the true upstream to different parts of their driver comes from.

Next thing where does Intel experiment with their next generation graphics driver designs that right on Linux.

There are very valid reasons for AMD to want to work with Intel on Linux for their windows drivers. AMD worked this out look back at the ATI mess with Vista in 2007. Its not like Microsoft at the time really did not have personal to be making the reference graphics drivers to allow them todo OS development incompatible to ATI/AMD and Nvidia at the time but Microsoft did have a reference graphics driver so some other party had to be playing a had here and that was Intel. Nvidia by 2010 seams to have forgotten this as well.

Old saying "keep your friends close and your enemies closer" this kind of does apply to AMD and Intel relationship with open source graphics drivers.

Really Nvidia should be wanting to keep Intel close as well since they have been the repeating source of platform reference drivers and the fact Nvidia drivers have picked up some bad designed from Intel we know about. Of course there still could be more.

AMD legal audit process on their open source and closed source graphics drivers filled in a lot of these blanks for AMD so they are not as likely to miss upstream fixes something event. Releasing documentation for open source development means you do have to map down who designed what and where ideas really came from. So this part of the process is long term beneficial even that it has a upfront cost.

[mdedetrich]

Have you tried using a laptop with nVidia GPU? Obviously you haven't, otherwise you wouldn't have made this statement.

I have, and with Arch/Manjaro getting optimus working wasn't too difficult. Obviously it wasn't as good as it was in Windows but as far as I understand there were problems from both sides (one being NVidia's unwillingness of not putting more than the minimum efffort required and the other being technical issues with Linux i.e. iirc at the time Linux couldn't properly lower power for devices including the GPU which made optimus less appealing)

Ontop of this Windows for obvious reasons is a lot easier for NVidia to work with than Linux (there isn't this fuss about closed source drivers there).

[ezst036]

I'm a monopolist, I don't give a damn about your wishes and demands.

No you aren't. It's nice of you to trot out a strawman and then knock it down, but the reality is that AMD open sourced their drivers so many years ago I can't even count it on both my hands anymore.

Nvidia is many things but monopolist isn't one of them. And even moreso, Intel Arc are knocking on the door here and will also have open source drivers.

You have choices. You simply choose not to make the open source one. You have nobody to blame but yourself.

[ezst036]

What I don't understand is this;

- In 2010, the existing open render stack (mesa, gallium 3D etc) was a godawful dysfunctional mess, so Nvidia then did the wise thing of abandoning ship and roll their own
- The current open render stack is obviously competitive as seen with latest Phoronix benchmarks of Radeon vs Nvidia GPUs

Logic then dictates to go with the path of least resistance; if Nvidia can cut 80-85% of their driver stack to focus on the last 5%, instead of stubbornly bending backwards to keep their incompatible implementation... Why keep it up with the obviously more cumbersome solution, especially as the open stack will probably only improve over time? It took a long way to get the open stack where it is, but just like the Linux Block Device driver, ignoring it at this point makes very little sense.

This is what gets people so upset. Nvidia could slowly start chipping away at their own driver and returning back to the community and they have instead chosen to keep everything to themselves. I think the fight between Nvidia and the open source developers over EGL exemplifies this more than any other.

To put this into different words, Nvidia could be the Valve of its own open source driver now that Mesa and Gallium and the rest aren't a dysfunctional mess anymore and they could be immensely helpful for the whole open source video infrastructure, but they are set on being exclusive and they can't be relied on by us.

Shoulda woulda coulda. Nvidia doesn't help us. That's the fact. I bought AMD because I refuse to give money to a company with a closed source driver. Others want to have it both ways, even if it means we reintroduce star chambers. I'll be happy to recommend Intel once they're actually commercially available.

Stop buying Nvidia. This isn't that difficult.

And even if I had something Nvidia right now, step 1 is Ebay. Out with the old in with the gold.

Again, this isn't that difficult.

[Monsterovich]

Nvidia is many things but monopolist isn't one of them.

In truth, Nvidia is actually a monopolist. Just look at those numbers.

https://wccftech.com/nvidia-intel-gp...ed-in-q2-2021/
http://cdn.statcdn.com/Infographic/i...mal/15172.jpeg

Nvidia is an absolute leader in the market. Nothing has changed for 10 years.

Intel Arc are knocking on the door here and will also have open source drivers.

• Intel has failed to compete with AMD even in the CPU market and it has uncertain future. They forcibly put their shitty cheap CPUs in every laptop to kick out AMD from the market.
• Intel has never previously been successful in the discrete graphics card category.
• I doubt they would make this far especially in the times of GPU shortage.

You have choices. You simply choose not to make the open source one. You have nobody to blame but yourself.

I wanted to buy RTX 3060 Ti, but the prices were insane (they still are) that's why I bought GTX 960 in the second hand market. The older AMD GPUs are an uncharted territory for me. The modern AMD GPUs has even higher prices than modern Nvidia GPUs.

[Danielsan]

I wanted to buy RTX 3060 Ti, but the prices were insane (they still are) that's why I bought GTX 960 in the second hand market. The older AMD GPUs are an uncharted territory for me. The modern AMD GPUs has even higher prices than modern Nvidia GPUs.

Discrete AMD Graphic Cards (not even the most powerful ones) are more expensive than a decent laptop, it is insane, I would never thought we reached this point...

[agd5f]

What I don't understand is this;

- In 2010, the existing open render stack (mesa, gallium 3D etc) was a godawful dysfunctional mess, so Nvidia then did the wise thing of abandoning ship and roll their own
- The current open render stack is obviously competitive as seen with latest Phoronix benchmarks of Radeon vs Nvidia GPUs

Logic then dictates to go with the path of least resistance; if Nvidia can cut 80-85% of their driver stack to focus on the last 5%, instead of stubbornly bending backwards to keep their incompatible implementation... Why keep it up with the obviously more cumbersome solution, especially as the open stack will probably only improve over time? It took a long way to get the open stack where it is, but just like the Linux Block Device driver, ignoring it at this point makes very little sense.

It's not that simple. In reality, upstream is largely meaningless from the perspective of what customers actually use (beyond a few bleeding edge power users). Most customers want support for new asics in old enterprise distros that were released years before the new product shipped. There is frankly not much incentive to go through the trouble to be upstream. The whole upstreaming process can be long and complex and works on a completely different schedule from product release schedules. You need to upstream your code months before product release if you want a chance at getting into a distro release before the product ships. This presents several challenges: you expose your new product early, potentially tipping your hand to your competitors, and product cycles and distro/kernel/mesa/etc. cycles rarely align, so you may not end up getting full support for a new product into a particular kernel release and you can't add new features to released kernels, only bug fixes. So even if you are working upstream, you still need huge teams of engineers to backport changes and maintain parallel trees to support old distro kernels and features that customers want at launch, but are not upstream yet because of bikeshedding or non-aligned schedules. It also doesn't help that lot of other internal teams and end users are more familiar with the windows model where you download a vendor provided driver. So even if the stars align and everything falls into place for upstream support at launch, a lot of people still want packaged drivers they can just download and install. So yes, having open source, upstream drivers is nice and is an important part of the being a part of the Linux community, it's certainly not a panacea.

[Linuxxx]

It's not that simple. In reality, upstream is largely meaningless from the perspective of what customers actually use (beyond a few bleeding edge power users). Most customers want support for new asics in old enterprise distros that were released years before the new product shipped. There is frankly not much incentive to go through the trouble to be upstream. The whole upstreaming process can be long and complex and works on a completely different schedule from product release schedules. You need to upstream your code months before product release if you want a chance at getting into a distro release before the product ships. This presents several challenges: you expose your new product early, potentially tipping your hand to your competitors, and product cycles and distro/kernel/mesa/etc. cycles rarely align, so you may not end up getting full support for a new product into a particular kernel release and you can't add new features to released kernels, only bug fixes. So even if you are working upstream, you still need huge teams of engineers to backport changes and maintain parallel trees to support old distro kernels and features that customers want at launch, but are not upstream yet because of bikeshedding or non-aligned schedules. It also doesn't help that lot of other internal teams and end users are more familiar with the windows model where you download a vendor provided driver. So even if the stars align and everything falls into place for upstream support at launch, a lot of people still want packaged drivers they can just download and install. So yes, having open source, upstream drivers is nice and is an important part of the being a part of the Linux community, it's certainly not a panacea.

Man, I'm reading a lot of frustration out of Your post!

It certainly isn't easy to work with the Linux community!

No wonder nVidia ultimately decided against upstreaming the kernel part of their driver and just sticking to the status quo, which seems to be working out for them just fine, anyway...

[oiaohm]

Man, I'm reading a lot of frustration out of Your post!

It certainly isn't easy to work with the Linux community!

No wonder nVidia ultimately decided against upstreaming the kernel part of their driver and just sticking to the status quo, which seems to be working out for them just fine, anyway...

Except that is only half the problem. When you look at Nvidia drivers you see another set of problems., How many Linux kernels do you think there are in the wild.

Upstreaming your drivers and having them back-ported to the LTS kernel at kernel.org does have its advantages.

Fedora, Ubuntu.... Long list of distributions their kernels have their own custom patchset applied on top of the kernel.org tree. This results in some very fun things like Nvidia drivers not working after particular distribution updates. It also means for items like amd that are open source its possible to have the distribution vendor pick up their driver patchset so reducing issues on end users.

The Linux kernel is going to kick you in the teeth one way or the other as a driver developer.

https://forums.developer.nvidia.com/t/ubuntu-nvidia-driver-installed-but-not-running/166619

This above issue with Nvidia does show another reason why doing something like a upstream is important. Notice the user is having hell because there was a different version of Nvidia driver installed on the system in the past. Upstreaming means that all drivers in the upstream kernel have to compatible with each other.

Nvidia names there Linux kernel modules all the same so you cannot load 2 different versions of Nvidia drivers at the same time. Yes it possible with AMD to have radeon and the amdgpu drivers load at the same time for different cards.

Reality here if Nvidia not going to upstream they do need to make a all in one driver as all in one package that support all currently support Nvidia cards without tripping over itself. This would fix a lot of breakage. Yes even under windows users update their Nvidia GPU and have all hell break loss because the old driver for their old card is conflicting with the new driver. So Nvidia drivers do have their fair share of broken.

Yes interesting enough you update AMD gpu on windows you don't have driver caused failure either. Because AMD is making sure their drivers are compatible enough. There are a lot of things people have to do so that Nvidia gpus work that they should not have to-do and are pure mark of badly quality drivers.

[aufkrawall]

I switched Nvidia cards several times and never had to reinstall the driver on Windows or Linux, where I experienced the opposite with AMD Windows driver. Anecdote experiences are pointless.

Yet I think it has really paid off for AMD to jump through the upstreaming loops. Or, to be more precise, for their users. If amdgpu kernel driver was developed like amdvlk, its reputation would be far worse. 100% sure.

That being said, the Nvidia Linux driver also used to be far worse than its current state. Too bad some really dumb limitations continue to exist (not related to FOSS or how the develop drivers, at least not directly).