OpenGL = IP mindfield, Intel is problem #1, vendors need to adhere to LSB -- WAS: Kernel source | |
| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] | |
Tamal Kanti Nath <tamal.nath@xxxxxxxxx> 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@xxxxxxxx http://thebs413.blogspot.com -------------------------------------------------- I'm a Democrat. No wait, I'm a Republican. Hmm, it seems I'm just whatever someone disagrees with. -- amd64-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/amd64-list
[Search] [Home] [Kernel List] [Linux ia64] [Linux X86_64] [Red Hat Install] [Red Hat Migration] [Red Hat Development] [Red Hat 9 Bible] [Red Hat 9 Mailing List] [Fedora Legacy] [Yosemite News]