OpenGL = IP mindfield, Intel is problem #1, vendors need to adhere to LSB -- WAS: Kernel source

[Bryan J. Smith]

Tamal Kanti Nath <tamal.nath at gmail.com> wrote:
> Possibly, I had started the thread.

Well, regardless who started the thread, I sure know how to finish it
off.  Sorry I get heated sometimes.

nVidia has always done its best to keep up the GPL drivers for the
nForce -- from ALSA to NIC to USB.

Understand nVidia, unlike Intel, isn't a 800lbs. gorilla.  They can't
force all Tawainese companies to use only their approved PHY or sick
lawyers or make their market life a "living hell" on invalid
configurations.  nVidia tries to track all those configurations, and
get them into the forcedeth _immediately_ when they know about them. 
But people don't always have the latest kernel with it -- whereas you
can download the nVidia package and install it on _any_ kernel.

In fact, "integrator choice" is currently the #1 problem with AMD
Turion64 on Linux.  AMD doesn't sell the whole stack, but lets
vendors add value.  Intel Centrino is a P3 CPU, i8xx+ICH series
chipset, MAC+PHY WLAN, etc... all-in-one.  Intel can do that because
it has dollars.  AMD doesn't.

> I had made a wrong assumption about nVidia.

It's okay.  You aren't rabid like some people.  Sorry I sacked you
with my 'tude because I just try to help people sometimes and my
words just get raped on-line by 3-4 people.  Then the tangent is way
off -- and I stupidly try to explain things.

> I am using the generic driver as I was unsuccessful to run
> the  driver.

> But thanks to Bryan J. Smith for the information about nVidia.

nVidia gets bashed for a lot of things that aren't their fault.

They *DID* release the NV0x (TNT2/GeForce[1]) source code with _full_
GLX 3D acceleration back in the XFree86 3.3.x days.  And Intel,
Microsoft and many other lawyers sent "cease'n desist" letters.  That
source code release was then used for the open source nVidia UtahGLX
drivers that did work through some of the NV1x (GeForce2/4MX) models,
but none of the NV2x+ (GeForce3/4Ti) on-ward.

Some of the kernel-memory code is IP of Intel.  In fact, nVidia's
Linux AGPgart became _GPL_ and went into the stock kernel the second
Intel stopped enforcing their IP on it.  The nVidia AGPgart is
_much_more_stable_ than other chipsets.

That's the _only_ part that has to be GPL -- that kernel-memory
interface module.  XFree/Xorg allows binary modules for all the GLX
functions, and the nVidia license on their libGL allows dynamic
linking.

I think it's time the community gets off the rabid anti-proprietary
and realize:  

A.  OpenGL/GLX _is_ an "open standard" with board committee
B.  There needs to be a _standard_ mechanism for kernel-memory
control
C.  There needs to be a _standard_ mechanism for "alternative" libGL

With regards to "A," yes, it's not "open source."  But it is *NOT*
"proprietary standard."  In fact, because OpenGL is an IP minefield,
by letting the OpenGL library/driver be "closed source" from
companies that have IP arrangements with Intel, Microsoft, SGI and
others, we _avoid_ sacking the community with countless IP
litigation.

The _only_ way to avoid that is to come up with an _alternative_ to
OpenGL.  And even then, some OpenGL technology patents _will_
overlap.

Now "B" is clearly on _Intel_ for the most part.  It affects _both_
ATI and nVidia.  Hell, if we didn't use PC compatible, "clusterfsck"
interfaces that make a peripheral bus look like a CPU -- and adopted
a _real_ system interconnect like AMD HyperTransport with _real_ I/O
MMU in the CPU itself (with the GPU as a _peer_ processor on the
_same_ interconnect) -- we would *NOT* have to play stupid games like
Intel does with kernel-memory-peripheral mapping.

But AMD doesn't have the R&D dollars to influence other companies
like Intel -- so we're stuck with Intel's utter-lack of a _real_
system interconnect, and the "clusterfsck" hacks like the
kernel-memory interface.  And that crap is protected by IP.  As an EE
with a focus on computer architecture, I'm really tired of Intel's
use of a 12 year-old interconnect/CPU making life hell -- AMD figured
this crap out 6 years ago, in a way that _removes_ the need for these
hacks.

Now "C" could be solved by ATI, Matrox and nVidia using the
"alternatives" subsystem.  The Linux Standard Base (LSB) could be a
little less vague on using "alternatives."

> Also thanks to other posters. Can you help me about how to
> configure X (by modifying xorg.conf) ?

Why not use the system-config-* program?


-- 
Bryan J. Smith   Professional, Technical Annoyance
b.j.smith at ieee.org    http://thebs413.blogspot.com
--------------------------------------------------
I'm a Democrat.  No wait, I'm a Republican.  Hmm,
it seems I'm just whatever someone disagrees with.