Posted by
Hemos
on from the more-support-coming dept.
skroz writes "At Linux world today, 3dfx announced plans to bring their direct rendering infrastructure to its Linux drivers. Their hope is to broaden high-end graphics support in Linux. Check out the story here. "
For those who didn't know, nVidia has already released an OS-neutral driver suite for the RIVA 128, TNT, and TNT2 series of chips. Fully compilable source for the entire suite is provided under a BSD-ish license. (The source isn't very educational, however, as it's been run through 'cpp'.) Sample driver implementations and example code for Linux and Windoze-NT also accompany the distribution.
The suite is designed to function as low-level support for all rendering and display functions. These functions are exposed in an object-oriented-like fashion at a hardware level. Whatever the hardware doesn't support directly is thunked over to software. Thus, the public API for the NVidia chips is the hardware channels.
This has been out for several weeks now, but every time I've submitted it to Slashdot, it hasn't been approved. Oh, well...
Do we _have_ to use X for everything?
by
MenTaLguY
·
· Score: 2
Well, this is unquestionably a Good Thing(tm), but it really would be nice if it were possible to do 3d graphics decently _without_ X, too. (none of this beating directly on the hardware in each individual app stuff)
While you unquestionably need some central facility to arbitrate access to and abstract the graphics hardware (which is why svgalib doesn't realy cut it -- each app banging on the hardware directly is NOT a modern or a safe way of operating), it'd be nice if you didn't have to pay for the memory overhead of X if you didn't really need it (and it is considerable). Or the startup time -- not all of us keep an X server running continuously.
It'd be nice to see the kernel doing its job with arbitrating access to hardware, although that usually means an in-kernel abstraction layer too, which we really don't want. Partly because it can be a severe cause of bloat, and partly because there's no real obvious way to abstract most graphics stuff without breaking the standard Unix 'everything-is-a-file' metaphor. Except maybe for abstracting really basic stuff, like the framebuffer, which is what fbcon does.
We do still need to arbitrate access to accelerated graphics though, especially in light of the existence of poorly-designed hardware where you can inadvertantly (or deliberately) lock the bus and other fun things by poking accel registers. Maybe KGI will mature someday; the design seems to manage that pretty well without foisting an ungainly abstraction layer on the kernel.
*sigh*
Or maybe I'm just blowing smoke. I dunno. I'm not faulting the 3dfx folks. There are a lot of times you want or need 3d in X, and DRI is the cleanest way to do that. It's also the only emerging "standard" way we have of doing this 3d stuff cleanly right now, in any environment.
The problem is that your X server isn't using your graphics chipset's hardware acceleration capabilities. XFree86 4.0 will address some of this, and I'm sure the dot releases following will bring some pretty good performance gains. I'd settle for my TNT delivering 90% of the performance I get with the same card in one of my other machines that runs Win 95.
I was getting half-way decent on Q2 DM on that Winnders box, but I got sick of the constant crashes (not to mention the fact that I wasn't getting any work done). With hw accel. on Linux, I could go back to being a total slacker and rule my favorite DM server!
3Dfx makes junky proprietary graphics cards that until recently were faster than everybody else's junky proprietary graphics cards. Now nVidia's Riva TNT2 is faster, and has free (BSD license, but hard to read source) drivers, there's little place left for 3Dfx in my world.
I use it all the time at work. My main project involves coding something on an SGI Octane using a library which we only have licensed for the Octane. My workstation is an O2. So, I remotely display the program from the Octane onto the O2, and it works great. Of course, it runs much fasbter when/if I runt it locally on the Octane, but since the Octane sits on my manager's desk and not mine, that's a bit difficult.
Ennyhoo. The reason the TNT driver currently only does GLX is because GLX is just so much simpler to implement and keep synchronized. That's what the DRI is all about. And anyway, q3test runs adequately on my TNT even through the GLX-only driver, as long as I turn off lightmaps (admittedly, GLX really sucks when it comes to texture thrashing, and it doesn't help that the GLX driver has no AGP support yet). --- "'Is not a quine' is not a quine" is a quine.
-- "'Is not a quine' is not a quine" is a quine. Quine "quine?
Slashdot Mirror
For those who didn't know, nVidia has already released an OS-neutral driver suite for the RIVA 128, TNT, and TNT2 series of chips. Fully compilable source for the entire suite is provided under a BSD-ish license. (The source isn't very educational, however, as it's been run through 'cpp'.) Sample driver implementations and example code for Linux and Windoze-NT also accompany the distribution.
The suite is designed to function as low-level support for all rendering and display functions. These functions are exposed in an object-oriented-like fashion at a hardware level. Whatever the hardware doesn't support directly is thunked over to software. Thus, the public API for the NVidia chips is the hardware channels.
This has been out for several weeks now, but every time I've submitted it to Slashdot, it hasn't been approved. Oh, well...
Schwab
Editor, A1-AAA AmeriCaptions
Well, this is unquestionably a Good Thing(tm), but it really would be nice if it were possible to do 3d graphics decently _without_ X, too. (none of this beating directly on the hardware in each individual app stuff)
While you unquestionably need some central facility to arbitrate access to and abstract the graphics hardware (which is why svgalib doesn't realy cut it -- each app banging on the hardware directly is NOT a modern or a safe way of operating), it'd be nice if you didn't have to pay for the memory overhead of X if you didn't really need it (and it is considerable). Or the startup time -- not all of us keep an X server running continuously.
It'd be nice to see the kernel doing its job with arbitrating access to hardware, although that usually means an in-kernel abstraction layer too, which we really don't want. Partly because it can be a severe cause of bloat, and partly because there's no real obvious way to abstract most graphics stuff without breaking the standard Unix 'everything-is-a-file' metaphor. Except maybe for abstracting really basic stuff, like the framebuffer, which is what fbcon does.
We do still need to arbitrate access to accelerated graphics though, especially in light of the existence of poorly-designed hardware where you can inadvertantly (or deliberately) lock the bus and other fun things by poking accel registers. Maybe KGI will mature someday; the design seems to manage that pretty well without foisting an ungainly abstraction layer on the kernel.
*sigh*
Or maybe I'm just blowing smoke. I dunno. I'm not faulting the 3dfx folks. There are a lot of times you want or need 3d in X, and DRI is the cleanest way to do that. It's also the only emerging "standard" way we have of doing this 3d stuff cleanly right now, in any environment.
---
DNA just wants to be free...
The problem is that your X server isn't using your graphics chipset's hardware acceleration capabilities. XFree86 4.0 will address some of this, and I'm sure the dot releases following will bring some pretty good performance gains. I'd settle for my TNT delivering 90% of the performance I get with the same card in one of my other machines that runs Win 95.
I was getting half-way decent on Q2 DM on that Winnders box, but I got sick of the constant crashes (not to mention the fact that I wasn't getting any work done). With hw accel. on Linux, I could go back to being a total slacker and rule my favorite DM server!
slashdot broke my sig
3Dfx makes junky proprietary graphics cards that until recently were faster than everybody else's junky proprietary graphics cards. Now nVidia's Riva TNT2 is faster, and has free (BSD license, but hard to read source) drivers, there's little place left for 3Dfx in my world.
----
----
Open mind, insert foot.
I use it all the time at work. My main project involves coding something on an SGI Octane using a library which we only have licensed for the Octane. My workstation is an O2. So, I remotely display the program from the Octane onto the O2, and it works great. Of course, it runs much fasbter when/if I runt it locally on the Octane, but since the Octane sits on my manager's desk and not mine, that's a bit difficult.
Ennyhoo. The reason the TNT driver currently only does GLX is because GLX is just so much simpler to implement and keep synchronized. That's what the DRI is all about. And anyway, q3test runs adequately on my TNT even through the GLX-only driver, as long as I turn off lightmaps (admittedly, GLX really sucks when it comes to texture thrashing, and it doesn't help that the GLX driver has no AGP support yet).
---
"'Is not a quine' is not a quine" is a quine.
"'Is not a quine' is not a quine" is a quine.
Quine "quine?