feedback to NVidia [was: Nvidia Drivers]

[Sean Estabrooks]

On Sun, 6 Jun 2004 23:38:02 -0700
"T. 'Nifty New Hat' Mitchell" <mitch48 at sbcglobal.net> wrote:

> Consider the mmx class of instructions that Intel introduced.
> What "C" code causes these instructions to be generated by gcc.
> 
> See ..../arch/i386/lib/mmx.c where in line assembly is used.  For the
> class of SIMD and other complex instructions that I expect exist in
> the interesting GFX engines other abstractions beyond those addressed
> by MMX are involved.  I have not disassembled all of Linux to check
> but these are rare instructions and I believe that they are all
> generated by hand crafted assembler directives.  If mmx instructions
> are unused by gcc then the interesting GFX engine functions would likely
> be unmapped to "C" code structures as well.
> 
> Yes the 'gnu' compiler and assembler could be modified but these are
> not off the shelf general purpose processors.  There are no flags for
> these engines in the existing gcc code base. Think Xilinx Virtex-II
> Pro, 29K bit slice or perhaps the classic Motorola MC14500B if you
> want to research and think about these GFX processors (MC14500B is key).
> 
> The assembler has to be built for each custom engine, then the code
> generation templates for the 'C' compiler.  Then because the
> abstractions in the 'C' language do not express the transformations
> that are interesting to 3D graphics,  hand coded blocks and or
> special compiler (language) extensions are needed.   There is
> also no standard ABI for these custom engines.
> 
> Not only is there a lack of support for 3D graphics abstractions in
> "C" expect also a complementary lack of support for "C" in these
> special purpose GFX/vector engines.
> 
> One of the problems with complex instruction set processors (GFX
> engines are complex) is that compiler writers often ignore the full
> instruction set because the abstractions of the language do not match.
> Hmm time for me to dust off "Computer Architecture a Quantitative
> Approach", J.L. Hennessy and D. A. Patterson, 2nd Edition, 1996.
> 
> These are not frame buffers with 'common' processors glued to them.
> 

What are you talking about?   Do you know how many open
source 3D drivers there are?   Please check out:

http://dri.sourceforge.net/

When manufacturers make information available, open source drivers
can get written.   The technical hurdles aren't the problem.   Getting the
information is the problem.   The drivers run on the host computer
not on the graphics card, so the current suite of open source compilers/
assemblers handles the job adequately.

> Do not get me wrong I would love it if all these drivers were full
> open source.  But for me this takes second place to the question 
> of vendor support.   
> 
> Vendor support is my requirement!
> 
> Full open source and open hardware documentation would be wonderful.
> 
> In the past I have ranted on a specific scanner given to me by my
> brother.  He upgraded his WindowZ box and the 'old' scanner was not
> supported on the new WindowZ OS (and not on Linux).  This scanner
> vendor will never see a penny from me. Because they fail to support
> their product on anything.  Had they supported my brother in his
> upgrade or opened up the hardware details so I could use it on Linux I
> would not say a cross word.  So, beware of "OneTouch" and any other
> vendor that has a support matrix that looks like Swiss cheese.
> 

Yeah.  Would be nice to get  an honest operator/specifications
manual with all hardware purchases.    As someone once said, 
would you buy a car with the hood welded shut?

   
> Again,
> 
> Do not get me wrong I would love it if all drivers were full open
> source and hardware fully documented!
> 
> Vendor support is my single requirement!
>        drivers please
>        if no drivers then documentation so we can build our own drivers.
>        drivers + documentation -- best of both worlds.

I think people who are committed to Linux should be committed to
supporting the developers who gave them Linux.   Linux needs open
hardware on which to run.   People serious about supporting Linux should
consider carefully how they use their purchasing power.   Supporting the
open source developers seems like the smallest effort we can make to
help the people who gave us Linux.   Obviously there are times when you
have to make an exception, but it seems reasonable to help support open 
source where we can.

> When a vendor gets weary of updating their drivers... publish the
> documentation then move on.  I would love to see hardware vendor
> support matrix tables use three codes: (ds), (dd) or (os).
> Where "ds" indicates data sheet for device driver writers published.
> (dd) device driver binary, and (os) for open source driver.
> I would kindly at vendors that had all three (ds+dd+os).
> 
> Hello sound card and modem vendors..... Three simple options ds, dd, os.
> 

Regards,
Sean