The State of Linux Graphics 349
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."
ATI Drivers (Score:5, Interesting)
Re:ATI Drivers (Score:2, Interesting)
Re:ATI Drivers (Score:2)
Re:ATI Drivers (Score:3, Interesting)
Re:ATI Drivers (Score:2)
Here's a problem: It is a 9250.
Being an RMS emulator has its time and place, but lets be realistic shall we?
Re:ATI Drivers (Score:5, Interesting)
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?
Re:ATI Drivers (Score:3, Insightful)
This Linux elitism just doesn't seem to change. "I don't have a problem doing what I want to so if you do you must be an idiot" is not going to make you an
Re:ATI Drivers (Score:2)
It has a Mobility Radeon 9000 and I haven't had any trouble using it (hardware accelerated) with the default Fedora drivers. OpenGL is a little slower than with ATI's drivers, but it's not enough to make games look bad.
Whatever happened to Looking glass? (Score:4, Interesting)
Linuxgangster.org [linuxgangster.org]
Re:Whatever happened to Looking glass? (Score:3, Informative)
Re:Whatever happened to Looking glass? (Score:2)
I say this based on a plethera of responses I got asking about running the dynamically linked version of Opera against my GPL'd QT library.
The response was as follows (paraphrased).
You idiot, the GPL is only about distribution, not about running it, how is
I thought it was a llittle h
Re:Whatever happened to Looking glass? (Score:5, Informative)
It's barely usable and already been opensourced because, once shown to the press, it had little use to them.
lkml discussion (Score:5, Informative)
http://marc.theaimsgroup.com/?t=112541793700006&r
Proprietary driver + cairo ? (Score:4, Interesting)
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 ? (Score:4, Funny)
With BSD Dying, you should be collecting that inheritance shortly.
The Drivers Are The Problem (Score:3, Interesting)
If Nvidia and ATI released their specs today Linux would still be at least 2 years behind Windows and OSX- thats how long it would take to make drivers from
A little OT, but... (Score:5, Interesting)
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.
Re:A little OT, but... (Score:3, Funny)
Re:A little OT, but... (Torrent) (Score:2, Informative)
dht://395CB97AFF235BABAAFFBE6BB2771353758C370B.dh
4/4MBIT norweigian fibre based seeder.
Thanks Jon! (Score:5, Interesting)
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! (Score:5, Insightful)
_Eight_ redirections? (Score:3, Interesting)
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..
Re:_Eight_ redirections? (Score:5, Interesting)
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? (Score:5, Informative)
>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_______________||OpenGLdr
(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.
Re:_Eight_ redirections? (Score:2)
That's exactly why you don't want to use Xglx. You want to use direct rendering, which looks like:
App -> gtk+ -> Cairo -> glitz -> GL -> hw
Ungrounded Optimism? (Score:5, Insightful)
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? (Score:4, Insightful)
I reckon the Slashdot will still be having "X Suxx0rs!!!" flamewars in 10 years.
It's not a flamewar if everyone agrees
Re:Ungrounded Optimism? (Score:2, Interesting)
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 somethin
Re:Ungrounded Optimism? (Score:5, Insightful)
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? (Score:2, Interesting)
Never happen.
Oh, X as a protocol/platform may conceivably support Quartz functionality and beyond (Display SVG?), but in terms of the interface, I don't see any free WM in the same ballpark as OSX in terms of usability. KDE comes closest to quartz in theory (frameworks, OO, DCOP, KParts), but there is still only a nascent appr
Re:Ungrounded Optimism? (Score:2)
Re:Ungrounded Optimism? (Score:2, Insightful)
To reinforce my point, the major drawback to Linux is simply 'death
Re:Ungrounded Optimism? (Score:2, Insightful)
I migrated to Linux precisely because it was free from Bill Gates, Steve Jobs, and anyone else's domination. The whole appeal of Linux is that you can have your OS your way, not how Bill Gates or Steve Jobs wants you to have it. Can Linux improve? Yes, of cour
Re:Ungrounded Optimism? (Score:2)
As far as X is concerned, I personally have some hope that the eventual modularization of the X system MIGHT help with this. Right now, X is still one gigantic project and therefore (I presume) run by one gigantic virtual committee of developers. If they can manage to modularize it, it might at least reduce the size of the committees to separate groups of people
design by committee (Score:4, Insightful)
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.
Re:Ungrounded Optimism? (Score:3, Insightful)
People have tried that multiple times: Berlin, GNU Step, etc. If you l
Re:Ungrounded Optimism? (Score:3, Insightful)
I agree. I think we're reaching a level of critical mass where the X developers actually are seeing limitations with X on the desktop. Historically, many of the X developers were either embedded guys or server/cross-network guys, and things they found to be problems got fixed rapidly.
Personally I've never had problems with X
Re:Ungrounded Optimism? (Score:5, Insightful)
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.
Re:Ungrounded Optimism? (Score:2, Interesting)
They are both impressive enough, but more importantly, they do things that X simply *cannot* at this time.
I do, however, hope and expect this to change.
Your answer: (Score:2)
Drawing your windows quickly;
Speeding screen updating in power-demanding apps (e.g. video);
Freeing your CPU to concentrate in your programs' data instead of in the screen's eye candy;
Making your screen convey more information about your computer's and your data's status.
Re:Your answer: (Score:3, Insightful)
Seriously, you're absolutely right in that it is about the eye candy. Nothing wrong with that though, although I do wish that everyone would just be honest about it and stop trying to come up with some bogus productivity justification for wanting to have a "shiny" desktop.
If you want to have a plain, utilitarian computing experience then go ahead and stick with the plain-jane window manager and cheap video card; that's fine for you. But don't get on the case of
Re:Ungrounded Optimism? (Score:2, Insightful)
But in the end one main thing it comes down to is using the enormous resources modern graphics cards offer. If you're anything like a geek, at the very least the feeling of only using
A New Respect for X (Score:4, Insightful)
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.
Y'know... (Score:3, Insightful)
This is a very well-written, comprehensive discussion, that I look forward to reading through thoroughly. But I can't help being pessimistic about how this Frankenstein is going to keep adding new pieces without a central authority to enforce a consistent plan.
Re:Y'know... (Score:3, Interesting)
C'mon...alsa/jack for everything!!!
Re:Y'know... (Score:3, Interesting)
It is too big a change to do in the KDE 3 series.
artsd has some good features, it will be a shame to lose them, but it had some problems too. Ones I've notice is a lag on XMMS of a second or 2 when you start a song and sometimes the connect to it would get hosed and XMMS would just say something like "unable to connect" or somesuch generic error and I'd had to restart KDE sometimes.
There are supposedly other technical problems as well.
The big non-technical problem is that the autho
Re:Y'know... (Score:3, Informative)
and that layer will then allow you to select a backend. and one of the will be arts...
but it can be left out.
X is hard to code for! (Score:5, Insightful)
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! (Score:3, Interesting)
My answer is to your question
Why can't a binary driver be accepted?
is that if it would be accepted, it couldn't be part of a "free" operating system anymore.
What most people understand is that you can't have a totally free operative system if it runs on proprietary hardware. You need to set your priorities: do I want a free operative system, or just an alternative to Windows/OSX? In the first case, you _need_ to buy hardware from vendors that com
Re:X is hard to code for! (Score:3, Insightful)
Re:X is hard to code for! (Score:3, Interesting)
It IS the death of Linux. Of course "big buisiness as well as the non technical users (and) my folks" don't get it.
Linux is an Open Source kernel. Meant for experimentation. It grew because Minix wasn't free. And there were hassles with BSD at the time. It only makes sense if it STAYS free.
Then, investigations into other processors, architectures, etc. can take place. By introducing the CONCEPT of a "binary driver",
Re:X is hard to code for! (Score:5, Insightful)
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:X is hard to code for! (Score:3, Interesting)
I guess I'm just dumb, but while I agree that the data can be held closely (it's theirs, after all), I don't understand what the company loses by releasing it. It's not like their competitors can scan the data-sheets and walk down to the chip fab with the design, any more t
Re:X is hard to code for! (Score:4, Insightful)
It's not about making money, it's about not losing money. Specifically, not losing money to lawsuits. Exposing the commands implemented on the chipset may reveal that the hardware manufacturer is using some bit of logic that falls under someone else's patent. By not revealing how you actually talk to the chip, they hope to buy themselves a little safety from the vicious patent land sharks, er, lawyers.
Re:X is hard to code for! (Score:2)
Let me count the ways:
1. Will the manufacturer support every target processor, including compiling with options optimized for each processor in a given family of processors? I doubt it.
2. Will the manufacturer maintain feature and performance parity with Windows drivers? Maybe nVidia does; I'm not aware of anyone else.
3. Will the manufacturer maintain API/ABI compatibility, or continue to support older hardware? ATI's Linux drivers don't even support older Radeons.
I cou
Re:X is hard to code for! (Score:3, Interesting)
Re:X is hard to code for! (Score:3, Informative)
Gentoo (Score:5, Funny)
He must be using Gentoo. *ducks*
Re:Gentoo (Score:3, Funny)
Ducks? Ducks???? It's Penguins!!!!
He missed some things. (Score:2, Troll)
Re:He missed some things. (Score:4, Insightful)
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?
More than X will need fixing (Score:4, Interesting)
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.
Re:More than X will need fixing (Score:5, Interesting)
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:More than X will need fixing (Score:2)
Re:More than X will need fixing (Score:2)
Just Scanning The Comments (Score:2, Insightful)
The computer from Dell... (Score:5, Interesting)
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.
Re:The computer from Dell... (Score:2)
OSS and the last 5% (Score:2)
Why doesn't it get done EVENTUALLY?
What instead happens is people add more features to the 95% as well, and this means more polishing is needed for those features, so they are adding to the 5% that needs to get done as fast or faster than anybody is working on it.
Eventually people abandon the project for a new one or a rewrite or such a majo
Re:The computer from Dell... (Score:2)
That's why I'm fingering MS on this one. Why should Dell pick up MS's slack? They could if they wanted to, true enough - but from their point of view, why should they?
From MS's point of view, why should MS try to fix the problem, when MS thinks that hardware vendors should be dealing with the OS?
What a f***ing mess.
The X-Window system is not about Linux graphics. (Score:5, Interesting)
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:The X-Window system is not about Linux graphics (Score:5, Insightful)
In short: Security, portability, 3D vs. 2D.... (Score:3, Informative)
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.
Flamebait (Score:4, Interesting)
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.
Re:Flamebait (Score:3, Insightful)
The issue of open source 3D drivers is a real one, but I think Jon - like perhaps many of us - have accepted that the solutions to this lie at the political level and not at the
Re:Flamebait (Score:5, Informative)
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.
X Window System is Wikipedia feature, Sep 3rd (Score:4, Informative)
It can be read of here... (Score:2)
It's very funny, even more so when you know just a little bit of Unix and even more than that when you know too much which is to know any, really. ; )
MPEG2 / HD Video Processing? (Score:4, Informative)
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.
Re:XvMC is Non-Functional in MythTV (Score:3, Interesting)
I am currently using it on an X86-64 Gentoo system, with an Nvidia FX5200 card, and their version 7676 binary drivers. I primarily play video through MythTV, though I also use mplayer for some things (both of which support XvMC).
MythTV has infrequent stable/public releases. But, they have very frequent development updates via their svn server. The svn version is usually stable, though sometimes bugs are introduced (as expec
Article errors and misrepresentations (Score:2)
Next, a lot of standard features are referred to as "Linux" features. From the concept of kernel drivers to virtual terminals, these are implied to be Li
Re:Article errors and misrepresentations (Score:2)
If BSD has parallel support to Linux fbdev that will make it easier to run OpenGL/EGL on it. I was also under the impression that all of that PCI probing code was in X because BSD lacked the needed functions.
The focus of the article was the state of Linux graphics but write up some BSD clarifications and I'll add them as soon as we can convince our censorist
Kick It Up A Notch (Score:3, Interesting)
Best article in years. (Score:3)
Re:games? (Score:2)
Re:games? (Score:2)
Re:games? (Score:2, Insightful)
Re:games? (Score:2, Interesting)
Cedega is a mixed bag.Some of my Favorites play great. HalfLife 1 & 2. StarWars Jedi Academy and JK1&2, WoW, GuildWars.
Some of my favorites Don't Play at all. Prince Of Persia, HULK, Legacy of Kain:DEFIANCE...HALO
Always check the wiki before purchasing. http://digital-conquest.ath.cx/wiki/index.php/Main _Page [digital-conquest.ath.cx]
I support TransGaming with a subscription, almost against my better judgement, because I believe those $5 monthly reciepts show a viable market to t
Re:games? (Score:2, Informative)
You can download Cedega for free from the CVS. You can find a tutorial here [linux-gamers.net].
Re:State of the Art Unix Graphics ... (Score:3, Informative)
-Scott
Re:disagree with eye candy (Score:3, Informative)
That is his point, but I don't understand what your objection is. He's not making a theoretical claim, just saying that the reality is that 3D hardware support is better than 2D and the gap will continue to widen.
Also, 3D doesn't necessarily mean a Jurassic Park GUI -- look at Quartz and how it takes advantage of an intrinsically 3D GUI, even if the user is looking at a single plane of overlapping windows.
Re:disagree with eye candy (Score:5, Insightful)
Re:disagree with eye candy (Score:3, Informative)
Go reread the TFA, paying particular attention to a) the first graphic, and b) the 2nd and 3rd sentences in the third paragraph. They are:
I don't think Jon or anyone else is saying 3D is easier than 2D, but 3D is becoming faster than 2D because most (if not all) design energy is being focused on the 3D pipeline. And, since it all ends up getting
Re:disagree with eye candy (Score:2)
Why not? Because video card manufacturers won't release the docs for their videocards, so very few cards have open-source drivers with 3D support.
Making the X server only work on one specific videocard would allow for extensive optimizations, but that isn't practical, just as depending on 3D support isn't currently practical.
Re:disagree with eye candy (Score:2)
There comes a point where an algorithm is as optimized as it can ever be without losing information...the same way it works for compression. After 20yrs if intense development, 2D graphics have reached the point where adding transistors will not speed the process. 3D graphics are exponentially more difficult and require more transistors (and we haven't even f
Re:disagree with eye candy (Score:2, Insightful)
Re:Fantastic Article (Score:3, Insightful)
I've used Linux since late '94, and Linux with X since mid-95... and I'd only ever had the vaguest idea of how the X-ish display systems and subsystems all hung together... until now. It's fantastic to see a detailed and lucid (and, as far as I can tell, fairly thorough) article like this, put together by someone who obviously knows the topic extremely well.
agreed (Score:2)
Re:I wish we had better XKB documentation (Score:3, Interesting)
Re:leave good enough alone (Score:3, Insightful)
X11 has supported OpenGL, transparency, and other modern features for many years. What it hasn't done is support them for regular desktop graphics, but that's because they are a gimmick there. Your desktop doesn't become any more usable or any better for graphics or visualization by having semi-transparent menus or windows that warp. Still, it's a gimmick