Moving to hackers@, where most discussions regarding the NVIDIA drivers
seem to take place lately. 

Chris BeHanna wrote:

>     I don't remember if it was this list on which I saw this
> discussion, or if it was hackers.  Anyway, I looked at xfree86.org
> today, and noticed that there is accelerated support for ATI Mach64
> and for NVIDIA TNT2 and GeForce256 boards, as well as many others.
>
>     Is there some reason why this isn't "good enough," or do we
> really need actual drivers for these boards to get at their
> extra-nifty features (e.g., hardware backface culling, fog, bump maps,
> etc.)?

        The NVIDIA drivers for XFree86 are the result of a collaborative effort
between NVIDIA, SGI and VA Linux. Concentration, as far as I know, has
been focused on OpenGL development in the new DRI environment XFree86
4.0 provides.

        You could speculate that with fairly high calibre companies partaking
in such an effort - where there's obviously a fair amount of financial
investment - their drivers are going to perform better than those
provided with XFree86.

        For those interested, it is the code of the accelerated OpenGL
driver/libraries that NVIDIA are distributing as Linux binaries (i.e.
closed-source). The only source that *is* provided is for the cards'
kernel device driver. 

        I remember reading somewhere on NVIDIA's site that the only reason
they're providing *this* code is because Linux's kernel module loading
mechanism prevents the introduction of foreign pre-compiled binary
objects as system device drivers. So, effectively, a kernel device
driver has to be compiled on the system natively before it can be used
(?).

        It was something along those lines, anyway.

        Someone should tell NVIDIA there's a lot more to "Open Source" than
just writing closed-source drivers for Linux.

        On a more technical note, given an accurate port of the kernel device
driver (which would be trivial at best), is there any reason these Linux
OpenGL drivers & associated libraries can't just be branded as 'Linux'
object types and handled as-per-normal by linux.ko? After all, it's the
kernel driver's responsibility to manage all the Operating System's
specific hardware resource management etc.

        I'm doubting it's that easy, though.

> Chris BeHanna
> Software Engineer (at yourfit.com)
        
        Regards,

                Trent.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Reply via email to