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

Re:Whatever happened to Looking glass?

[zr-rifle]

Looking Glass is a move akin to flexing your muscles at the gym. Sun just wanted to prove "their stuff" to Microsoft and Apple, demonstrating a desktop technology demo.

It's barely usable and already been opensourced because, once shown to the press, it had little use to them.

lkml discussion

[slavemowgli]

There's also a discussion about this on the linux-kernel mailing list (lkml) currently - certainly worth reading:

http://marc.theaimsgroup.com/?t=112541793700006&r= 1&w=2

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).

Re:Proprietary driver + cairo ?

[Trigun]

...and this is the reason I also bought an iBook (well, besides the BSD inheritance).

With BSD Dying, you should be collecting that inheritance shortly.

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:Thanks Jon!

[Anonymous Coward]

I'm posting anonymously because I don't want to seem like a suck-up - rest assured, though, that I am not Jon :)

I think it's a crying shame Jon has stopped working on Xegl

I think it's a crying shame that no one (i.e. Red Hat, Novell, IBM, etc) stepped up to sponsor such an intelligent and capable guy, even with just a living wage (although I'm glad that Novell hired Reveman, at least) - and the same goes for drobbins. IBM in particular has damn-near bottomless pockets for R&D, and I bet they hire legions of lesser skilled workers doing more menial jobs. Could they not have spared the budget equivalent to one extra support-monkey for such an exceptional talent? It boggles the mind, quite frankly.

Ungrounded Optimism?

[minginqunt]

Two years ago at FOSDEM, the Xorg fork had just occurred, and there was much excitement. Maybe this time, free from the shackles of the X consortium and XFree86, X would actually improve to the point where we can be proud, and snicker at our Mac OS X using chums and say "Why can't Quartz do this then, eh?"

Unfortunately, the way I read this article is:

1) Linux Graphics is a bloody mess.

2) X is still an embarassment, five years behind (at least) what Quartz and Avalon are capable of.

3) Nobody has the time, manpower or inclination to fix it.

Ah tits.

Ten years ago, we were having the discussion about X being b0rken. In ten years time will we still be having this discussion?

Plus ca change...?

Actually I am still excited about X's future. Yes, X development stagnated pretty badly under XFree86. But things are moving along nicely now that X development is being conducted at X.org.

The state of Linux Graphics isn't a mess. The controversy this article caused on LKML shows that many people are talking and working together and feel that things are improving. It may not be close to what Quartz is capable of yet. But it is still moving the right way.

The Big Iron vendors let X stagnate because they never ever seemed understand the desktop space. Stupidly, they let Bill and his minions stroll in and take it over before they really had any chance to grasp what a mistake they'd made.

Then XFree86 let X stagnate further, thinking of itself as some exclusive Gentleman's Club.

Fortunately, the foundations of X are right. Simple, modular, highly extensible. If there's one thing the Unix Way gets right, it's simple, modular and extensible.

Now, perhaps, X has finally space to really thrive and grow.

I reckon the Slashdot will still be having "X Suxx0rs!!!" flamewars in 10 years. I hope also that those trolls will be even more wrong than they are now.

Perhaps my terminal optimism is sweetly naive, but I sincerely hope and expect X to go from being "just-about-ok" now to leaving Mac OX smoking dead in the dust in the next few years.

Re:Ungrounded Optimism?

[Coryoth]

Actually, that might be a good idea... how about someone creates a really good commercial windowing system for those poor souls who have to use X every day? I'd love to have something with the quality of Avalon or Aqua on Solaris. That would be fantastic!

It's all a matter of what level of graphics architecture your talking about though. In many ways X is simply a matter of how you draw graphics to the screen, how you access the hardware. You're, for some reason, comparing it with Aqua and Avalon. In practice X is more comparable with Quartz and GDI which Aqua and Avalon sit on top of. You want something comparable, then try looking at GTK sitting on top of Cairo. Cairo provides the same sort of drawing abstraction and interface that Quartz offers, the same sort of thing Avalon offers. It also has multiple backends so if you work in Cairo you can display on X, Quartz, Windows, or in print via PDF or Postscript. You can use Cairo acclerated over OpenGL. In terms of ease of programming Cairo offers a nice graphics API of various drawing commands. If you want a GUI interface (as in Aqua or Avalon (I think - I'm still a little unclear on what all Avalon exactly entails)) then you'll want a toolkit to expose an interface there. Something like GTK is being converted to run on Cairo (the latest version of GTK uses Cairo for some of its rednering already). It's there in Free software, though it is still young. It provides a lot of what you're looking for and X doesn't matter a bit - X is just how you draw to screen... and in a conveniently network transparent way. X doesn't necessarily suck, but a good graphics stack in Free software is certainly fairly young right now. The need is fairly new as well though... the desktop was not something that was much of a focus (everyone kept saying the desktop wasn't viable). It is coming along though.

Jedidiah.

Re:Ungrounded Optimism?

[cahiha]

Unfortunately, the way I read this article is:
1) Linux Graphics is a bloody mess.

And you think other window systems aren't? Apple tried to redo MacOS multiple times, until they eventually gave up and bought NeXT. Microsoft tried GDI+, then Avalon, and both have had big problems. Reengineering large amounts of code, and augmenting interfaces that have been in use for two decades simply is a hard task. Unlike both Apple and Microsoft, which have solved the problem by starting over (and maintaining old versions for compatibility), X11 has managed to evolve.

2) X is still an embarassment, five years behind (at least) what Quartz and Avalon are capable of.

Quartz didn't even really exist five years ago, it got limited 3D hardware acceleration only recently, and even today, most of it isn't hardware accelerated by default. If you really want a Quartz-like graphics subsystem under X11, there have been multiple implementations of DPS for X11 around for years; it's no coincidence that Linux desktop developers have chosen not to use them.

And Avalon? Avalon has been delayed over and over again. Eventually, it may give you about what Firefox and several other systems already give you on Linux. With Avalon, Microsoft is years behind, not years ahead, the state of the art.

Now, perhaps, X has finally space to really thrive and grow.

X has thrived and grown since its beginning, despite people badmouthing it. See, unlike the stuff Apple or Microsoft put out back then, X11 has actually survived this long, and that's because it works and it can be adapted.

X is hard to code for!

[Anonymous Coward]

There are lots of issues that need to get resolved reguarding X and Unix/Linux. The biggest one I've seen is that the developers are super focused on everything being GPL all the way down to the driver level. Here's an example I have a SiS 650 it uses the SiS 315 chipset. Currently there is no 3D driver available in X.

But, When I started to dig further into why the SiS 315 wasn't supported. I found out that the SiS 315 was the basis for all of SiS/XGI's new chipsets and included all kinds of new IP, register informtion/locations, and therefor datasheets could not be released to create an open driver. Ok, that is reasonable. So I asked if I could view the datasheets. After sighing an NDA I receievd all chipset datasheets within 2 weeks and an internal chip development contact. SiS/XGI was more than happy to work with me to get things to run under Linux/Unix but, their hands were just tied about releasing the specs as open. Also they don't have the technical resources to create a X driver.

Why can't a binary driver be accepted? I understand the implications. But seriously there are times when you need to look at the bigger picture.

My rant is done...

Re:X is hard to code for!

[krmt]

Why can't a binary driver be accepted? I understand the implications. But seriously there are times when you need to look at the bigger picture.

I think you need to take your own advice. What happens when you go away because SGI won't pay you any more or decides to cancel your contract? Who can port the driver or make bufixes? In a year? Or two? What about all the users who are dependant on your driver?

The bigger picture is that we need open drivers so that we're not reliant on you or anyone else. If you want to distribute your own binary driver, go ahead, but the rest of the world needs that driver free.

Oh, and X.Org doesn't want things licensed under the GPL, but the MIT/X license, just like everything else in the tree.

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.

Re:_Eight_ redirections?

[serialdogma]

>the toolkit --> the X server --> and the driver/hw!!
>When I saw this (App->gtk+->Cairo->XRender->Xgl ->GLX(X)->GL->hw) it blew my mind..
Well it is really more like this

App->toolset->Cairo->XRender->Xgl->GLX(X)->GL->hw
|___App______||__Xserver_______________||OpenGLdri vers/hardware
(might not be lined up)

It is in fact the 3 part system that you think it should be, however it (for many diffent reasons) spilt up into subparts.

Like if I where to show you the way a file system works i might draw:
App->API->driver->hardware
when it is more like:
App->API->filesystem driver->device diver framework->PCI bus driver->PCI to IDE controller driver->Disk driver
It is still in the same 4 parts as it was shown in the first but this( 2nd one) is more detailed.
And as this is "News for nerds" surly we should crave the more detailed account.

Gentoo

[MoogMan]

...during the last two years building the Xegl display server.

He must be using Gentoo. *ducks*

Re:disagree with eye candy

[DrWhizBang]

I think what he is saying is that the current crop of video cards have a much more powerful 3D engine than they do 2D engine. You can perform 2D operations with the 3D engine and they are executed faster than they would be if they were performed with the 2D engine.

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."

Re:The X-Window system is not about Linux graphics

[mrchaotica]

Err, isn't that what Xgl or glitz or whatever is supposed to be doing? I think the reason this hasn't been implemented is that they just haven't finished it yet!

Re:Flamebait

[jonsmirl]

If you compare the 2D performance of an ATI Rage1128, Radeon 9000, and a Radeon X850 you will discover that they all perform about the same. But if you compare 3D performance of the X850 to the R128 you will see a 500:1 improvement.

I didn't brush the open driver issue off, I simply chose not to address a topic that is the source of a lot of controversy. I am well aware of the problems of obtaining driver documentation.

X just needs to make a choice, continue with the flat-lined 2D performance or make the jump to the 3D hardware. If X chooses 3D I would much rather see if use a well designed, standardized API like OpenGL than to slowly extend the existing code base to start using 3D features like EXA does.

If you want open 3D drivers go lobby the hardware vendors to release code and specs. However, I think it is wrong for Linux to ignore the immense performance gains available from the 3D hardware on the grounds that the hardware is not completely open. Withholding use of 3D hardware on Linux will do nothing to open the vendors and it will definitely result in Linux having an inferior competitive desktop experience.

Have you considered that the opposite effect might happen? It Linux builds an excellent 3D desktop and attracts a lot of new users the hardware vendors may start to take Linux seriously and open their specs.