| |||||||||||||
Packard on the state of Linux graphicsPackard on the state of Linux graphicsPosted Apr 25, 2009 18:34 UTC (Sat) by drag (subscriber, #31333)In reply to: Packard on the state of Linux graphics by kragil Parent article: Packard on the state of Linux graphics
This is a total restructuring of Linux and how it handles displays. Total restructuring.
It's taking stagnet and obsolete design that is stuck in the 1980's and getting it competitive with the latest and greatest that any other display system has to offer. And not only just for accelerating GUIs...
efforts to take advantage of those high speed floating point co-processors for general Linux programming is tied into it. Currently it's impossible for Linux folks to take full advantage of their hardware processing power using fully open source means.
Basically all if this would take much too long to accomplish without the assistance of the distributions and user base. Users are free to use systems like CentOS/Redhat/Debian Stable if they don't want to run into problems on production machines.
(Log in to post comments)
Packard on the state of Linux graphics Posted Apr 25, 2009 19:21 UTC (Sat) by kragil (subscriber, #34373) [Link]
Run into _this_specific_ problem.
Debian and CentOS have different problems attached to them.
Packard on the state of Linux graphics Posted Apr 27, 2009 1:58 UTC (Mon) by dag- (subscriber, #30207) [Link]
Debian stable seems a better pick right now, because it is newer than CentOS-5. This in itself is temporary, until CentOS-6 is released within the next 10 months and then CentOS-6 will be for some time newer than Debian Stable.
On the other hand, Debian Stable only gets security updates until one year after the next Debian Stable. Which effectively means you have to upgrade in that one year. Which is vastly different than with CentOS, where you know in advance you can run it with security updates up to 7 years after General Availability. For CentOS-5 that means until 2014 ! For Debian Stable it is hard to tell, you only know it exactly one year in advance :-D
It could be in 18 months, if Debian is able to follow a strict release schedule. Or it could be in another 3 or 4 years ? In both cases it is worse than what CentOS offers, even if that means that you get something older than Debian Stable at *this* moment in time.
Packard on the state of Linux graphics Posted Apr 27, 2009 2:11 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
debian stable gets security updates far more frequently than once a year.
Packard on the state of Linux graphics Posted Apr 27, 2009 2:29 UTC (Mon) by dag- (subscriber, #30207) [Link]
That is not what I said.
I said that you won't get any security updates one year after the next Debian Stable release. So you are forced to upgrade to the newer Debian Stable in that one year, and you do not know in advance when that is going to be.
Packard on the state of Linux graphics Posted Apr 27, 2009 14:45 UTC (Mon) by sbergman27 (guest, #10767) [Link]
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?
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.
|
|||||||||||||