Slashdot Mirror
NVidia releasing OpenGL ICD by End of Year
ttyRazor writes "ga-source.com is reporting that at Comdex they were told by NVidia that they will be releasing an OpenGL ICD for Linux for all their current products by the end of the year. Woohoo! Quake 3 on my TNT in Linux! One less reason to dual boot.
" Mmmm...prettier graphics. I'll give thanks for that.
I'm very pleased to see companies adopt this kind of stance. I'm only buying hardware now from companies that have a positive attitude to linux, and letting companies know this. I'm now strongly tempted to buy an NVidia card to replace my G200.
Please let hardware (& software) companies know that there is money to be made in supporting Linux. I'm very gald to see that Creative Labs have caught on to this. With NVidia, 3DFX & Creative to set good examples, hopefully the rest will follow.
Yellow tigers crouched in jungles in her dark eyes.
She's just dressing, goodbye windows, tired starlings.
It cooperates with the X server.
I was able to make nice screenshots using good old xv on my FreeBSD system. Pulsar shows some fps (K6-300).
The GLX thet the TNT2 and TNT uses only works at 15-bit and 16-bit colour. Any other depth and the reverts back to software.
:-(
... doesn't seem like that would be too hard to do given the code they've released. Granted, I've only read the design docs for DRI, not looked at code. So I don't really know how bad it'll end up being.
Yes. This was in the release notes. 32bit color would be nice, I agree wholeheartedly.
The driver didn't access all the features of the chipset. There was no advantage in having a TNT2 with 32Mb and a TNT with 16Mb. (Unless you had a ridiculously large Workspace with 32-bit colour, but that has nothing to do with the GLX code)
I have a secret for you: no one cares. 32 megs is on that card 'cos they wanted to have a bigger number on there, but there's no excuse for it. The only case in which you would care is if you literally have 32 megs of textures on the screen at once. Otherwise you can page on and off the card very efficiently. Speaking from experience here, about 4 megs of texture memory is more than plenty.
Basically, If you put a TNT-2 next to a comparative Matrox card (G200?) next to a comparative 3Dfx card (Voodoo2?), the TNT-2 would be only marginally better than a S3 Virge.
You obviously haven't played Q3A on a TNT2 in Linux.
Again, speaking from experience, it's not bad. The cost is a weird one, since you're paying for data sent to the card, so it's kind of like having a slower computer. But it's no where near a Virge.
And this is a problem because of current GLX architecture, i.e. we're making the wrong trade-off now -- GL apps work beautifully in a network transparent way (you can display them remotely) but at a big speed hit. DRI will fix that. But all nVidia's got to do is reimplement their driver to use the DRI version of GLX
For that matter, I should really look more closely at the code nVidia released....
Locking is addressed in one of the p.i. papers, can't judge their scheme at present however.
I love to emphasis that FreeBSD was used for rendering The Matrix. But let's face it, in both films mentioned, the free operating systems just delivered raw muscle, not the brains (ie acted as rendering farms).
The higher level modeling and control still seems to be a job for SGIs.
Present stuff gets nice and already is sufficient for certain modelling needs, but we are not state of the art.
I'm using everything straight from CVS, like the FAQ says, and it works great with Quake 3 demo test on my G200. 800x600/vertex, decent frame rate.
Interested in XFMail? New XFMail home page.
use -rMesa_3_2_dev (or something similar, can't remember off hand and I'm at work and my checkout tree is at home). Basicly, get Mesa 3.2.
Bill - aka taniwha
--
Leave others their otherness. -- Aratak
The nvidia specific part has not been touched except for some adjustment to later XFree86 changes regarding the card IDs. But the other stuff (and of course the Matrox specific things) have been improved.
XFree86 will have direct rendering (DRI) and indirect rendering (glx). Here I expect the hardware drivers of the free glx to be integrated and the glx protocol stuff to be replaced by the SGI implementation. But who knows for sure.
Actually, ICD stands for "Installable Client Driver" and is a driver which links itself to Windows' WGL library. Therefore, nVidia isn't actually working on a Linux ICD but a full Linux OpenGL implementation.
Unless, of course, they plan to port WGL to Linux....
Have not read about this on glx-dev or xfree86-dev yet either.
NVIDIA has a history of supporting things before they become "necessary", such as T&L, 32-bit rendering, Stencil Buffer, etc. Linux is yet another thing that hasn't really gone "mainstream" yet, but when it does 1) it will partly be because of developer support like this and 2) NVIDIA will have a much more mature ICD than other devs (*ahem*3dfx*ahem*).
Pablo Nevares, "the freshmaker".
Pablo Nevares, "the freshmaker".
I think I know why Nvidia is doing this and it ain't nothing to do with games or wanting to be nice to the open source community.
Nvidia and SGI are scheming behind the curtains to create NT killer 3d workstations that are Intel Linux based and will have either Quadro's or most likely some kind of multi-pipe (2-4 quadro's) in parallel and custom bus architecture (like the current SGI vis workstations).
Cue a release of Maya for Linux soon (it's done they're just waiting for the linux 3d hardware support to catch up...)
A broad release to the linux community gets their driver's throughly beta tested before the release of their custom boxes probably about march next year.
Unfortunately then I don't think they will opensource the drivers. It will probably be an open source resource manager (basic interface) and binary only glx module for XF86 4.0. If I understand the XF86 4.0 architecture correctly it's possible to have binary only modules that link into the X server and well at least we don't have the problem of kernel modules compiled for wrong kernel versions anymore.
Then once SGI get's a few more features in Linux (Raw i/o, XFS, realtime uncompressed video streaming) look for come seriously cool linux based video editing/compositing systems....
The next year will be interesting....
The consideration that XFree86 4.0 is to be "more modular" will either encourage production of proprietary modules, or downright discourage it, if there need to be some reasonably intimate links between modules. My hope is on discourage.
Hopefully RAM prices will come back down; if XFree86/OpenGL support for some not-too-expensive 32MB cards comes along, I might consider one in the new year some time...
If you're not part of the solution, you're part of the precipitate.
This isn't really new. I've been using it for the last 6 months. There is a team working on accelerated OpenGL (GLX) drivers for a long time. The drivers can be downloaded from "http://glx.on.openprojects.net". However, you must keep in mind that these drivers are still under strong development and still have bugs (alfa/beta). I've been using it with Quake (Q2 and Q3test) and with FlightGear using a RIVA TNT. The drivers work just fine. The supported chipsets are: Matrox G200 and G400 NVidea RIVA 128, RIVA TNT and RIVA TNT2 ATI (Recent cards) You have to download the drivers, and compile it toghether with Mesa3D. TIPS: When you "configure" the compilation flags, you shouldn't forget to select the right chipset: ex: --with-chipset=tnt You will have to compile a new OpenGL DLL "libGL.so.1.0" and a new XFree86 module "glx.so". The DLL must be moved to "/usr/X11R6/lib" and the XFree86 module, should be moved to "/usr/X11R6/lib/modules". At the end, you will also have to configure the new module into your "/etc/X11/XF86Config" file. In case your X server doesn't support loadable modules, then you must upgrade to a new version. In my system, the "glx.so" module compiles OK, but is missing one object file (asm386.o). This way, I allways copy that file from Mesa-3D and append it to "glx.so". fjp
There's a new extension being introduced in XFree86 4.0 which should make video zooming and similar things very easy; it's imaginatively called the X Video Extension.
6 .html
AFAICT, it's still pretty experimental, and I don't know what (if any) hardware is supported, but it sounds very interesting.
http://www.xfree86.org/snapshots/3.9.16/DESIGN1
Tedious Bloggy Stuff - hooray?
What am I missing here?
...
My TNT2 Ultra has worked nicely for some months now (since this summer), thank you very much. There's a fully open source (GPL iirc) driver built around Mesa and SGI's GLX.
What is who talking about? Is nVidia talking about a DRI-compliant driver for use with XFree86 4? I would hope they plan to provide one, but if Precision Insight's assorted whitepapers on the subject are on target, porting to DRI shouldn't be that hard
Comments from someone with some level of clue? Is nVidia just re-releasing old news to have something to say at Comdex?
You are right, the buzzword to watch for in case of X is DRI.
See this diagramm for what to expect. (There is also a less detailed and a poster sized version in the parent directory).
It hasn't hurt Matrox, that they released nice specs so that a lot of people, including John Carmack got interested to hack a driver.
I am not completely sure what is going on in their minds.
They seem to want to harvest the free developer resources from the net at one hand, but on the other hand seem to fear to give away too much secrets to their competition by opening up completely (it is an incredibly competetive market after all).
It is also possible that they don't supply register level stuff, because they fear us to produce crappy drivers, hurting the brand name.
The material released so far and updated this month is something more high level, that also provides uniform access along several NV chip generations. Could be the reason why the traditional hardware freaks did not pick it up so far.