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. "

Comments

OSS Radeon Drivers.

[reaper20]

Thanks guys, we all know we can't rely on ATI for decent drivers - for anything. Heh.

Re:Is either one that bad for you?

[cduffy]

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?

Re:Here is to wishing.. (amen!)

[PotatoHead]

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.

Re:Will graphics be getting closer kernel ties?

[be-fan]

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.