NVIDIA Developer Talks Openly About Linux Support

[CrystalCowboy]

I see they didn't bother to supply an answer to my question about GeForce 3D (now apparently renamed NVidia 3D Vision on Linux. I guess selling product to an eager market is not a priority for them.

[movieman]

There's pieces that they just can't expose to the world, and it's not just due to "embarassment" or hiding flaws (which is one of the reasons some other vendors don't do this...they've got design defects in their silicon... )- or even Microsoft's influence as some keep intimating.

I doubt you'll find many non-trivial chips without design defects: building a chip with hundreds of millions of transistors based on a huge stack of low-level specifications converted to a design language and translated into wires on a silicon chip without something going wrong somewhere in the process is extremely hard. Almost all the non-trivial chips I've worked with have had defects of some kind, documented or undocumented; the last custom chip I worked on in my previous job had one defect that took me more than a month to track down and we never even worked out how it occurred... as far as we could determine the spec was right, the VHDL implementation was right, and it broke somewhere between the VHDL and silicon.

One of the big issues with releasing driver source is patents: not to imply that any of these companies is _deliberately_ violating someone's patents, but so much of hardware design is patented these days that you'd need to hire a whole gang of lawyers working full-time just to tell you whether you are breaking any obscure patent. This was one of the reasons why the hardware company I worked for was reluctant to release open source drivers.

[mtippett]

I doubt you'll find many non-trivial chips without design defects: building a chip with hundreds of millions of transistors based on a huge stack of low-level specifications converted to a design language and translated into wires on a silicon chip without something going wrong somewhere in the process is extremely hard. Almost all the non-trivial chips I've worked with have had defects of some kind, documented or undocumented; the last custom chip I worked on in my previous job had one defect that took me more than a month to track down and we never even worked out how it occurred... as far as we could determine the spec was right, the VHDL implementation was right, and it broke somewhere between the VHDL and silicon.

2.15 billion things can go wrong... And they do.

But remember that GPU companies don't just sell an chip, they sell a system which is both HW and SW.

You only _really_ need to document the errata around the outside of the system. ie: for a GPU, it is only the electrical HW interface and the SW interface that is sold. The SW facing HW bugs are no different than silicon interconnect between HW block A and HW block B. Choosing a different resistor or capacitor to pull a pin in a different way removes the "issue". The datasheet for the chip will just say to use the new resistor and won't talk about the what happens if you don't use it.

The same things happens at the system level. The chips are sold as part of a system with software. So the outward issues are SW visible (on top of the driver), or HW visible (how you lay out the chip), the HW to SW layer isn't really relevant. The people who directly buy the chips virtually never write a driver.

Then when Open Source comes in it is a completely orthogonal model. The end user (who buys a card or a system from someone who actually bought the HW and the matching driver) doesn't care about the furnished driver. They want to use their own driver. Then suddenly the driver visible issues at the HW to SW layer become absolutely critical. But the IHV who produced the chip hasn't ever needed to document the HW to SW layer issues because they don't sell it that way.

That is where bridgman comes in and as Andy indicated, it is expensive to pull together what is needed to document the HW to SW layer sufficiently to communicate it externally. The only other alternative is to have someone internal to write the driver (that would be Alex) and so then you are back to the original situation where you are receiving a HW/SW system complete from the vendor.

It kind of makes OSS an expensive proposition, you either fund the development, or you fund the documentation creation. But it definitely is not cheap.

One of the big issues with releasing driver source is patents: not to imply that any of these companies is _deliberately_ violating someone's patents, but so much of hardware design is patented these days that you'd need to hire a whole gang of lawyers working full-time just to tell you whether you are breaking any obscure patent. This was one of the reasons why the hardware company I worked for was reluctant to release open source drivers.

It goes deeper. There are

o Commercial - we bought this code and can't release it
o Legislative - we have macrovision related code, and can't release it
o Competitive - we have secret juju that we don't want to release
o Contractual - we have license agreements (for patents), and can't release it.

issues all through the driver source. Let alone the risk of unknowingly violating patents.

All of these constraints make it very difficult to tease out what can and cannot be released and the relative risk associated with it. Particularly where after release, the company will still have "ownership" of it.

Regards,

Matthew

[yotambien]

If I linked to AMD/ATI forums we'd see something other than a long list of things gone wrong and cries from users drowning in their tears?

Ok, where's the link? Here?

No. More like HERE and HERE . Two for the price of one. Any other questions?

[V!NCENT]

@Matthew Tippett:

First of all thanks for the insight

But uhm... at least I couldn't care less about features. All I, as a customer, want is that ISA doc -> Gallium3D converted and state tracker features on top of that.

All problems solved, right?

Correct me if I am wrong though...

[BhaKi]

but so much of hardware design is patented these days that you'd need to hire a whole gang of lawyers working full-time just to tell you whether you are breaking any obscure patent.

Programming specs need not speak about internal hardware design; they just need to document the interface to hardware. So patents can't be a problem, right?

[BhaKi]

It kind of makes OSS an expensive proposition, you either fund the development, or you fund the documentation creation. But it definitely is not cheap.

Thanks to mtippett for the insightful comments. While I definitely agree that open-source drivers are an expensive proposition, I don't think that the same logic applies to programming specs.

Firstly, inside the company, the person/team that designs hardware is most likely different from the person that writes the usual proprietary drivers. How do these separate teams communicate? The hardware designing team must be documenting the interface which is then being used by the driver writing team. I agree that this documentation won't be sane enough and clear enough for releasing to the general public. But that is all there is to it: the cost involved in releasing programming documentation is just the cost of sanitizing these internal documents which is far less than the cost of writing documentation from scratch.

Secondly, while patented code is a problem against open-sourcing drivers, how would it make it difficult to release programming specs? These specs need not contain either patented code or patented hardware design.

Please correct me if I'm wrong about something.

[Ex-Cyber]

Secondly, while patented code is a problem against open-sourcing drivers, how would it make it difficult to release programming specs? These specs need not contain either patented code or patented hardware design.

They need not describe patented hardware design elements directly, but the presence of certain combinations of features and constraints can very strongly suggest that a particular implementation technique is used. As a simple example, if a processor executes an average of approximately one instruction per clock cycle, runs at competitive clock speeds, and has a considerable performance penalty associated with conditional branching, then it's virtually certain that it is using a pipelined design.

[mtippett]

But uhm... at least I couldn't care less about features. All I, as a customer, want is that ISA doc -> Gallium3D converted and state tracker features on top of that.

All problems solved, right?

Correct me if I am wrong though...

Not quite, the ISA is about as useful as x86 assembly. It is critical to execute programs (ISA is used for shaders on the GPU).

Getting the GPU in the state that it can accept a program is the hard part, kind of similar to what the BIOS and Linux kernel and libraries do to allow you to run your x86 program under Linux.

Regards,

Matthew

[mtippett]

Programming specs need not speak about internal hardware design; they just need to document the interface to hardware. So patents can't be a problem, right?

Patents cover SW, HW, process, programming techniques, etc. *lots* of places.