NVIDIA's Andy Ritger On Linux Drivers

tykev writes "The Director of Unix Software at NVIDIA talks about Linux drivers, planned features, development cycle, and the open source Nouveau driver. (The interview is in English but all the comments are in Czech.) Quoting: 'NVIDIA's stance is to neither help nor hinder Nouveau. We are committed to supporting Linux through a) an open source 2d "nv" X driver which NVIDIA engineers actively maintain and improve, and b) our fully featured proprietary Linux driver which leverages common code with the other platforms that NVIDIA supports.'"

Comments

Re:NDAs and Patents Suck Life.

[mikael]

What you say is confusing and has the smell of a well crafted lie. Can you set me straight so I can understand why Nvidia is unable to do like Intel and fully co-operate with the free software community?

Have a look at NVidia's OpenGL specifications web-page

Every extensions comes with an IP Status field. For example ARB_color_buffer_float has the following:

IP Status

        SGI owns US Patent #6,650,327, issued November 18, 2003. SGI
        believes this patent contains necessary IP for graphics systems
        implementing floating point (FP) rasterization and FP framebuffer
        capabilities.

        SGI will not grant the ARB royalty-free use of this IP for use in
        OpenGL, but will discuss licensing on RAND terms, on an individual
        basis with companies wishing to use this IP in the context of
        conformant OpenGL implementations. SGI does not plan to make any
        special exemption for open source implementations.

        Contact Doug Crisman at SGI Legal for the complete IP disclosure.

Re:Nouveau

[MoxFulder]

There is no way that an open-source GPU driver can ever achieve same quality (in terms of performance and compatibility at a given timeframe) as an actively developed proprietary driver. GPUs are very complex devices, and drivers make a huge difference on performance. In order to make a fast driver you really need to know how the target GPU works on a very low level.

This is the same tired, fallacious argument NVidia has been trotting out for years: "Developing GPU drivers is much too complex. Why don't you Linux kids go run along and play with your toys, and let us write the GPU drivers?"

Well, it's just wrong. I have used many reverse-engineered drivers for complex pieces of hardware, and nearly all of them work as well as or better than the original vendor's drivers. Most recently, I had the pleasure of trying out the Broadcom 43xx wireless driver, which was painstakingly reverse engineered in the face of an INCREDIBLY recalcitrant vendor that won't release a shred of documentation on their devices to open source developers, even under NDA! And, surprise, the card works better under Linux with the reverse-engineered driver than it does with the Windows driver, which seems to lose the signal quite often. The bcm43xx developer Michael Buesch has even got some evidence that certain parts of their code are implemented more efficiently and elegantly than the original driver.

Naturally, NVidia will not disclose this low level stuff about their GPUs to outsiders.

Why is this "natural"? Intel releases documentation on the low level stuff about their GPUs, Realtek goes out of its way to help the Linux community with Ethernet and wireless IC documentation, and Linksys has released the complete code for its Linux-based routers. If a business is based on continual innovation--rather than maintaining an entrenched monopoly--it is entirely possible to be successful and open at the same time.

You can compare GPU drivers to compilers. There is no way that open-source compiler (GCC) will ever produce as good code for new Intel's CPUs as Intel's own compiler (ICC) as long as ICC is actively developed.

Again, this is only true if Intel holds back some of the documentation necessary to make a good compiler. If they publish complete instruction set information, with accurate timing, cache, and pipeline data (which they have done, for the most part), then making a better compiler is "merely" a question of developer resources and talent.

I suspect that, to the extent that GCC code doesn't run quite as fast as ICC, it's because GCC has higher priorities for its code base, especially ensuring support for an incredible breadth of platforms. GCC has essentially become the reference compiler for a lot of embedded development in particular. Even companies like Broadcom that won't lift a finger to help open source out rely on GCC to build the firmware for their own devices.