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

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.