[linux-elitists] [email@example.com: The Tangent that Won't Die: GeForce and binary LKMs -- WAS: Kernel source (and GPL nForce drivers)]
Wed Apr 19 05:13:43 PDT 2006
----- Forwarded message from "Bryan J. Smith" <firstname.lastname@example.org> -----
From: "Bryan J. Smith" <email@example.com>
Date: Mon, 17 Apr 2006 09:52:42 -0700 (PDT)
Subject: The Tangent that Won't Die: GeForce and binary LKMs -- WAS: Kernel
source (and GPL nForce drivers)
Okay, since help on the GPL nForce drivers has turned into an anal
probe of the GPL license and Linux Kernel Modules (LKMs), I guess we
can't avoid it.
Maurice Hilarius <firstname.lastname@example.org> wrote:
> What a funny coincidence:
Yes. If you follow the LKML, you'll see Linus come in and talk about
different modules. Some people have collectively called these
"binary/license module exceptions" and that's a skewed name for it.
But from AFS to Atheros, he has weighed in on several non-GPL LKMs.
Saying "3D acceleration" is like saying "network services." It's a
massively open-ended statement that covers _thousands_ of
technologies and functions. Graphical Processor Units (GPUs) are
_more_complex_ than _any_ CPU these days. You can't just write a
"driver" and it works.
Furthermore, let us not mistake the fact that there are two (2)
_different_ portions to a video driver. There is the kernel-memory
interface into the GPU, and then the actual X11 plus GLX (OpenGL on
X11) driver. The latter _can_ be closed source. Only the former is
an issue with the GPL license of the kernel. IP is the biggest PITA,
and it's _unavoidable_ in the GPU world.
Also, when I hear the word "proprietary," do you mean proprietary
source or standards? OpenGL is an "open standard," with an
Architecture Review Board (ARB) and inter-vendor exchange. Yes, ATI
and nVidia might handle it different in hardware, but for the most
part, OpenGL is OpenGL, and a common interface becomes an ARB
implementation and make it into the next revision.
Here's the deal, there should be a _common_ interface for
kernel-memory interfaces into the GPU. It's in the interest of ATI,
Intel and nVidia to work on this. It would help if Intel would open
up some of its IP, but it won't for whatever reasons (hence why
Intel's Linux driver sucks compared to its Windows). But without
opening up the IP, there _should_ be a standard, flexible interface
that ATI and nVidia should support.
Otherwise you get far worse issues -- like trying to change from the
ATI to nVidia driver or vice-versa. Reminds me of conflicting
Windows printing drivers.
We're the community, and we can provide a solution. The pipe dream
is to get an open source GLX driver. It would _still_infringe_ on
_hundreds_ of OpenGL and other patents. Many of those owned by
you-know-who in Redmond. If anything, ATI and nVidia address that
It's either that, or come up with a replacement for OpenGL
all-together, while reverse engineering the _thousands_ of function
calls into ATI and nVidia hardware. Hardware that
_doubles_in_performance_ every 9-12 months. Yes, you heard that
right, every 9-12 months! 2x Moore's Law for CPUs.
In the time CPUs gain 4x performance, GPUs gain 16x.
P.S. Miquel deIcaza's comment about NT 4 drivers working on XP (NT
5.1) was _not_accurate_ with regards to the video driver. In fact,
the video driver is one driver for Windows that _always_changes_ with
every NT revision. Yes, a NT 4 printer driver might work on NT 5.x
(2000/XP), but a video driver for NT 4 does _not_. In fact, one of
the few drivers from NT 5.0 (2000) that will not work on NT 5.1 (XP)
is the video driver -- Microsoft made changes.
Why? Because the kernel-memory interface is very complex, and sacked
by a lot of IP. And that's just one _small_ portion of the overall
driver for "3D Acceleration." ;->
Bryan J. Smith Professional, Technical Annoyance
I'm a Democrat. No wait, I'm a Republican. Hmm,
it seems I'm just whatever someone disagrees with.
amd64-list mailing list
----- End forwarded message -----
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
ICBM: 48.07100, 11.36820 http://www.ativel.com
8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 191 bytes
Desc: Digital signature
Url : http://allium.zgp.org/pipermail/linux-elitists/attachments/20060419/b6829d04/attachment.pgp
More information about the linux-elitists