NVIDIA Developer Talks Openly About Linux Support

[mtippett]

Obviously Matthew Tippet has so much to say, you've interviewed the wrong team, lol.

Tippett (note the double "t").

Well, it isn't corporate, so I am just making industry observations. If it was an AMD article, then my comments would be way more muted .

Obviously there is a common scenario for both. Read whatever you want into my comments .

[yotambien]

Despite statements to the contrary, this IS typical marketing BS. Not to mention the fact that the questions asked were *SEVERELY* sensored from those listed in the original thread. Yes, some of the questions were rude, but facing rude questions is the price you pay for writing a binary blob driver for Linux.

Ah, so there is a price to pay for supporting Linux in different terms than those_you_would like? And the price is that they have to stand a crowd of morons behaving rudely? And what is the price then for those who don't support Linux in the first place? Would crucifixion be enough for you?

They have basically come out and stated in no uncertain terms, that they are sitting on their a$$es.

Is that_really_all you could gather from the (quite good) article?

How exactly does the code being shared between microshaft and *nix relate to supporting open source? We don't want your crap code. We want *specifications*.

No, YOU don't want their 'crap code'. Others do want their hardware to work, open source or otherwise. Don't try to represent Linux users as a whole. If anything, you represent the enlightened minority who still has problems spelling Microsoft after all these years.

IP from specifications? You know perfectly well that everything in your chips has been reverse engineered and documented by AMD, Intel, and everyone else with deep pockets using electron microscopes (since that is what you yourself do...), so the only groups who could benefit (in the sense that they would compete with you) from the IP giveaway (i.e. those who are in the GPU business) that the specifications might lead to *ALREADY HAVE IT*.

Interesting. Next time I use an electron microscope I'll put a couple of drivers in the specimen holder to check what they look like. That'll be fun.

Good news is that the AMD OSS drivers are in a great state. I think I'll drop the $25 and pick up a nice new AMD card -- light all my nvidia's (2) on FIRE.

Please, go ahead. Can the rest of us now sell our souls to [insert evil company name here] and use binary blobs to make our hardware work when/if we are so inclined? (without the stone-throwing if possible).

[energyman]

@energyman

ATI chips are not produced in germany, only some AMD CPUs. Ironically Nvidia+ATI chips are produced by the same company

I know that.
The company is TSMC.
But who knows, maybe GloFo will produce AMDs graphic chips in the future too?

there were many good reasons for me to buy an amd cpu. That the silicone was done in Dresden was the icing on the cake
chuipset was.. hmm *shrug* the a770 board had everything I needed and after the last nvidia board I hoped for some less bugs (and got disappointed, but AMDs kernel troopers were nice and helpfull).

The 3870: I was fed up with nvidia's driver and AMD started supporting open source. Two very good reasons to switch. And so far I am a happy little panda.

So happy that my next card will be a 5770 or 5850.

[mtippett]

Nothing definite, no, but we do get a lot of requests for it and it is something I hope we can pursue in the future.

Hope is not a definite thing
What I've meant was in near term. Not in a long possible term...

It's PR speak. "Hope" is nearly the exact opposite to "no plans". These are closer to neutral than "have plans" and "won't" respectively.

I'd personally look to push the Unigine demos (Tropics, their upcoming ones) as great techdemos. It's cross platform, they have a commitment for Linux and it's great eyecandy. Get them as part of the staple for both Linux and Windows bencharking, and you won't need the demos.

(If we can displace furmark for OpenGL testing with something cross-platform it helps keep the OS neutral technologies.)

But no as Linux's kernel approved and correct way.

The "approved way" is transient, there is no stable API under Linux. The "correct way" is even less realistic. TTM/GEM/etc, the churn is expensive for the components that hook into it. If you are out of tree, you get the cost of churn (in the kernel interface layers), but the stability in the areas that you care about.

Realistically, the OSS drivers circulate and refactor out interfaces to improve maintainability. The binary drivers extract out functionality to provide stability and increase re-use. Different purposes triggered by different constraints.

[mtippett]

Interesting. Next time I use an electron microscope I'll put a couple of drivers in the specimen holder to check what they look like. That'll be fun.

*chuckle*

(actually to the original author) Realistically, remember that even though the products get launched to market every 9-12 months, the actual product development cycle is measured in 2-4 years (or longer). Even if by looking at the top layer of silicon you get a great idea, it will still take another 2-4 years before you can possibly start to integrate it. In the GPU market, that is 3 or 4 generations of products.

ie: R300 derived tech would have only come out around the launch of the RV670.

Matt

[Jimmy]

How exactly does the code being shared between microshaft and *nix relate to supporting open source? We don't want your crap code.

How exactly does making code cross-platform make it "crap code"? Should we go on to list all the software which runs on BOTH Linux and Windows and label them "crap code"? The list is rather long.

[dlang]

The main comments below are asking what is the usage of the tech, not what is the tech itself.



KMS is an interesting one, where do you get value from this? There are a couple of areas that it might add vale.

o BSOD equivalence - get the log messages on the screen with an oops. The joke of the Windows world applied to Linux. I would expect it'll feel just like the old Sun Workstations from 20 years ago.
o "Flicker free" boot. Well, I don't really see too many problems with this. Sure Apple has it - but that is a closed system, top to bottom. But what value does it *really* provide?

a large part of the benifit of switching to KMS is simplification. X.org is conenctrating on making this shift, and viewing kernel mode selection as the primary focus going forward.

they will continue to support the legacy mode (for cards that don't do this, or for OS options that don't implement KMS), but it's going to be just that, legacy, and that means that over time you are better off not using it.

[myxal]

KMS is an interesting one, where do you get value from this?
*snip*
But what value does it *really* provide?

Reliable suspend/resume, duh. Since switching to Karmic beta, my laptop (intel GM965) hasn't hardlocked during either operation once, something I can't say about Hardy or Jaunty, which would stop suspending or hardlock sometime during suspend/resume after the 4th iteration. Now only if plasma-desktop was as reliable...

[Vadi]

Thanks a ton!

[mtippett]

a large part of the benifit of switching to KMS is simplification. X.org is conenctrating on making this shift, and viewing kernel mode selection as the primary focus going forward.

Can you expand on your view on simplification?

From my discussion with the X devs pushing KMS, it solves a number of problems
o Flicker on boot (desktop experience - RH is investing here)
o BSOD like behaviour (don't laugh, it's coming with KMS)
o Removes the other kernel drivers from the picture (directfb, vesafb/radeonfb, etc). The X devs are open to former kernel fb devs joining them, but don't really care to directly include their interfaces.
o Some say reliable suspend/resume (see my upcoming response for that).

they will continue to support the legacy mode (for cards that don't do this, or for OS options that don't implement KMS), but it's going to be just that, legacy, and that means that over time you are better off not using it.

That isn't the Linux way. All your devices get moved to the new API or they are dropped from the kernel. Can't suck and blow at the same time.