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

Graphics expertise and their website

[awgy]

Its not that their website doesn't serve its purpose, but the Tungsten Graphics site doesn't quite instill any security in my mind of their graphics experience. Granted, hardware and DRI-related issues generally don't require good graphical design, but someone should at least offer them a logo.

Isn't the abbreviation wrong?

[kawlyn]

On the web page it's TG, but shouldn't it be WG?

Will graphics be getting closer kernel ties?

[Flarners]

I've gotten the impression that the reason many cards (including my Matrox G400) underperform in Linux compared to Windows is due to the fact that the majority of the 3D talk is done in userspace, outside of the kernel. NVidia has chosen to completely bypass DRI and throw their entire driver into the kernel, which produces equal or better performance in Linux compared to Windows, at the expense of numerous stability problems (especially on multiprocessor boxes).

So, what I'd like to know is, is there a happy medium between userspace code in the X server and driver code in the kernel than can provide adequate performance without sacrificing stability? Right now, Linux 3D support is at either one end of the spectrum or the other: Stable yet slow DRI, or unstable yet blazingly fast kernel drivers. I would love to dump Windows for all my Unreal Tournament and Tribes 2 gaming needs, and am a loyal Loki customer, but I hate having to put up with either regular crashes or a large drop in performance. Hopefully, these Tungsten folk will find the best compromise.

Re:Will graphics be getting closer kernel ties?

[BlueGecko]

IIRC, BeOS's video drivers were in user space, and seeing as that was a media OS, I'm assuming that there's some merit to keeping such drivers out of the kernel. The trick more likely has to do with the fact that Linux lacks real-time scheduling and the extremely low-cost context switches that were absolutely essential on an OS so pervasively threaded as Be, so I honestly do not know if such a solution would be practical in Linux without a major rewrite of the scheduler, etc.

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.

Not very supportive of Open source

[A Commentor]

We believe that some code MUST be open source, other code can go either way, and some, especially at the lowest levels of hardware and the code within applications, can be completely closed with no loss of benefit to the industry or its customers.

Didn't we have to face this problem before with some of the video card (S3?) manufactures that refused to give out programming information... Code to control hardware should be open just like any of the other code.

Re:Not very supportive of Open source

[MrHat]

Nice find - they have this completely reversed.

People should *demand* that code closest to the hardware is open source. Look at it this way: a company collapses and takes with it a base of code. Would you rather it be a driver at the core of your display subsystem, or your text editor? One product has alternatives that don't render your existing hardware useless.

Did you buy into the Circuit City Divx thing? No? Then you shouldn't go for this kind of crap either. Companies that get my money are the ones that aren't afraid of full disclosure.

IIRC, a similar issue with print drivers was the driving force in the establishment of the GNU project.

Re:Not very supportive of Open source

[MadAhab]

There is one way, and only one way, to completely close code with no loss to the customers, and that is to put that code in hardware and have open specs for interacting with it.

Anything else means that you can be stranded by the vendor.

This technology has been around for years!

[Carrion]

Tungsten graphics is usually low resolution, about 0.25 DPI. It's also got high power consumption and therefore heat dissipation, around 25-90W/pixel. If you want colour, triple those numbers. You wouldn't want one of these displays on your workstation, believe me!
Still, it's often used due to it's scaleability; I've seen dozens of companies use them in the major cities, ever since I was a kid.
Slashdot is behind it's times, posting articles of old technologies, well-known in the advertising business!

For those more interested in the technology, each pixel is made out of a usually pear shaped glass bubble. A tungsten spool is inserted, and the air is removed from the bubble causing a vacuum. When electricity is sent through the spool it starts glowing brightly so that light is emitted. The absence of oxygen from the vacuum keeps the tungsten from oxidating, making it last much longer. By variating the current through the spool, you can increase or decrease the brightness of the pixel.