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

8 of 164 comments (clear)

  1. Here is to wishing.. by Erasei · · Score: 3, Interesting

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

    --
    visit my free wallpaper collection, wp.erasei.com
  2. Will graphics be getting closer kernel ties? by Flarners · · Score: 4, Interesting
    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.

    --
    "The problem with the French is that they don't have a word for 'entrepeneur'." -George W. Bush
    1. Re:Will graphics be getting closer kernel ties? by BlueGecko · · Score: 4, Interesting

      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.

  3. Not very supportive of Open source by A+Commentor · · Score: 5, Interesting
    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.

    --

    Looking for any old 8-bit Heathkit/Zenith software/hardware - http://heathkit.garlanger.com

    1. Re:Not very supportive of Open source by MrHat · · Score: 5, Interesting

      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.

  4. Imporving the Radeon driver... by wbattestilli · · Score: 2, Interesting

    Would be great!!!

    I would really love to buy a radeon for my Linux workstation, but nVidia provides superior dirvers. I would like to philosophically take a stand and reject nVidia for their refusal to release specs but I need complete and efficient drivers. The radeon currently cannot compete with nVidia on linux (or windows) even though the radeon is likely better hardware.

  5. Re:Graphics expertise and their website by Anonymous Coward · · Score: 1, Interesting

    Have you noticed most engineering firms have crappy website? They're engineers for god's sake, not some unemployed slacking web-designers.

  6. Re:We've been waiting by Anonymous Coward · · Score: 1, Interesting

    If you want to fuck someone, fuck NVIDIA. They have offered licensing terms for NV_vertex_program that are impossible for most of the industry to accept, and have repeatedly claimed IP on all vertex programming APIs while refusing to identify what that IP is, so that the ARB and other vendors can avoid it.

    NVIDIA has also engaged in a great deal of spin control and has jerked other vendors around by saying they'd changed their position and were offering the extension up without any conditions, then suddenly reversing course after work on a unified interface had been underway for months.

    Their recent offer of NV_vertex_program under license to Brian Paul must be looked at very sceptically in light of their past history.