Slashdot Mirror
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."
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)
Generation Trance: What generation are you?
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
There's also a discussion about this on the linux-kernel mailing list (lkml) currently - certainly worth reading:
= 1&w=2
http://marc.theaimsgroup.com/?t=112541793700006&r
quidquid latine dictum sit altum videtur.
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).
here's a demo of a hacked version of KDE running on a XGL server
i .html
http://rapidshare.de/files/4553011/xgl_wanking.av
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.
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?
My conclusion is that most people don't really know what is going on with graphics in Linux. It's understandable that people don't see the whole picture. Graphics is a large and complex area with many software components and competing developer groups.
...now just lemme read that X server RFC...
But it really should be like.. at most 3 indirections:
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..
gtkaml.org
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.
Actually, Apple came up with their GUI after seeing a demonstration at Xerox PARC, here's some good reading for you.
-Scott
My other sig is a Glock
The WinXP user in me takes graphics and gui for granted. You turn on your PC and it just works, no matter what.
.conf file had the wrong PCI Bus address.
But when I run Linux, that isn't necessarily true. I've run Redhat, Mandrake, Fedora, and just last week, Kubuntu. It's always "just worked" for me, until I installed Kubuntu. I threw it on an old IBM laptop, and I couldn't connect to the X server for the life of me. Well, after several hours spent on Google Groups, I finally found the solution: my
After fixing that, all worked wonderfully! Any of you who know X well enough to be able to do anything with it, props to you. Especially those developers who made it possible to just throw an install CD into a PC and have it automatically detect all the drivers AND set up X correctly. Very cool.
IGB: More fun than eating oatmeal!
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...
...during the last two years building the Xegl display server.
He must be using Gentoo. *ducks*
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.
Schrodinger's cat is either dead or really pissed off...
Even if a "perfect" X server is implemented, that's not the end of the battle to give the Linux desktop a facelift. It's the beginning.
Toolkits running on top of X are just as important to Desktop Goodness as the Xserver is, and they can only be updated AFTER the X situation is stable. GTK and QT are the obvious ones, and I'm sure work will proceed on them, but I suspect such changes would be significant enough that they would warrant a major release, and lots of work to fully integrate new X features as opposed to just bolting them in.
Frankly, I think the best way to proceed would be to take the useful parts of Gnome and assorted GTK apps and port them over to the Enlightenment Foundation Libraries, once they are stable. Enlightenment DR17 is probably the only environment available with the potential to pass itself off as a next generation desktop for Linux and make it stick. Can you imagine what Gimp would be like written on top of the EFLs? (drool). Of course, that's too much work to expect it to actually happen on a large scale, but it might be that Gnome's recent trend toward simplicity could make such a target easier to achieve.
QT I think is in good hands - trolltech has proven quite good at making good toolkits with increasing performance in each new release. I'm sure it's just my perception, but GTK widigets feel clunky to me and I really think a shift by the Gnome effort to the EFL base would rock the Linux desktop world. Of course, that's easy to say and hard to do, but major landscape changes are not made by minor efforts.
"I object to doing things that computers can do." -- Olin Shivers, lispers.org
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.
"We are all geniuses when we dream"
- E.M. Cioran
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.
Security: Currently, X runs as root on Linux. It doesn't need to, it just does. That means 16M lines of code to audit. A set of kernel modules for Linux to handle root access plus running the rest of X under a non-root user would go far in solving this issue and getting wider (aka DOD, ...) acceptance.
Portability: Linux + X does things differently from other *nix + X. X should act more like an OS with the OS interface needed for hardware acess only. This would eliminate a few layers and projects currently handling different issues.
3D vs. 2D: 2D is going away. 3D hardware is cheap and highly accelerated. 2D is not even on older hardware. You can do 2D with 3D hardware. 3D support under X is limited and mostly propriatory...partly because of the kernel (security) and layers (portability) problems.
There is no reason why X can't be updated to handle these problems, though it does take quite a bit of effort and a road map from X.org that currently does not exist.
A lot of this article is flamebait. Jon is pretty obviously bitter that the rest of the X developers didn't feel his sense of urgency in moving everything to Xegl right away.
The fundamental difficulty in getting specs to write and maintain open drivers for various video cards still exists, and any move to a fully OpenGL-based system will still have this barrier for a large number of people. If you've ever tried to run sw-based mesa, you know how slow it is, so on a fully OpenGL subsystem a large number of people will have to run it using the proprietary drivers. These work well for some people but for others they crash constantly and integrate poorly with the rest of their system. Ultimately, the X developers have their hands tied with these drivers because they can't fix them. Imagine a world where most everyone running all of X on these drivers, from 3D games to xterm, and you can see a serious problem.
Jon just brushes this off in his article ("believe it or not some people like the proprietary drivers"). Meanwhile, he calls the current effort to actually make the code work a "bandaid" even though it shows great promise to actually deliver useable drivers for a large number of people in a very short amount of time. He laments that X doesn't handle hotplugging well, but ignores the many efforts to implement this (check the X wiki for info) and the fact that no one has really figured out the best way to do it. He willfully ignores the fact that X needs to run on non-Linux systems, and as such it can't rely on many of the facilities he talks about.
Jon's definitely a smart guy, and he understands X incredibly well, but he's unwilling to accept that maybe he's not prioritizing things very well. He certaintly hasn't done a great job of selling Xegl to the rest of the X world, because if he had he might not have written this wonderfully elaborate troll.
"I may not have morals, but I have standards."
By the way, the X Window System article will be the Wikipedia front page feature on September 3rd.
http://rocknerd.co.uk
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!
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
One area the article didn't touch on at all was MPEG decoding. Most video cards today have hardware to accelerate decoding of MPEG2 video. Some even have MPEG4 acceleration.
For lo-res stuff, like DVDs, this is not a big deal because modern CPUs don't break a sweat decoding that stuff. But, when you go to HDTV (1920x1080i / 1280x720p) video, even fast processors feel the load. In Windows, there is a standard API (DxVA) which is supported by most video drivers. In the Linux world, there is similar support, but it's a bit trickier..
Linux XvMC API - Enables hardware offload of iDCT and Motion Compensation in MPEG2 processing. The API is relatively new, and support has recently been added to key applications (MythTV, Mplayer, Xine, (vlc?) ).
NVidia - supports XvMC in their binary / closed source driver releases. XvMC is suported by their newer FX series cards (and newer), and GeForce4 MX cards. It is not supported in the hardware of the other GeForce4 cards.
ATI - No support for XvMC in Linux. (ATI was the pioneer of the MPEG2 acceleration hardware, available in their Radeon line for many years. But, they don't support this at all in Linux.)
VIA/S3 Unichrome - There is a Unichrome driver project on sourceforge, which supports the excellent MPEG2 accleration of the Unichrome integrated graphics processors. (Though, it's not clear to me if it's completely open source or relies on VIAs closed drivers/libraries). The S3 MPEG2 processing is beyond normal acceleration. They do full MPEG2 decoding in hardware - which allows for HDTV display with very low CPU requirements. S3 also has standalone video cards (DeltaChrome, GammaChrome), I don't know the state of Linux or MPEG2 support for those. The Unichrome also has hardware support for MPEG4 processing, which is not yet supported in Linux.
Others - Any other Video cards with XvMC support in Linux that I missed?
--- The MPEG2 acceleration support in Linux is not great yet. But, at least it's better than MacOS.. In OS X, the DVD player is built with MPEG2 acceleration support, but no other applications can use it (there is no open / published API). So, HDTV display has ridiculous CPU requirements (Dual G5 is stated as required for the ElGato EyeTV 500). The vast majority of Macs have video hardware that supports MPEG2 accel, but none can actually use it.
The state of Linux graphics is in my opinion, better than Windows. I've had long nights of reinstalling the OS (Windows) just because I had a bad video driver that corrupted the system. Not even restoring the system from a backup helped. But what I am certainly curious about is minimizing the compile time on systems with higher-end video cards. If GPUs can be utilized for sorting processes and some boards contain more than one processors, why aren't we utilizing these high-speed processors to aid in compiling a kernel for our computers? I don't see the problem since audio processing is already being done.
-- Game Developers: Stop porting badly-textured games from crappy console systems!
You seem to have a twisted view of what is "open".
First, consider the graphics cards we have now, such as ATI and nVidia. Those are what we call "not open at all". You cannot get specs, or open source drivers for the latest stuff. This is what you have.
There are a few low-end manufacturers that do publish specs. But you still don't get anything the least bit interesting about internal workings. Those are what we call "open spec".
The design for OGP is what we call "open architecture". At first, what you get are complete specs, plus detailed descriptions of the internal workings of the GPU. Then, when the $2 million or $3 million espense for the ASIC is paid off, you get the whole design of everything under GPL. Is that open enough for you?
The first OGP product is a "development platform", which is under LGPL from the start, with lots of code published already.
Is that open enough for you?
To reinforce my point, the major drawback to Linux is simply 'death by committee'.
I have seen this phrase popping up from Mac advocates over and over recently; it seems to be the latest marketing meme from Apple.
In fact, nothing could be further from the truth. Linux isn't designed by committee or anybody else; Linux isn't even an operating system in the sense of OS X, it's a family of operating systems. And what goes into those systems is shaped by market forces and user choice.
Windows and OS X are designed by little self-appointed elites inside Microsoft and Apple; if anything is "designed by committee", it's those systems. Whether that's a good thing is debatable. I believe more in the power of market forces and evolution than despotism, but your preferences may differ.
What Linux needs is for one company and/or person to do the same thing.
There are companies that are doing just that. Have a look at Ubuntu and Linspire, for example.
Otherwise, Linux will always be 2nd or 3rd to something else.
Given Apple's checkered history and modest market share, it doesn't seem like Apple ought to be the model to go for. In any case, we'll take your advice for what it's worth.