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.

Re:Graphics expertise and their website

[randumb_surfer]

After looking at your site I don't think they'll be coming to you for site design assistance.

Isn't the abbreviation wrong?

[kawlyn]

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

Re:Isn't the abbreviation wrong?

[rlowe69]

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

>wang grabbing?
>wookie grease?
>womanly grunts?

*sigh* ... W is the chemical symbol for the element Tungsten - incidentally, the W stands for wolfram. Don't they teach basic chemistry in high school these days? Maybe I'm just biting a troll ...

Here is to wishing..

[Erasei]

We believe that OpenGL 2.0 needs more industry support

I would +love+ to see this happen, especially in the gaming area. I know we (the /. readers and karma whores like myself) all talk about how great Linux is, and for the most part, I agree. I would not replace my Slackware server for any version of Windows, ever. But I still run a Windows desktop, purely for gaming. That is really all I do on my home desktop, is play games. I would love to be able to play those same games on a *nix machine.

Then maybe I wouldn't feel slightly guilty for pirating windows.. naaah.. I don't feel guilty.

I realize that this article was covering far more than just games.. but I know games are what we are all thinking when we hear the terms 'OpenGL' and '3D'.

OSS Radeon Drivers.

[reaper20]

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

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.

Look out nvidia.

[Penguinoflight]

With the Radeon 7500 (the one with the technical stuff to smash a geforce 3), nvidia will likely see a loss in it's sales to linux users. The Radeon 7500 is actually a radeon 64mb ddr that goes a lot faster. The radeon 8500 on the other hand is another generation, too bad it's not supported yet.

To be frank, if it weren't for the heat that nvidia cards produce, I'd probably get one. I just can't afford to have my server go down because a GPU overheated and pumped the case tempurature to 120 degrees. I don't want a video card that has a fan for something other than cosmetics.

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.

2D performance of current Radeon drivers is awful

[Thagg]

The current DRI Radeon drivers are fine for 3D, providing pretty much the full power of the machine to the Linux world -- but the 2D performance is awful. Why, you might ask? Because when ATI contracted with VA Linux to create the drivers, they only funded development of 3D, and didn't specify that the 2D performance should be accelerated.

This turns out to be a real problem in the visual effects community -- a lot of our work depends on having good, fast 2D. Film frames, after all, are still just 2D images.

I hope that this new driver they speak of, and future drivers, recognize this. We'll see. At this point, we have to by nVidia boards, even while the drivers are closed-source, they provide pretty good 2D support.

thad

Precision Insight

[4of12]

Am I correct in my impression that Precision Insight included some of the more famous names from SGI and that some of these same people would be part of Tungsten Graphics?

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.