The State of Linux Graphics

jonsmirl writes "I've written a lengthy article covering what I learned during the last two years building the Xegl display server. Topics include the current X server, framebuffer, Xgl, graphics drivers, multiuser support, using the GPU, and a new display server design. Hopefully it will help you fill in the pieces and build an overall picture of the graphics landscape."

Comments

ATI Drivers

[GecKo213]

I just want an ATI driver that will work in full screen mode with my Dell Laptop. Too much to ask, maybe, but I'm making due just fine with what I've got. (Fedora FC4 w/ Enlightenment)

Re:ATI Drivers

[Tet]

Here's a problem: It is a 9250. Being an RMS emulator has its time and place, but lets be realistic shall we?

Sure, let's be realistic. I have a 9200 because at the time I bought it (last year, IIRC), it was the fastest card available with free drivers. Yes, that's important enough to me to be worth putting my money where my mouth is. You know what? The 9200 turns out to be a pretty decent card. OK, so it may not be a match for the latest whizz-bang-turbo-plus-FX-hyper-overdrive card, but in terms of putting pixels on the screen, I've got no complaints. It keeps up with everything I want to do, both 2D and 3D. Unless you're wanting to do heavy duty CAD (which I'm not), or unless you're wanting to play games with Cedega (which not being free, I'm not), then it's a great graphics card for Linux systems, and I can highly recommend it.

I'm living proof that it's possible to be ethical about your purchases, and still have a usable system. So what's not realistic?

Whatever happened to Looking glass?

[Anonymous Coward]

Im sure you guys remember the Looking Glass demo that Sun showed us a year or so back. This article mentions Project Looking Glass, but only explain what it does. Did Sun just throw this up for publicity? Are they ever going to opensource it or make it more widely avaliable?
Linuxgangster.org

Proprietary driver + cairo ?

[Anonymous Coward]

Interesting read. I'm quite happy with my nvidia proprietary drivers as long as Cairo/glitz/whatever will use that to make my desktop more responsive.

I hato to see a lousy looking window-drag (ie. sloow update) when I know I have a professional video card. It really bugs me and this is the reason I also bought an iBook (well, besides the BSD inheritance).

A little OT, but...

[Anonymous Coward]

here's a demo of a hacked version of KDE running on a XGL server

http://rapidshare.de/files/4553011/xgl_wanking.avi .html

Demoed at aKademy 2005, KDE's developers conference.

According to the developer, this is on a 4-years-old notebook running ATi hardware. Quite impressive.

Thanks Jon!

[IamTheRealMike]

I'd just like to say thanks to Jon Smirl for writing this. I've been following X development for some time on the various mailing lists and so on, but for an outsider looking in it's nearly impossible to get an accurate picture of what's happening and which bits do what let alone what peoples plans are.

I think it's a crying shame Jon has stopped working on Xegl - we can only hope others will pick up from where he left off. It looks like Linux graphics is going to go through a series of half-way steps before arriving at fully OpenGL accelerated graphics: Exa based drivers first to speed up RENDER based graphics, then Xglx running on top of an existing X server to utilise its mode setting and input code, then finally Xegl which eliminates the existing X server entirely in favour of a new one that pipes all its drawing directly into the 3D pipeline.

Question is, how long will it take?

Re:_Eight_ redirections?

[IamTheRealMike]

Well, it's not as bad as it looks.

App to GTK+ is just some function calls and data structure manipulation. Like on any OS widget toolkit.

GTK+ to Cairo is the same: Cairo and GTK+ are both shared libraries. Cairo takes drawing instructions from GTK+ and translates it into low level primitives that map directly to the XRENDER protocol.

XRENDER is just a wire format - a way to tell the X server what to do.

Xgl is an X server. You need a single entity controlling video hardware, otherwise things get complicated very fast. Existing GL drivers don't like being used by lots of apps at once as they were built primarily for games. By centralising control of the hardware you can optimise things and deal with existing hardware/drivers.

GLX->GL->hw - this is only temporary until enough infrastructure has been integrated into the kernel to obsolete the existing X server.

The computer from Dell...

[MECC]

I recently tried reinstalling windows on a Dell, using the Dell 'recovery' CDs (OS and drivers) that came with the box. Everything worked except the video. Windows had to boot into 'safe' mode in order for the video to work, and then it was at reduced bit-depth. This was a factory shipped Dell, with factory shipped CDS - I added nothing to it. Of course the problem can be easily fixed, but my point was that it was a problem in the first place.

I booted the same box with Ubuntu live 5.04. X came up fine, no problems. I had to do nothing at all for it to work just fine.

Windows: 0
Linux: 1

This kind of thing happens way too often. What the hell is MS doing with its time - making TPS reports? I guess this is what you get when you spend your resources buying software instead of making software.

The X-Window system is not about Linux graphics.

[master_p]

The X-Window system runs in a variety of O/Ses, including every flavor of Unix, Mac OS X and Microsoft Windows.

What I haven't understood all these years of 3d development is that why X-drawing calls are not converted to OpenGL drawing lists. An X-Window server could take the graphic calls and store them as OpenGL drawing commands, and each time some window is redrawn, the commands are sent to OpenGL and thus the graphics card. That would mean automatic antialiasing, full zooming etc.

Re:More than X will need fixing

[DreadSpoon]

"Can you imagine what Gimp would be like written on top of the EFLs?"

Ugly, inconsistent, unusable, gimmicky, and unprofessional?

The Englightenment libraries are certainly great as demos of what you can do with a graphics system, but they are *not* a replacement for Xegl. That is, the Enlightenment libraries have just as much to gain from Xegl as do any GTK/cairo-using apps or Qt/arthur-using apps.

Switching from GTK to the Enlightenment libraries really bugs you nothing. If, and *only* if, the Enlightenment libraries offered *all* of the features of GTK, including the extensive accessibility support, advanced multi-lingual support, and so on would the Enlightenment libraries even be good enough for GIMP, or any serious application for that matter. Even then, if you already have something running on GTK/cairo, what do you hope to gain? The Enlightenment libraries pretty much give you nothing noteworth except for some optimized rendering (which really can and should be done in GTK/cairo, removing the need to recode the entire damn application for a likely imperceptible speed boost) and some funky theming options, which likewise will probably be seen in forthcoming GTK releases now that the Cairo integration is underway. (Check out Seth's blogs on Cairo-GTK themes, his mockups/examples do many of the things that the Enlightment libraries do, but do it without needing to rewrite your application or lose vital functionality provided by GTK/Qt.)

Enlightenment is a lot like the graphics demo scene: they are *really* cool looking, but not paticularly practical or useful. They could have spent the time writing all those new Enlightenment libraries as new GTK/Qt theme plugins and patches and had a usable, complete, functional desktop and set of development libraries today, or they could, well, spend 5+ years implementing a still incredibly incomplete environment that has little to no mindshare. Oops.

Rewriting is usually not the answer, especially not at a high level. Xegl can be installed on your machine and all your old apps will continue to work with no changes. Drop in a new GTK theme or GTK library that uses cairo and all your existing apps get the new functionality (like rendering over GL and anti-aliasing and such) for free. Even if you have to extend the GTK API to get things like funky animated themes, it's much easier to port a GTK app to a new GTK version than it would be to port it to a totally new set of libraries.

Summarizing with a popular phrase among engineers: "evolution, not revolution."