Packard on the state of Linux graphics [LWN.net]

Packard on the state of Linux graphics

Posted Apr 27, 2009 14:45 UTC (Mon) by sbergman27 (guest, #10767)
In reply to: Packard on the state of Linux graphics by drag
Parent article: Packard on the state of Linux graphics

Since Novell first released their X server on an X server, XGL, and introduced "The Cube", I've been hearing that the ultimate "solution for everything" was for the X server to just do everything, 2d and 3d, in OpenGL. Do these changes get us there? Or is there further restructuring needed for that? Or is that goal not really the desired destination?

(Log in to post comments)

Packard on the state of Linux graphics

Posted Apr 27, 2009 17:31 UTC (Mon) by slougi (subscriber, #58033) [Link]

Xgl was really a hack - the implementation that was initially demonstrated piggy backed on another X server.

The idea is still to take advantage of the 3d support of modern cards, but not directly through OpenGL for application developers. Instead, applications are generally expected to use X Render. Internally in the drivers, this might be accelerated with the same hardware that drives the 3d engine on graphics cards. In the general case that we are transitioning to, rendering happens to off-screen surfaces, which the compositing manager (kwin, compiz etc) then draws on the screen. This way you get the nice cube bling effects.

Gallium3D (http://en.wikipedia.org/wiki/Gallium3D) will provide a uniform framework in which to develop drivers, hopefully making the above more stable and performant in the future.

The above already matches and exceeds in flexibility other current systems like OS X and Vista in regards to plain rendering. Another big piece is XRandR support, which allows for adding and removing screens on the fly. Basically, you have a big root window, which is a parent to all other windows. When you add a screen the root window is resized, and each screen displays a part of the root window. This allows for things like cloned output on certain screens (just output the same region of the root window) and arbitrary placement of screen positions in regard to each other (screen 1 is left of screen 2 and down 60 pixels).

Maybe, just maybe given some time (a year or two on intel hardware is my estimate...) I will be able to add a new screen without the X server crashing, my apps freaking out, or the kernel panicking... Looking forward to it. I think the approach is sane and has a good chance of working once it stabilizes. It's about time.

Packard on the state of Linux graphics

Posted Apr 27, 2009 19:31 UTC (Mon) by drag (subscriber, #31333) [Link]

Ya.. I originally thought the pure OpenGL environment would of been the way to go, but there are a couple problems with going pure-OGL server.

1. Doing 2D graphic acceleration for applications on OpenGL is more difficult/irritating then originally thought. EXA was developed as a replacement for XAA and is actually able to run quite well on 3D hardware.

2. OpenGL is only designed for a application API. There is nothing in the standard for managing displays, video memory, etc. Mode setting and whatnot is actually VERY VERY hard to get right.

Then people realized also that they will want to use the GPU for other tasks like OpenCL, shader languages, video acceleration, codec acceleration, etc.

So the thoughts went from "OpenGL for everything" to extending the existing DRI protocol used by OpenGL to allow drivers that support multiple APIs (gallium) then putting a unified memory management scheme and mode setting into the kernel.