Phoronix: Packard Talks About Ongoing Intel Linux Work
Lately we have talked a lot about the Intel Linux driver stack with their ongoing work of switching over to the Graphics Execution Manager for memory management, moving to kernel-based mode-setting, and migrating to the Direct Rendering Infrastructure 2. In the short term, this work has caused some nasty problems, but once the fallout has been addressed, the open-source Intel driver should be in a prime position to perform on all fronts.Intel's Keith Packard has written a new blog post talking about Sharpening the Intel Driver Focus...
Are they going to use Gallium or it will happen like in TTM vs GEM and they will bring something new that gives them direct advantages over open source driver initiatives for graphics hardware of the competitors (AMD...)?
What about the future of graphics infraestructure of FOSS? Major Xorg rewrite? Wayland as base or alternative? MESA becoming the portable graphics subsystem due to Gallium evolving to 2D too? Evolving X11 so it can compete with remote desktop solutions for Microsoft operating systems and patches like FreeNX no longer necessary?
I'm going to play amateur prophet here and make a few predictions:
Gallium will finally come along in a shippable form late this year. Intel will have it first, followed by ATI, and nouveau will wander around in the hinterlands between stable and unstable due to a lack of documentation. There will be OpenGL 2.1 and 3.1 state trackers quickly. There will be an effort to make an OpenCL state tracker, and someone in the wine project will talk about a Direct3D state tracker.
The size of Xorg will shrink a huge amount as it relinquishes direct access to hardware to a large extent. Wayland will provide display manager functionallity, and people will talk about replacing X-based 2d acceleration with a 2d gallium state-tracker. Xorg will stick around and get major code cleanups once a lot of the DDX layer is removed.
As for network-transparency, I'm not sure what is going to happen. If the x-server doesn't do any of its own drawing, using it as a network-transparent remote-desktop layer becomes less attractive as compared to, for example, VNC. I'm sure there will be discussion on what should be done server-side vs. client side.
Gallium is in beta/alpha stage right now in he Mesa code repositories. I think it's made it into the development releases.
Gallium drivers are DRI2 drivers. DRI/DRI2 is the protocol that you use to communicate between the userland video drivers and the in-kernel direct render management stuff. I beleive that Gallium already has state trackers for the EXA API as well as a number of other APIs.
The long term goal for Xorg is to eliminate all need for your X server to interact with the hardware directly. One of the biggest problems with Linux stability in the past was that the Xserver would access the hardware outside of the direct control of the Linux kernel. So occasionally you'd have Xserver twiddle bits on the PCI bus that it shouldn't, it was hard to coordinate between the needs of OpenGL and the needs of the Xserver, and oddball things like that.
So your Xserver can run under a user's account just like any other program. It will use the normal API that is provided by gallium or whatever, just like any other application you'd care to run.
Wayland is a alternative windowing system for Linux. Its not a 'replacement' for X or anything like that.. it's a alternative.
So keep in mind two points:
* Xorg provides 2 major portions. There is DDX and DIX. Device Dependent X (DDX) is the drivers and Xserver and whatnot. Device Independent X (DIX) is the stuff that applications use, like XCB or Xlib.
So you can install the Xorg DIX (xlib or xcb and other libraries) on a remote machine, run firefox on that, and then display Firefox's graphical output on the DDX stuff (xfree xserver, exa drivers) on your local machine.
Xlib is the older way, xcb is the new ones. What they are is C language bindings for the X Windows network protocol.
So X.org provides lots of different DDX. The one your currently using as a desktop windowing system would be the Xfree DDX. But there are others... like Xephyr which provides a nested X window display (replaced xnest a while ago), Darwin for Mac OSX, one for Windows, Kdrive for embedded systems, and the now obsolete Xgl for a pure OpenGL X display. I think there are a couple beyond that. VNC even uses it's own X display for it's framegrabbing before sending the output over the network.
* A modern display system uses composition. That is the application writes out it's output to a off-screen buffer. That off-screen buffer is then turned into a texture that is then combined with other off-screen buffers by the windowing system to create the display that you actually see on your monitor.
OS X Aqua was the first to do this.. with a completely unaccelerated display (no 2D or 3D accel) back in the OS X 10.1 days. (Aqua Extreme is when it gained 3D accel, I beleive).
Windows Areo does that for Windows and provides for 3D acceleration. (but applications are not provided 2D hardware accel anymore, I beleive)
And with Linux there are a few different ways, Compiz being the most popular.
So if your using Wayland then what will probably happen is that Xorg will create a DDX that does nothing more then write display output to Wayland's off-screen buffer. Then Wayland will then pull that buffer in as textures to be used in it's own display composition.
Using that method it should also be possible to combine other types of displays into your display management system... like maybe whatever Android uses or individual application output over the Remote desktop protocol.
Of course Wayland provides it's own API that applications can use directly and avoid the X Windowing protocol stuff if that is what they want. Like how GTK and similar toolkits have been ported to MS Windows, they are being/can be ported to Wayland.
Personally I think that a X Windows protocol is old and crusty and should be updated with a much more streamlined and modernized version.
wayland is just a display server, it also relies on KMS for modsetting, it isn't a network protocol, and doesn't have a DDX(whch would be called Device dependent wayland). Also it takes many things out of the server.