Weekly Edition
Return to the Development page
| |||||||||||||
|
| |||||||||||||
Packard on the state of Linux graphics
Keith Packard has posted an extensive summary of the state of the art in Linux graphics support and where things are going in the future. "In moving towards our eventual goal of a KMS/GEM/DRI2 world, weve felt obligated to avoid removing options until that goal worked best for as many people as possible. So, instead of forcing people to switch to brand new code that hasnt been entirely stable or fast, weve tried to make sure that each release of the driver has at least continued to work with the older options.
However, some of the changes weve made have caused performance regressions in these older options, which doesnt exactly make people happy the old code runs slow, and the new code isnt quite ready for prime time in all situations. One option here would be to stop shipping code and sit around working on the perfect driver, to be released soon after the heat-death of the universe."
(Log in to post comments)
Packard on the state of Linux graphics Posted Apr 25, 2009 18:10 UTC (Sat) by kragil (guest, #34373) [Link]
Very interesting and it is good to see what the future will bring.
_But_ it is kind of sad to see Linux products released with broken parts. I think Linux will only be ready for everyones desktop once these kind of major breakage scenarios only happen in development releases for dedicated testers, not general users.
Packard on the state of Linux graphics Posted Apr 25, 2009 18:34 UTC (Sat) by drag (subscriber, #31333) [Link]
This is a total restructuring of Linux and how it handles displays. Total restructuring.
It's taking stagnet and obsolete design that is stuck in the 1980's and getting it competitive with the latest and greatest that any other display system has to offer. And not only just for accelerating GUIs...
efforts to take advantage of those high speed floating point co-processors for general Linux programming is tied into it. Currently it's impossible for Linux folks to take full advantage of their hardware processing power using fully open source means.
Basically all if this would take much too long to accomplish without the assistance of the distributions and user base. Users are free to use systems like CentOS/Redhat/Debian Stable if they don't want to run into problems on production machines.
Packard on the state of Linux graphics Posted Apr 25, 2009 19:21 UTC (Sat) by kragil (guest, #34373) [Link]
Run into _this_specific_ problem.
Debian and CentOS have different problems attached to them.
Packard on the state of Linux graphics Posted Apr 27, 2009 1:58 UTC (Mon) by dag- (subscriber, #30207) [Link]
Debian stable seems a better pick right now, because it is newer than CentOS-5. This in itself is temporary, until CentOS-6 is released within the next 10 months and then CentOS-6 will be for some time newer than Debian Stable.
On the other hand, Debian Stable only gets security updates until one year after the next Debian Stable. Which effectively means you have to upgrade in that one year. Which is vastly different than with CentOS, where you know in advance you can run it with security updates up to 7 years after General Availability. For CentOS-5 that means until 2014 ! For Debian Stable it is hard to tell, you only know it exactly one year in advance :-D
It could be in 18 months, if Debian is able to follow a strict release schedule. Or it could be in another 3 or 4 years ? In both cases it is worse than what CentOS offers, even if that means that you get something older than Debian Stable at *this* moment in time.
Packard on the state of Linux graphics Posted Apr 27, 2009 2:11 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
debian stable gets security updates far more frequently than once a year.
Packard on the state of Linux graphics Posted Apr 27, 2009 2:29 UTC (Mon) by dag- (subscriber, #30207) [Link]
That is not what I said.
I said that you won't get any security updates one year after the next Debian Stable release. So you are forced to upgrade to the newer Debian Stable in that one year, and you do not know in advance when that is going to be.
Packard on the state of Linux graphics Posted Apr 27, 2009 14:45 UTC (Mon) by sbergman27 (subscriber, #10767) [Link]
Since Novell first released their X server on an X server, XGL, and introduced "The Cube", I've been hearing that the ultimate "solution for everything" was for the X server to just do everything, 2d and 3d, in OpenGL. Do these changes get us there? Or is there further restructuring needed for that? Or is that goal not really the desired destination?
Packard on the state of Linux graphics Posted Apr 27, 2009 17:31 UTC (Mon) by slougi (guest, #58033) [Link]
Xgl was really a hack - the implementation that was initially demonstrated piggy backed on another X server.
The idea is still to take advantage of the 3d support of modern cards, but not directly through OpenGL for application developers. Instead, applications are generally expected to use X Render. Internally in the drivers, this might be accelerated with the same hardware that drives the 3d engine on graphics cards. In the general case that we are transitioning to, rendering happens to off-screen surfaces, which the compositing manager (kwin, compiz etc) then draws on the screen. This way you get the nice cube bling effects.
Gallium3D (http://en.wikipedia.org/wiki/Gallium3D) will provide a uniform framework in which to develop drivers, hopefully making the above more stable and performant in the future.
The above already matches and exceeds in flexibility other current systems like OS X and Vista in regards to plain rendering. Another big piece is XRandR support, which allows for adding and removing screens on the fly. Basically, you have a big root window, which is a parent to all other windows. When you add a screen the root window is resized, and each screen displays a part of the root window. This allows for things like cloned output on certain screens (just output the same region of the root window) and arbitrary placement of screen positions in regard to each other (screen 1 is left of screen 2 and down 60 pixels).
Maybe, just maybe given some time (a year or two on intel hardware is my estimate...) I will be able to add a new screen without the X server crashing, my apps freaking out, or the kernel panicking... Looking forward to it. I think the approach is sane and has a good chance of working once it stabilizes. It's about time.
Packard on the state of Linux graphics Posted Apr 27, 2009 19:31 UTC (Mon) by drag (subscriber, #31333) [Link]
Ya.. I originally thought the pure OpenGL environment would of been the way to go, but there are a couple problems with going pure-OGL server.
1. Doing 2D graphic acceleration for applications on OpenGL is more difficult/irritating then originally thought. EXA was developed as a replacement for XAA and is actually able to run quite well on 3D hardware.
2. OpenGL is only designed for a application API. There is nothing in the standard for managing displays, video memory, etc. Mode setting and whatnot is actually VERY VERY hard to get right.
Then people realized also that they will want to use the GPU for other tasks like OpenCL, shader languages, video acceleration, codec acceleration, etc.
So the thoughts went from "OpenGL for everything" to extending the existing DRI protocol used by OpenGL to allow drivers that support multiple APIs (gallium) then putting a unified memory management scheme and mode setting into the kernel.
Packard on the state of Linux graphics Posted Apr 25, 2009 18:48 UTC (Sat) by wingo (subscriber, #26929) [Link]
I motion to consider all uses of the phrase "ready for the desktop" to be intended as humorous.
Packard on the state of Linux graphics Posted Apr 27, 2009 22:08 UTC (Mon) by liljencrantz (subscriber, #28458) [Link]
They already are.
Packard on the state of Linux graphics Posted Apr 27, 2009 0:25 UTC (Mon) by iabervon (subscriber, #722) [Link]
The audience for releases of these packages is dedicated testers and distributions trying to decide whether it's time to distribute them yet. And the distributors just need to make sure that none of the broken combinations will end up on people's systems, which is what they're always making sure of.
Packard on the state of Linux graphics Posted Apr 25, 2009 18:18 UTC (Sat) by al451 (guest, #58271) [Link]
Keith's summary is not about Linux graphics in general, it's specifically about X on Intel hardware...
Packard on the state of Linux graphics Posted Apr 25, 2009 18:27 UTC (Sat) by drag (subscriber, #31333) [Link]
No it's not.
Intel drivers are leading the way, but as other projects progress they will match the same drive model. It's the goal for all of X.org stuff.
Packard on the state of Linux graphics Posted Apr 25, 2009 18:47 UTC (Sat) by nix (subscriber, #2304) [Link]
Well, I hope that DRI1 et al don't get ripped out of X until the major
drivers have got DRI2 and some GEM alternative in place.
(Actually, I'm sure that'll happen, even though Keith made it sound like
I'm not sure if there are any drivers left for which XAA is still
Packard on the state of Linux graphics Posted Apr 25, 2009 19:32 UTC (Sat) by drag (subscriber, #31333) [Link]
Hrmm.. Define 'major'.
The open source Nvidia drivers going forward are Nouveau and those are designed from the ground up to be all Gallium-enabled, so that required DRI2.
The open source ATI drivers I am not sure about the status off exactly, but they certainly been working on GEM compatibility.. I think they got a bit sidetracked with the TTM-to-GEM transition, but they've been working with the DRI2 development early on.
Then, of course, Intel is leading the pack with their improvements.
I a took a look at what was going on on OpenChrome mailing lists and I found this that they were working on a pretty-much new Mesa driver to work with DRI2 and the unified memory management scheme.
So it looks like all of them are more or less well on their way to transitioning to the new model.
So that probably cover 98-99% of users with video cards capable of some sort of real opengl performance that have support of open source drivers.
Packard on the state of Linux graphics Posted Apr 25, 2009 20:37 UTC (Sat) by nix (subscriber, #2304) [Link]
You pretty much covered the majors, I'd say. (I know one person with an S3
but this is on a nine-year-old machine, which even I would say is not really worth targetting in new code!)
(Mind you, I've just bought a machine with an Aspeed AST2050 card, which
The worry I had was that GEM was supposed to be designed around the needs
Packard on the state of Linux graphics Posted Apr 26, 2009 1:52 UTC (Sun) by dberkholz (subscriber, #23346) [Link]
xf86-video-ast doesn't work on that one yet? The ChangeLog claims it does.
Packard on the state of Linux graphics Posted Apr 26, 2009 14:30 UTC (Sun) by nix (subscriber, #2304) [Link]
I'd never even heard of xf86-video-ast: google didn't find it, and I
overlooked it in the enormous cgit.freedesktop.org output (also, 'ast' means 'Tanenbaum' to me: it's a pretty useless abbreviation for 'aspeed').
I'll give it a try (but the machine hasn't arrived yet, and there is no
Packard on the state of Linux graphics Posted Apr 26, 2009 14:33 UTC (Sun) by nix (subscriber, #2304) [Link]
Definitely counts as 'not a major': changes implemented by gigantic code
drops from some other repository, no EXA support...
Packard on the state of Linux graphics Posted Apr 26, 2009 17:04 UTC (Sun) by tzafrir (subscriber, #11501) [Link]
I believe that S3 is basically what you ave now in recent crappy sis boards. Sadly I inherited one such system. Well, it's good enough to show a console or X with lots of xterms.
BTW: what about graphics chipset(s?) included in popular ARM/MIPS SoC?
Packard on the state of Linux graphics Posted Apr 26, 2009 19:40 UTC (Sun) by drag (subscriber, #31333) [Link]
The only one that I am really aware of that has real OpenGL acceleration for Linux would be the ones included in such devices like the Dell Mini-12* and OMAP3 plaform.
*The Mini-12 uses a variant of the 'full embedded' Atom processor + Atom-oriented chipset that Intel and friends intended for the MID/handheld market. Typically Atom-based netbooks/laptops (like the mini-9) use older Intel laptop-oriented chipsets like the 915g or 945g and the chipset uses more energy then the actual cpu.
These use the PowerVR SGX core.
Now for the Dell Mini-12 and other Atom-based systems Intel provides the proprietary Poulsbo OpenGL driver (along with OSS DRM and 2D driver).
I don't know about the OMAP3 stuff...
Now if you looked at Tungsten graphic's documentation for Gallium they mentioned PowerVR with pretty much every other sentance. I don't know the status of any of that stuff, though. Especially since Tungstan graphics has been bought out by Vmware.
Packard on the state of Linux graphics Posted May 14, 2009 10:25 UTC (Thu) by robbe (subscriber, #16131) [Link]
> Mind you, I've just bought a machine with an Aspeed AST2050 card,
This is a glorified frame buffer (typically) inside the service processor
A lot of serious servers come with something equivalent. As its main use
Packard on the state of Linux graphics Posted May 14, 2009 20:41 UTC (Thu) by nix (subscriber, #2304) [Link]
Ah! I was wondering if this was in some way related to the
apparently-undocumented 'iKVM' feature (comes with really annoying ungoogleable name identical save for case to that of major Java package). Apparently it is.
(I'll see if it's documented in the motherboard manual when the machine
Packard on the state of Linux graphics Posted Apr 27, 2009 7:53 UTC (Mon) by ppedroni (subscriber, #6592) [Link]
> I'm not sure if there are any drivers left for which XAA is still
> preferred over EXA, though: is XAA in the X server core going to stay > around for long?)
Ati binary driver, AFAIK (I haven't used that in a long time, but when I
Getting rid of the bits of architecture Intel didn't design Posted Apr 25, 2009 23:23 UTC (Sat) by jensend (guest, #1385) [Link]
I'm not on top of all the details, but it seems to me that Intel has dominated the decision-making, and in some of these areas I wonder whether the architecture is too specific to their needs (last year's GEM v TTM article discussed this a little). I wish other vendors could be brought on board in a more meaningful way- even the fglrx and nvidia closed driver teams could make some contributions to building a better infrastructure. I also wonder to what extent some of this is making other Unices into second-class citizens or worse.
Getting rid of the bits of architecture Intel didn't design Posted Apr 26, 2009 3:07 UTC (Sun) by drag (subscriber, #31333) [Link]
Well....
There are two areas that the 'next gen' driver model can be ported to other operating systems..
1. The other OS can choose to impliment support for the DRI2 protocol and do kernel-level memory management that provides support for GEM-like objects. Then take care of mode setting in some way that doesn't depend on X DDX drivers (since that is hopefully going away in the long-term. About 50% of the code for X.org drivers is just to deal with mode setting.)
2. The other OS can target Gallium directly and create their own 'winsys' portion of the driver. (or whatever they now call the bottom layer of the Gallium design stack)
The bonuses that come with the new unified driver design is better memory management and much simplier driver model. Also for security it makes it possible to allow Xfree-style X server to run as a regular user.
I think that FreeBSD already has some support for DRI2 somewere with their own memory management scheme and OpenBSD folks should be interested in allowing users to get hardware acceleration without compromising security.
Windows and OS X could be taken care of by porting Gallium to their native acceleration APIs and get compatibility with the Linux-style display stack.
-------
All in all this sort of thing is just a plain better design long-term.
Remember that with Windows Vista one of their big deals was to impliment a in-kernel video memory management system and shove the rest of the driver back into userspace.
Also according to ATI's proprietary drivers developers they have already moved to this sort of driver model, internal to the driver, some time ago. (For Windows and then later on for Linux) And, I expect, the same for Nvidia proprietary driver prior to ATI's.
In this way Linux open source graphics is just catching up with the rest of the world and this sort of model is going to be required to take better advantage of things like Intel Larrabee, the ATI GPGPU stuff, as well as OpenCT and manageable hardware acceleration for video decoding. (although I think that Linux's OSS graphics stack has such wonderful potentional since it's using a open and standardized approach.. were as with things like Nvidia's CUDA is very vendor, very hardware specific.)
Getting rid of the bits of architecture Intel didn't design Posted Apr 26, 2009 16:59 UTC (Sun) by wilreichert (subscriber, #17680) [Link]
Intel is driving the decisions here because they're the ones paying salary to xorg developers. Sure AMD is releasing hardware specs, but how many full time open source xorg develpers have they hired to work on their hardware support? None that I'm aware of, its the distros like Redhat & SUSE doing it for them. That said, I think the Intel paid developers are considering the needs of the other video cards when these APIs are created, no one will benefit if this stuff only works on one brand of card.
Getting rid of the bits of architecture Intel didn't design Posted Apr 27, 2009 4:01 UTC (Mon) by airlied (subscriber, #9104) [Link]
that would be 3 full-time AMD open source developers.
They are mainly concentrating on getting initial working 3D code for the current batch of chips at least useable before going ahead with getting the other bits.
Getting rid of the bits of architecture Intel didn't design Posted Apr 27, 2009 4:36 UTC (Mon) by wilreichert (subscriber, #17680) [Link]
Excellent, I'm thrilled to be wrong here. Perhaps its a problem of perception then - one doesn't see too many @amd.com emails on the xorg / mesa mailing lists.
Packard on the state of Linux graphics Posted Apr 26, 2009 1:38 UTC (Sun) by obi (subscriber, #5784) [Link]
This all sounds like great stuff, and it all seems to make sense for the intel driver. I've got a couple reservations though:
- as other people mentioned, the intel guys seem to be doing their own thing for their own needs, without much regard for other hardware platforms (I guess they're a business after all). The way GEM was introduced (and subsequently added to the kernel) forced the others to rethink their memory management strategy (TTM -> GEM-on-TTM). UXA seems to be an intel-only thing ATM, and the original plans to generalize it seem to have been abandoned. The intel guys also don't seem to like Gallium3D very much; admittedly it's probably an unnecessary abstraction for one driver, but the point is to share as much code/cost/burden as possible, across different drivers. At least on KMS and DRI2 it seems there's a consensus, more or less.
- I'm also wondering what will happen with older kernels with newer userspace. Will 2D work without KMS or DRM? It could make transitions harder (upgrading distros, "impossible" combinations of xserver, x driver, kernel) etc.
In the end, my impression of keithp is that he often 'just does it' instead of trying to discuss it to death (xorg git transition f.e.); he's very likely right most of the time. I just hope he can still recognize when he's wrong, or when 'the greater good' (i.e. the greater xorg ecosystem) should take precedence over short term progress of the intel driver.
Packard on the state of Linux graphics Posted Apr 26, 2009 3:23 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]
Intel is employing these developers to gain a market advantage by leading in development. It creates more pressure for other vendors to step up. ATI did to some extend. Nvidia didn't yet. Other operating systems are going to lag behind if they don't step up either.
Packard on the state of Linux graphics Posted Apr 26, 2009 12:30 UTC (Sun) by mjr (subscriber, #6979) [Link]
As for generalisation of UXA, AFAIK it's basically EXA for GPUs that don't have dedicated video RAM. This is largely (though certainly not exclusively) Intel, and not much use for discrete graphics cards with their own RAM.
So EXA really isn't going away in favor of UXA any time soon anyway.
Packard on the state of Linux graphics Posted Apr 26, 2009 14:39 UTC (Sun) by nix (subscriber, #2304) [Link]
Doesn't no-dedicated-video-RAM do horrible things to performance anyway?
The memory bandwidth requirements of a modern video card must be enormous...
Packard on the state of Linux graphics Posted Apr 27, 2009 5:23 UTC (Mon) by JoeBuck (subscriber, #2330) [Link] I'm sure AMD/ATI will be integrating the graphics and CPU more heavily soon, leaving nVidia the odd man out. Moore's Law and all ...
Packard on the state of Linux graphics Posted Apr 27, 2009 12:52 UTC (Mon) by drag (subscriber, #31333) [Link]
Well...
UXA originally was intended to be a bit of a experiment on Intel's part. Just to see how well GEM can be be used. What UXA is is implimenting the EXA API on top of GEM objects.
The idea was once they got the basics going then they would port their changes back to the "EXA" portion Xorg DDX drivers. However they found out that the vast majority of the EXA drivers was not needed and that it was actually much easier for them to write new code for UXA then it was to try to make the old EXA drivers work.
==============
To say that UXA is 'just for video devices with no shared ram' is actually kinda misleading. UXA is a Intel thing and all Intel IGPs use the main memory... however the model of running EXA API on top of GEM (probably through Gallium state-tracker; or porting EXA to use kernel memory management like Intel originally intended) is something that all video card drivers will probably do.
There are a couple reasons why this is misleading...
* The EXA driver in the Xorg DDX uses it's own private memory management scheme and textures objects that are incompatible with those required for OpenGL.
So right now if you want to have composited desktop and want to have full 2D and 3D accelleration you need to:
Something like that. So that is pretty inefficient and with a discrete GPU with dedicted RAM it may mean moving textures back and forth over the PCI Express bus.
So with the UXA mode of doing things the data is written out to GEM-based memory objects that can be used directly by the OpenGL drivers. Much more efficient. And as you can imagine that with dedicated video RAM avoiding trips back to he CPU is more critical then with the Intel IGP.
* As the driver's capabilities increase it will be able to be used in lots of different manners. You will never really have enough video ram for all tasks, like you can't really have enough main memory for all situations. So video cards are going to take advantage of 'stealing' main memory time to time.
You should be able to eventually use something like LLVM JIT to take advantage of OpenCT on your GPU, be able to use GSLS shaders for programming, be able to use VDPAU for decoding acceleration, and other such things.
When you start to use the video card for more general purpose stuff then you'll never really have enough dedicated video memory to do everyhing you want to do. Even running a basic composited desktop ends up using massive amounts of vram to hold all the application windows textures, if you have a crapload of Windows opens. With that you'd still need to be able to juggle between the needs of the desktop rendering with OpenGL application and games as well as video playback.
For example, imagine if your a scientist that is programming a physics simulation and want to use a python program that not only uses OpenGL for the scientify visualization, but uses C modules built to take advantage of OpenCT to do real time data analysis. Or whatever. Huge amounts of number crunching, multiple different APIs accessing the same card, etc.
Even just for games people are start going to use the GPU in multiple different ways simultaniously. Physics acceleration, AI stuff, raytracing, OpenGL, etc.
So your going to need a way to efficiently and effectively manage swaping video ram out of the video card and into main memory and stuff like that.
So, I beleive, that moden video cards are setup with the idea that you are going to use a combination of both main memory AND dedicated memory. It's, at least, been true for a while that low-end and medium-end discrete graphics cards depend on the driver's ability 'steal' main memory to even function properly on a complex desktop. (like have 64MB of dedicated vRAM, but it's expandable up to 1GB)
Having the memory management done in-kernel and having it unified is critical to making that work very efficiently, especially when your going to have a much more diverse amount of GPU workloads.
-------------------
This is just my understanding of the situation and could be off by several magnitudes of reality. So don't be suprised if I got lots of stuff wrong.
Packard on the state of Linux graphics Posted Apr 27, 2009 13:02 UTC (Mon) by drag (subscriber, #31333) [Link]
Oh, and shoving all the memory management into the Linux kernel means that you can heavily leverage the efficient and time-tested code developed for handling application virtual memory requirements. This is very nice...
Packard on the state of Linux graphics Posted Apr 27, 2009 19:12 UTC (Mon) by drag (subscriber, #31333) [Link]
Sorry. Substitute 'openct' with 'opencl'. That's what I get for posting too early in the morning.
Packard on the state of Linux graphics Posted Apr 28, 2009 19:14 UTC (Tue) by bersl2 (guest, #34928) [Link]
Also s/GSLS/GLSL/ I presume.
Packard on the state of Linux graphics Posted Apr 27, 2009 9:09 UTC (Mon) by rvfh (subscriber, #31018) [Link]
Nope, from the article:
"UXA simply skips the parts of EXA which are not necessary in a GEM world."
Packard on the state of Linux graphics Posted Apr 27, 2009 11:22 UTC (Mon) by mjr (subscriber, #6979) [Link]
Was this comment spurred by further knowledge than a simplified description in the article?
Packard on the state of Linux graphics Posted Apr 27, 2009 13:59 UTC (Mon) by makomk (guest, #51493) [Link]
If you read the rest of the blog post, what he really means is that UXA
skips the migration of pixmaps between video card RAM and main memory, since for Intel cards they're pretty much the same thing. In fact, GEM as a whole only really works for Intel integrated graphics. (This is why it's such a headache for everyone else.)
Packard on the state of Linux graphics Posted Apr 27, 2009 14:27 UTC (Mon) by quanxian.wang (guest, #52086) [Link]
Hi, Keith
What is the big difference between GEM and TTM? 1) performance? 2) openGL? 3) overdesign?
Thanks
Packard on the state of Linux graphics Posted Apr 26, 2009 6:39 UTC (Sun) by muwlgr (guest, #35359) [Link]
I would better like to know how to prevent my X server from entering into SIGALRM loop with my Mobile GM965/GL960 IGC and Kubuntu 9.04.
Have to wait for Karmic 9.10, it seems.
Packard on the state of Linux graphics Posted Apr 26, 2009 12:47 UTC (Sun) by ssam (subscriber, #46587) [Link]
you could try your luck with these.
https://lists.ubuntu.com/archives/ubuntu-x/2009-April/000...
also see http://ubuntulinuxtipstricks.blogspot.com/2009/04/jaunty-...
Packard on the state of Linux graphics Posted Apr 26, 2009 19:07 UTC (Sun) by sbergman27 (subscriber, #10767) [Link]
Just a wild guess, but I've heard of lockups and slow downs with UXA. In those cases, EXA has worked better. Check your /var/log/Xorg.0.log and see what you are using. It should say something like:
(==) intel(0): Using EXA for acceleration
Packard on the state of Linux graphics Posted Apr 26, 2009 7:34 UTC (Sun) by petegn (guest, #847) [Link]
I wish someone would put a nuke up ATI's backside it is absolute junk right now that is if it even installs at all .
If it was possible rip the ATI junk out of my laptop and install and Nvidia graphics system i would but i am stuck with ATI Junk and am sick of their junk .
Packard on the state of Linux graphics Posted Apr 26, 2009 14:38 UTC (Sun) by nix (subscriber, #2304) [Link]
Without saying which card it is this is, well, as useless as anything
we've come to expect from you.
ATI produce a *lot* of different cards. Some have excellent free support.
Which it is depends on what card you've got (oh, and also what version of
Packard on the state of Linux graphics Posted Apr 27, 2009 7:04 UTC (Mon) by petegn (guest, #847) [Link]
>Without saying which card it is this is, well, as useless as anything
>we've come to expect from you.
Wonder which one of the factory list numbies this is
If you think you know who i am then you obviously know what machine i have it,s graphics adaptor and the versions of fglrx i have tried but for those that genuinely dont know the machine is a Compaq Presario V5030 AMD Turion 64 CPU ATI M200 mobility graphics Opensue 11.1 with the latest (supplied by suse) version of X KDE 4.2.2(ish) 1.0 Gb ram video ram 128Mb(max allowed by bios) .
Most of this information is so widely spread about on the net and i am not the only one that has these problems , Just one of the more vocal people when it comes to getting it sorted and when people start getting snotty and sarcastic they get it bounced straight back at them electronically or face to face it does not bother me at all .
Pete .
Packard on the state of Linux graphics Posted Apr 27, 2009 8:35 UTC (Mon) by k3ninho (subscriber, #50375) [Link]
I don't know SuSE, and you don't say which driver you're using. Are you using the ATI 'fglrx' binary driver, or the open xserver-xorg-ati one? And what's the PCI Id for the card -- it seems possible that the driver doesn't correctly recognise the thing. Does the VESA driver work -- even if at a galatial pace?
Packard on the state of Linux graphics Posted Apr 27, 2009 15:22 UTC (Mon) by ttonino (subscriber, #4073) [Link]
The M200 in the RS480/RS482 chip set worked okay for me with fglrx (though scrolling was slowish on a composited desktop and no xv support).
Since Ubuntu 8.10 the free driver is installed and this works well.
Packard on the state of Linux graphics Posted Apr 27, 2009 15:38 UTC (Mon) by Kit (guest, #55925) [Link]
>ATI M200 mobility graphics
This is a pretty stinking low end card, even as far as mobile graphics cards go (OEMs *love* giving you good processor/ram and then a PATHETIC video card). I had a laptop from the same era as the M200 (but with the 'high end' equivalent) and its performance made the PREVIOUS laptop's graphics card look blazing fast by comparison; the best you can hope for is 'okay' 2D performance and maybe, MAYBE (if you're insanely lucky) basic compositing. I'd say completely ignore the FGLRX (it just adds pain, and generally crashes) and go with the generic radeon driver.
Unless you're okay with basically just VESA level performance, I'd say to NEVER, EVER go with the entry level graphics card (ATI or nVidia, can't comment on Intel since that's really their primary target), can't really fault ATI for the card being so low end (although you can for their FGLRX driver sucking so hard, but then they could have easily just not even bothered with a driver at all... so I'm just gonna go with 'fglrx sucks horribly, but huzzah for releasing specs and working with the community now').
Packard on the state of Linux graphics Posted Apr 27, 2009 16:55 UTC (Mon) by petegn (guest, #847) [Link]
Yes i am now using the standard radeon driver it's not the best of things but works unlike fglrx but having said that the laptop was previously running opensuse 10.3 and it was ok on that but 11.1 Hummmm and 11.0 is not much better . i did think of canning opensuse but i now know the system fairly well so a change would be a real pain just hoping they get 11.2 right for release B4 it is released this time
think it is definately new laptop as soon as funds allow with decent Nvidia graphics
Packard on the state of Linux graphics Posted Apr 27, 2009 23:53 UTC (Mon) by nix (subscriber, #2304) [Link]
If you want decent graphics that doesn't crash, *avoid* nvidia. Everyone
else shares info at least and development time at best with the community, so over time driver support gets *better*; with nvidia, over time driver support gets *worse*, and in the end they drop support for your card and you're shagged (upgrade your kernel *or* have an insecure kernel and working video).
Packard on the state of Linux graphics Posted Apr 28, 2009 2:14 UTC (Tue) by foom (subscriber, #14868) [Link] I agree that it pretty much sucks, but Debian at least packages multiple versions of the nvidia drivers, thus managing to keep users from being totally screwed if they have old hardware.
Packard on the state of Linux graphics Posted Apr 28, 2009 6:08 UTC (Tue) by drag (subscriber, #31333) [Link]
It depends on what you want.
I think that overal the Intel driver is going to provide better stability and better long-term support. Not right now... but if your using something like Debian stable which uses the pre-GEM stuff.. or Fedora 11 which will use the post-GEM stuff.. then it'll be better.
The ATI stuff will provide better long-term support also. The open source OpenGL drivers still work fine with R200 era hardware... which is something that can't be said with proprietary Nvidia drivers which only do support for hardware sold in the last few years and shoves the rest into 'legacy' mode were your using older drivers until they no longer work with modern Linux systems.
However if you want/need to have good top range 3D performance and good compatibility for games and applications then Nvidia is still tops. Nvidia places a very high priority on performance for their drivers and it's obvious that game developers and application developers using Linux and targetting Linux all prefer the Nvidia proprietary drivers. So it's very common to run into situations were games and applications are tested against nothing but proprietary drivers and Nvidia's proprietary OpenGL stack.
So you end up with Nvidia-isms and bugs that happen in the open source OpenGL stack go unnoticed and unfixed. It's often a frustrating experience for people relying on OSS drivers to have to go and tweak settings on their apps in order to get some sort of combination that does not cause software fallbacks or crashes or other such negative things.
There have been a couple times in the past were I've personally run into situations were developers have simply given up trying to get their stuff working well on in a pure-OSS environment. It's not that they were all ra-ra proprietary softwre or anything like that... they were generally real swear-to-god open source developers, but it's just that the combination of low quality, spotty OpenGL support, and lack of demand among end users just left getting stuff working well a low priority. I don't blame them for having that attitude. I've ran into problems related to that in both open source ATI and open source Intel drivers.
A recent example of this is going to be the YoFranky game from the Blender project.
In Fedora 10, using the Intel GMA drivers for the 965 chipset, I couldn't even play the silly thing due to the lackluster OpenGL suppport.. it wasn't that the performance wasn't decent in benchmarks and such (Fedora 10 had the fastest OpenGL in terms of raw performance that I've ran into)it's just that it wasn't compatible with a lot of applications. In many ways Fedora 11 beta offers worse performance, but the stability and compatiblity has improved to the point were I don't have to worry about running most OpenGL applications and games. Now if I disable shaders in the game I can play it on medium quality decent enough... It's still not as pleasent as it should be.
I think that right now a lot of people are complaining about Intel performance and drivers and such.. not becuase there was a sudden drop off in quality (without a doubt the current transition is a rought spot), but that the quality has reached a point were people are beginning to depend on them and now are desiring to have higher quality.
Packard on the state of Linux graphics Posted Apr 28, 2009 23:49 UTC (Tue) by petegn (guest, #847) [Link]
Never had a moments problems with Nvidia at all they always just work as they should have always installed as they should except for one instance and that did not take much to put right a quick soft link and working like a champ Unlike every ATI video card i have come across has been a complete DOG .
No you can keep the ATI stuff I'll have Nvidia any day it is just a crying shame AMD wasted so much money on a 2 bit graphics chip maker like ATI they would have been far far far better off aquireing Nvidia
Packard on the state of Linux graphics Posted Apr 26, 2009 15:17 UTC (Sun) by arekm (subscriber, #4846) [Link]
Hopefully now some nasty bugs (like lockups) will be fixed instead of focusing purely on new features:
https://bugs.freedesktop.org/show_bug.cgi?id=intel-2d-rel... https://bugs.freedesktop.org/show_bug.cgi?id=intel-3d-rel...
Packard on the state of Linux graphics Posted Apr 26, 2009 22:29 UTC (Sun) by Kit (guest, #55925) [Link]
Good news:
>Right now, we continue to spend all of our time stabilizing the code and fixing bugs.
Back to the kernel Posted Apr 27, 2009 16:58 UTC (Mon) by mikov (subscriber, #33179) [Link]
Am I the only one who thinks that moving all that stuff in the kernel is potentially a step back and a mistake ? We need less stuff in the kernel, not more. Don't we all remember the complaints and discussions when Microsoft moved GDI to the kernel in NT 4.0?
Graphics drivers are immensely complex. I have been fortunate to work with the proprietary driver code of some of the major graphics manufacturers. Believe me, you do not want that stuff in your kernel. It is not that it is badly written (as any commercial software, it has its ups and downs), but it is so complex that I would never trust it to work completely reliably.
Putting it into the kernel means that the entire system is not reliable.
Unlike a file system, the graphics code doesn't have complex inter-relations with the rest of the kernel, so technically speaking there is no strict requirement why it should be there.
The part about displaying kernel messages on the screen which has already been initialized by X seems like a cop out to me.
Back to the kernel Posted Apr 27, 2009 17:02 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
this isn't putting the entire graphics engine in the kernel, only the portions for setting the mode on the hardware.
this needs to be in the kernel so that you can have multiple software packages (one of which being the kernel) accessing the same hardware.
Back to the kernel Posted Apr 27, 2009 17:28 UTC (Mon) by mikov (subscriber, #33179) [Link]
I have to disagree. First, it is not only the mode setting that goes into the kernel. And mode setting is really the last thing that needs to be there. You certainly do not have multiple applications trying to set different modes _at the same time_.
The kernel and X also never access the hardware at the same time. Designing the whole architecture so that the kernel can display an oops message when it crashes is absurd.
The thing about handing monitor hot-plug interrupts is also a red herring. For one, you hardly need extremely low latency for that, so polling once every 200ms in user mode would probably be sufficient. Even if you wanted to do it with an interrupt, there is no need for everything else to be in the kernel - handle the interrupt in the kernel and notify user mode.
Low latency interactions between DMA and interrupt handling do need to be in the kernel, however graphics drivers rarely have those.
So, I am aware of some of the arguments used to justify this, and I don't find them entirely convincing. There are clearly some advantages (especially if you have multiple 3D apps), but I am surprised that everybody is accepting this as if it is the only possible and clearly superior solution.
There is the unfortunate tendency of trying to put stuff in the kernel, simply because the kernel is the only common part that can be relied on to be in every Linux system. Take mode settings. If you had a user mode daemon doing it, it would work equally well. However, will every distribution take it up? Who will maintain it and in what repository? So, the problem is at least partly political/organizational and that really worries me. Can there be another UDEV?
Back to the kernel Posted Apr 27, 2009 17:33 UTC (Mon) by mikov (subscriber, #33179) [Link]
Forgot to mention that uvesafb/v86d is a better approach to all this.
Back to the kernel Posted Apr 27, 2009 17:57 UTC (Mon) by slougi (guest, #58033) [Link]
> it is not only the mode setting that goes into the kernel.
If you mean the memory management parts, as some have pointed out above there are reasons for that, like OpenCL for example.
> The kernel and X also never access the hardware at the same time. Designing the whole architecture so that the kernel can display an oops message when it crashes is absurd.
It's not just about displaying oops messages. You get other benefits, like no flickering on boot up when X starts. You finally get frame buffers in the kernel that do not conflict with X. You get safe and flicker free switching between virtual terminals and between multiple sessions when several users are logged in on the same machine.
> The thing about handing monitor hot-plug interrupts is also a red herring. For one, you hardly need extremely low latency for that, so polling once every 200ms in user mode would probably be sufficient. Even if you wanted to do it with an interrupt, there is no need for everything else to be in the kernel - handle the interrupt in the kernel and notify user mode.
Unfortunately, there are many chips that blank screens when you poll for outputs.
Back to the kernel Posted Apr 27, 2009 23:59 UTC (Mon) by nix (subscriber, #2304) [Link]
Indeed. I'm frankly scared to switch to virtual terminals when X is
running, because of the number of times it's locked up solid, frozen the console beyond repair, or 'merely' led to huge numbers of running X apps deciding to explode on return to X.
Bring on kernel modesetting!
Back to the kernel Posted Apr 27, 2009 18:02 UTC (Mon) by elanthis (subscriber, #6227) [Link]
"I have to disagree. First, it is not only the mode setting that goes into the kernel."
The memory management makes a lot of sense, too -- nobody is asking for a userspace virtual-memory subsystem, and the graphics memory space is just as complex and in need of kernel maangement these days as system RAM. Nothing else is going into the kernel that hasn't already been there for many years.
"Designing the whole architecture so that the kernel can display an oops message when it crashes is absurd."
That is not the point of KMS at all, only a side benefit that some people think is neat.
The point of KMS is that the kernel can reset the graphics mode at any time if need be, and those times happen often enough to be important. When X crashes for example, which in the current architecture often requires a power cycle to get your display working again. Or take suspend/resume, where trying to coordinate with userspace processes is really hard and still after all these years of suspend/resume work fails pretty damn often for quite a few people.
"For one, you hardly need extremely low latency for that, so polling once every 200ms in user mode would probably be sufficient."
Except that that blows nuts for laptops (and low-power desktops) where we're trying to reduce and/or eliminate polling entirely so the CPU can spend most of its time in a low-power state. Hotplug is most attractive to laptop users, too. If my laptop is just sitting there showing a static screen (say I'm reading a page) I don't want it waking up the CPU at all if it can be helped. Battery life is possibly the single most important thing for many people with laptops... a laptop with no charge is just a big paperweight if you don't have a power outlet nearby, which is pretty often for travelers and even students.
"Take mode settings. If you had a user mode daemon doing it, it would work equally well."
Except for suspend/resume where any kind of userspace synchronization is a whore.
If you want a microkernel approach, there are plenty of OSes out there for you to comfortably use. Linux is not and never has been one of them, and things move into the kernel in the Linux world when the advantages for doing so are clear and the disadvantages can only be summed up as "some people don't like it on principle because they're afraid of code in kernel space."
Back to the kernel Posted Apr 27, 2009 18:40 UTC (Mon) by jsbarnes (subscriber, #4096) [Link]
> I have to disagree. First, it is not only the mode setting that goes
> into the kernel. And mode setting is really the last thing that needs to > be there. You certainly do not have multiple applications trying to set > different modes _at the same time_.
No, but that's not the issue. You can search around and look for the
Simply saying that "The kernel and X also never access the hardware at the
And your comment about polling for display changes doesn't account for
As for uvesafb/v86d I can't imagine why you'd want to depend on that
So overall I think you're ignoring a number of real issues with the
Back to the kernel Posted Apr 27, 2009 20:00 UTC (Mon) by mikov (subscriber, #33179) [Link]
Well, those are good points. Undoubtedly, there is a certain elegance to doing things in the kernel, and it is very convenient. Even though kernel code is _risky_ it is also easy - you can do whatever you want in a straight-forward manner, maintain shared state and synchronization between processes for free, etc.
I am mostly concerned about the first part - the "riskiness". Adding more code to the kernel invariably will mean more bugs. Graphics code is very complex (at least the one I have worked with).
Fundamentally, putting stuff in the kernel offers only two true benefits: ability to maintain cheap shared state, and the ability to force changes to distributions in a centralized manner. (The latter is sad but true). Any other benefits are incidental.
So, if it is not terribly complex or inefficient, it makes sense to move code out of the kernel, when possible.
Of course it is absolutely impossible with some kinds of code - network and disk drivers, file systems, etc. However there are also other kinds, like USB, where user mode drivers are possible and even desirable. Graphics is somewhere between.
Back to the kernel Posted Apr 27, 2009 20:13 UTC (Mon) by jsbarnes (subscriber, #4096) [Link]
Yes it is a complex subsystem, but wherever the code is it will be
complex, and could hang your machine. So keeping it out of the kernel on stability grounds doesn't hold much water. (How many times has X frozen a machine even though it lives totally in userspace?)
Also you may have misunderstood my "centralized" item: putting output
You're right about graphics being an oddball though: certain bits of it
More generally, there's a dogma out there that says "if it can be done
Back to the kernel Posted Apr 27, 2009 21:59 UTC (Mon) by drag (subscriber, #31333) [Link]
Well... Think about this:
The Xorg DDX driver stuff... that had direct access to memory regions and would twiddle bits on the PCI bus, configure the hardware and things like that. Like you had it, at least partially, configuring the AGP ports and whatnot.
All of this was happenning, more or less, outside of the control of the Linux kernel and it was up to the Linux kernel, when dealing with your console or OpenGL graphics, to do what it can to avoid stepping on your Xserver's toes. If the Linux kernel or Xserver goofed up and had some sort of conflict then it would quite possibly hard lock your machine due to crashing the PC hardware.
It's rare, but a few times I've been using Linux and hte screen has gone all rainbow bright, and the lights started blinking, and the speakers started blaring static. This is not a pleasent experience.
The Xserver.. that's also a lot of code to have running around running as setuid root under your user's control. And besides the security implications involved with that... Depending on the acceleration method used by applications like Firefox you had a more-or-less direct code path from HTML/Javascript code being rendered --> Xserver --> you hardware.
Also X11 is a networking protocol. So when your running your system in the traditional X terminal mode your allowing a program that has direct access to your hardware to have network access.
So ya the Xserver and Xorg's drivers are technically 'userspace' and that is nice, but it's not really something that is hugely better then just shoving _everything_ into the kernel.
By moving the modesetting into the kernel (which is essentially low-level hardware configuration anyways...) and memory management (which Linux is good at and you can leverage the existing code for application virtual memory management) you can eliminate X's requirement to run as root, eliminate direct from your Xserver to your hardware, reduce the complexity and code redundancy in the Xorg drivers, and still have the the OpenGL stack and EXA-related stuff (except for video memory management) all happenning in userspace through a unified kernel interface.
Back to the kernel Posted Apr 28, 2009 15:17 UTC (Tue) by lkundrak (subscriber, #43452) [Link]
> For one, you hardly need extremely low latency for that, so polling once every 200ms in user mode would probably be sufficient.
Excuse me? Does that mean 5 wakeups a second?
Back to the kernel Posted Apr 28, 2009 10:09 UTC (Tue) by Quazatron (subscriber, #4368) [Link]
The kernel is supposed to be the bit of software that manages hardware so that applications don't have to.
It always struck me as very odd that X, being an app (a special app, but still an app) had to muck around with hardware registers, and could even bring the system down when thing went wrong.
This seems a much nicer design, with the kernel concerned with the hardware and the X concerned with drawing stuff on the screen.
Back to the kernel Posted Apr 28, 2009 16:37 UTC (Tue) by mikov (subscriber, #33179) [Link]
Well, the kernel being the only bit of software that manages the hardware is just dogma. You do it when it makes sense, and don't do it when it doesn't.
I am not saying that it doesn't in this case, but it is not as clear cut as people seem to thing. For one, drawing sometimes requires talking directly to the hardware. Not every graphics chip has a DMA command queue in system RAM, and even even for the ones that do, it is not always the best solution.
The command queue could be a FIFO in the chip. So, in some cases X has to talk to the hardware in order to draw. If we insist the kernel to be the only one touching the hardware, we have to make a kernel mode transition for every drawing command, which is not ideal.
Packard on the state of Linux graphics Posted Apr 30, 2009 8:41 UTC (Thu) by oak (guest, #2786) [Link]
> Objects in graphics memory are drawn fastest with the GPU
...but application doing (or X server splitting some other operation to)
Packard on the state of Linux graphics Posted May 4, 2009 13:35 UTC (Mon) by jlokier (subscriber, #52227) [Link]
This was reported a few weeks ago, when someone wanted to disable the flashing cursor in consoles because of the power drain from waking the GPU. The CPU can draw a flash cursor quite efficiently, and in the old days it did...
|
|
||||||||||||