Slashdot Mirror
Better Looking Linux: Tungsten Graphics
Several folks have e-mailed about the formation of Tungsten Graphics, which is composed of quite a number of ex-Precision Insighters. Linuxgames is carrying a bit of a conversation with Frank LaMonica, the CEO of the new company. They've got a contract with Red Hat already in place. Frank's statement summarizes what they are doing well: "The work we are doing involves Mesa ? and XFree86, including both 2D and 3D multi-screen technology, and we are working very closely with the OpenGL ? ARB to maintain the integrity of the OpenGL API. We believe that OpenGL 2.0 needs more industry support, so we are working to help generate that support. DRI ? technology is still in its infancy, and TG plans to help bring it to full fruition. Our first step in that goal is to significantly improve the existing open source DRI driver for the Radeon chipset. That driver is tentatively scheduled for release in late spring or early summer of 2002. "
Thanks guys, we all know we can't rely on ATI for decent drivers - for anything. Heh.
why would someone buy a nice card and then waste it's features in linux? It's not like you can play any games properly in it!
Beg pardon -- playing Tribes 2 at 1600x1200 with a perceptibly perfect framerate is somehow improper?
OpenGL is not just about games, though I play them along with everyone else :)
Mcad, Scientific Vis. , Simulation are some applications that depend on OpenGL right now. There is a *lot* of pressure to move some of these to the win32 graphics API to gain the economics of scale that surround the Intel platform.
In the MCAD area, OpenGL is widely used because the big players are still cross platform. Over the last few years, there has been little real Linux interest, and little UNIX interest. Almost every one starting new with MCAD was starting on win32.
This year has been different. People are asking about MCAD on Linux and UNIX. Seems that some of the backlash we all have postulated about here is beginning to happen. (about goddam time!)
One interesting approach has been to put in win32 MCAD because it is cheaper than UNIX, maybe use a UNIX backend and hope to migrate to Linux when things come together in the near future. Hearing this stuff is huge and indicates to me that Tungsten is in the right place at the right time.
Good quality X servers can at least take advantage of back-end UNIX compute servers. Enough people do this and realize the administrative and support advantages and Linux native ports will follow.
So here's to hoping for next year. OpenOffice will continue to get capable, Linux graphics will get strong and compare more favorably to highend implementations like IRIX, and some ancillary applications will appear to make technical computing on Linux a reality outside the developer and adademic communities.
Blogging because I can...
FWIW, both the 3Dfx and ATI OpenGL Windows drivers were in user space in Windows. The way it works there is that the driver asks the 2D display driver for a memory buffer, the driver fills the memory buffer in with commands, most of which have the form "draw a triangle", and then the driver submits the buffer of commands to the hardware through a kernel interface. This is the way the ATI Rage128 drivers worked, and the 3Dfx V3 and V5 drivers worked. In fact, for OpenGL, you could use the Visual C++ debugger to debug the driver. DirectX is under the Win32 mutex, so debugging it is a big PITA, and required SoftICE.
My guess would be that they are exactly the same now. The problem with Linux performance is not that the driver is in user space, but that the driver, Mesa, is not very efficient.
Actually, BeOS splits up the video drivers. The low level work that *has* to be done in the kernel (like handling interrupts) is done in kernel space. The high level work (everything else, including drawing) is done by the X server (from userspace) directly manipulating the registers on the card. This is actually faster than putting the driver in the kernel because you don't have to make a slow system call to do drawing. The major bottleneck in the system is that you have to communicate between the X server and the application.
Ideally, processors would implement protection mechanisms similar to the x86 segmentation method. That method let you define 4 protection rings, and allowed code to access certain segments based on the privelege level of the segment containing the code. That way, everything could be done in the application. The app code would have a privlege level of 3, so it couldn't trash kernel or windowing system data. The window system would have a privelege level of 1 or 2, so it could access its data and the applications, but couldn't trash kernel data. The kernel would have a privelege of 0, so it could access anything and be safe from other code. Using such a mechanism, it would be possible to make everything (including windowing operations and system calls) require no more time than a simple function call.
A deep unwavering belief is a sure sign you're missing something...
The NVIDIA stability problems are old news. Yes, for the first 6 months they were available, they had some stability issues. Just because they stated in their README that they were having stability issues on multiprocessor boxes 18 months ago does not mean the stability issues exist today.
I only use dual processor boxes. I have a dual processor box at home, and we've got 11 dual processor Linux boxes at work. All use NVIDIA hardware, and all of them are very, very stable. Our lab does flight simulators and scientific visualization, so the machines get heavy 3D use on a daily basis. I havn't had any NVIDIA Linux box lock up in about a year.
Most of the people I've talked to who are having stability problems with the NVIDIA cards under Linux have either a cheap motherboard or an inadequate power supply. No driver in the world can compensate for either of these.
"Good people drink good beer"