hmm.. perhaps I should have included this info from Terence's page (http://reality.sgi.com/ripperda_engr/glx/): I'd like to send a hearty congratulations and thank you to Dave Schmenk at NVIDIA for his hard work. I don't think people realize how long he's worked for this, or how he had already helped the linux cause. The G200 driver descended from his templates and work on the TNT driver.
Sure, Nvidia released "already-written GPLed drivers", but a) they aren't fully finished, b) they didn't send the specs along with the drivers, and c) the Nvidia drivers were based on... the same GLX source base as the G200 drivers. Surprise.
I think it is more correct to say that the G200 driver is based on the same source tree as the nVidia driver. David Schmenk at nVidia is responsible for the hardware procedure hooks in the GLX source tree. (Which btw shows that nVidia started this long before the Riva Enlightenment petition started)
btw, nVidia's driver aren't GPLed. They are under a XFree86 compatible copyright.
If you happen to have a matrox card, you can use matroxfb to wake up a secondary matrox card. I'm doing so right now.. You should use Gerd's fbdev patches as well since the normal mga driver assumes that the matrox card is the primary card. I needed to remove the vt switching code from the other server as well, but that was pretty straight forward.. and I'm using x2x to move the pointer between the screens.
Hope that made any sense... anyway you could just wait for XFree86 4.0 which is going to have multihead support. Or you could buy a commercial X server with multihead support.
According to the following URL, the TNT has a hardwired register based setup engine: http://lists.openprojects.net/pipermail/g200-dev /1999-June/001223.html
You can also look at servGL/hwglx/nv/riva_prim.c Much less to do than in mga_tritemp.h as far as I can see.
The WARP specs probably contains a lot of information about the G200 architecture. This is microcode we are talking about, not some high level language. A competitor trying to reverse engineer their chipset would be at a distinct advantage I guess. But, as Stephen wrote, Matrox has stated that they are going to help us with the WARP. Look at the following URL for the original mail from matrox developer relations: http://lists.openprojects.net/pipermail/g200-dev /1999-June/001323.html
Well, you've said this earlier, and I've answered this earlier as well, but since this message was moderated up... http://lists.openprojects.net/pipermail/g200-dev/1 999-June/001323.html
But the current bottleneck in the G200 driver is not the lack of documentation about the WARP microcode, rather the lack of direct rendering.
Matrox has stated that they are going to help us with the WARP engine. Take a look at the following URL: http://lists.openprojects.net/pipermail/g200-dev/1 999-June/001323.html besides, using the WARP engine will not be really helpful until we are using a direct rendering approach.
Since the company already disclaimed all responsibility for the program they can't be held responsible when Joe Random Scriptkiddie deinstalls all copies of the mission critical application Foobar across an entire corporation...
It is an essay on shrinkwrap licenses by Leo L Schwab.
There was also pretty good page with information about the legality of reverse engineering at www.fravia.org, but that site seems to be gone once again:( (Does anyone know of another such page anywhere?)
Exactly.. and for an absurd example: Would it be illegal if I figured out that I could get a dos shell directly if I added a BootGUI=0 to my msdos.sys? (Assuming that it isn't mentioned in the documentation somewhere)
I also like to have at least an illusion of being able to figure out how my graphics card works...
I really hope this proposal is soundly rejected. (Not that I as a native of Sweden would have any direct problem with this law, but you never know...)
The one thing that I really object to in this law is the clause against reverse engineering. I like to have the option of trying to figure out how things work... (even though I'm not good at it.) I think the code for accessing ZIP drives under Linux was originally written by reverse engineering. Comments in the source code indicates that the Matrox Millenium driver in XFree86 was originally written by something akin to reverse engineering.
The other clauses will probably hurt the software vendors once people start to grasp the trap. There is after all lots of free software out there.
Do you think every manufacturer will write rock solid authentication code to prevent non authorized people from deinstalling their software? I don't.
On the other hand, if we allow laws like this there could eventually be even worse laws around the corner... Imagine people selling a PC to you, and you are not allowed to install anything on it unless you pay a fee to the manufacturer, or something equally absurd.
You don't have to submit internal changes to GPL programs.
The GLX driver is developed under a XFree86 compatible license as well... (This is because it needs to be compatible with the license that is appropriate for Precision Insight's direct rendering architecture)
So, you are saying that the kids won't learn anything by writing the Operating system and the applications themselves?:)
ehm... seriously though, it is a very valid point, but in a couple of years or so there will be free software available that is suitable for use by computer illiterate I guess..
If Linux doesn't run well overclocked chances are that other applications will suffer as well. Anyway, I've heard that it is much more difficult to overclock a PPGA Celeron in a S370-S1 converter than a PPGA Celeron in a pure S370 configuration.
/AE
Re:Wasn't SMP support already suggested for Q3?
on
Quake3 to go SMP
·
· Score: 1
Carmack did experiment with it some time ago, but by then he didn't get any speed up... search for an older entry in his plan. (It was last year some time...)
Slashdot Mirror
There is a beta driver for Permedia2 based cards.. more information at http://www.suse.de/~sim/mlx.html
Also, Precision Insight is using 3dlabs hardware for their sample implementation. They demoed it on a 3DLabs GMX 2000 at Linux Expo.
hmm.. perhaps I should have included this info from Terence's page (http://reality.sgi.com/ripperda_engr/glx/):
I'd like to send a hearty congratulations and thank you to Dave Schmenk at NVIDIA for his hard work. I don't think people realize how long he's worked for this, or how he had already helped the linux cause. The G200 driver descended from his templates and work on the TNT driver.
Original GLX module.
Thomas Götz adds support for Matrox Millenium chipsets to the GLX module
David Schmenk adds hooks to the GLX module to simplify hardware acceleration.
Wittawat Yamwong adds support for G200 to the GLX module.
The nVidia driver is released to the public
Future: Integration with Precision Insight's DRI. (This will use the GLX implementation from SGI).
Sure, Nvidia released "already-written GPLed drivers", but a) they aren't fully finished, b) they didn't send the specs along with the drivers, and c) the Nvidia drivers were based on ... the same GLX source base as the G200 drivers. Surprise.
I think it is more correct to say that the G200 driver is based on the same source tree as the nVidia driver. David Schmenk at nVidia is responsible for the hardware procedure hooks in the GLX source tree. (Which btw shows that nVidia started this long before the Riva Enlightenment petition started)
btw, nVidia's driver aren't GPLed. They are under a XFree86 compatible copyright.
/Andreas
If you happen to have a matrox card, you can use matroxfb to wake up a secondary matrox card. I'm doing so right now.. You should use Gerd's fbdev patches as well since the normal mga driver assumes that the matrox card is the primary card.
I needed to remove the vt switching code from the other server as well, but that was pretty straight forward.. and I'm using x2x to move the pointer between the screens.
Hope that made any sense... anyway you could just wait for XFree86 4.0 which is going to have multihead support. Or you could buy a commercial X server with multihead support.
/Andreas Ehliar
According to the following URL, the TNT has a hardwired register based setup engine:v /1999-June/001223.html
http://lists.openprojects.net/pipermail/g200-de
You can also look at servGL/hwglx/nv/riva_prim.c
Much less to do than in mga_tritemp.h as far as I can see.
/Andreas
The WARP specs probably contains a lot of information about the G200 architecture. This is microcode we are talking about, not some high level language. A competitor trying to reverse engineer their chipset would be at a distinct advantage I guess.v /1999-June/001323.html
But, as Stephen wrote, Matrox has stated that they are going to help us with the WARP.
Look at the following URL for the original mail from matrox developer relations:
http://lists.openprojects.net/pipermail/g200-de
/Andreas
My take on this is that Matrox hardware people are very good, but matrox software people are still learning how to make fast OpenGL drivers.
/Andreas
Well, you've said this earlier, and I've answered this earlier as well, but since this message was moderated up... http://lists.openprojects.net/pipermail/g200-dev/1 999-June/001323.html
But the current bottleneck in the G200 driver is not the lack of documentation about the WARP microcode, rather the lack of direct rendering.
/Andreas
Matrox has stated that they are going to help us with the WARP engine. Take a look at the following URL: http://lists.openprojects.net/pipermail/g200-dev/1 999-June/001323.html
besides, using the WARP engine will not be really helpful until we are using a direct rendering approach.
/Andreas
What? The 3d portion of the NVidia drivers is checked into the same source tree as the driver for G200.
(Found this one on bluesnews). html
http://biz.yahoo.com/prnews/990611/ca_3dfx_fi_1
/Andreas
Transmeta mayhap?
But would that be an offer he couldn't refuse?
nope.. they stated in their shrinkwrap license that they are not responsible for their software...
Since the company already disclaimed all responsibility for the program they can't be held responsible when Joe Random Scriptkiddie deinstalls all copies of the mission critical application Foobar across an entire corporation...
/Andreas
http://www.microtimes.com/157/shrinkwrap.html
:( (Does anyone know of another such page anywhere?)
It is an essay on shrinkwrap licenses by Leo L Schwab.
There was also pretty good page with information about the legality of reverse engineering at www.fravia.org, but that site seems to be gone once again
/Andreas
Exactly.. and for an absurd example:
Would it be illegal if I figured out that I could get a dos shell directly if I added a BootGUI=0 to my msdos.sys? (Assuming that it isn't mentioned in the documentation somewhere)
I also like to have at least an illusion of being able to figure out how my graphics card works...
I really hope this proposal is soundly rejected. (Not that I as a native of Sweden would have any direct problem with this law, but you never know...)
/Andreas
The one thing that I really object to in this law is the clause against reverse engineering. I like to have the option of trying to figure out how things work... (even though I'm not good at it.)
I think the code for accessing ZIP drives under Linux was originally written by reverse engineering.
Comments in the source code indicates that the Matrox Millenium driver in XFree86 was originally written by something akin to reverse engineering.
The other clauses will probably hurt the software vendors once people start to grasp the trap. There is after all lots of free software out there.
Do you think every manufacturer will write rock solid authentication code to prevent non authorized people from deinstalling their software? I don't.
On the other hand, if we allow laws like this there could eventually be even worse laws around the corner... Imagine people selling a PC to you, and you are not allowed to install anything on it unless you pay a fee to the manufacturer, or something equally absurd.
/Andreas
But the point you are making about Open Source drivers is still valid...
You don't have to submit internal changes to GPL programs.
The GLX driver is developed under a XFree86 compatible license as well... (This is because it needs to be compatible with the license that is appropriate for Precision Insight's direct rendering architecture)
But he have submitted some changes even so.
So, you are saying that the kids won't learn anything by writing the Operating system and the applications themselves? :)
ehm... seriously though, it is a very valid point, but in a couple of years or so there will be free software available that is suitable for use by computer illiterate I guess..
You can get about two PII@400 for the price of one PIII@500...
The mother board is a bit more expensive of course, but you get my point...
/AE
If Linux doesn't run well overclocked chances are that other applications will suffer as well. Anyway, I've heard that it is much more difficult to overclock a PPGA Celeron in a S370-S1 converter than a PPGA Celeron in a pure S370 configuration.
/AE
Carmack did experiment with it some time ago, but by then he didn't get any speed up... search for an older entry in his plan. (It was last year some time...)
/AE
Probably not... SGI are after all playing in a market there the software in some cases are more expensive than the hardware they run on...