Spring is coming. I'm certain of it because I know for a fact that it's not Spring right now and seasons have a tendency to wrap around. Obviously that means I need to work a bit on the acceleration code for X11. It's just like going to a doctor, sure, it sucks, but at the back of your mind you know you need to do it.
So what's different about this code? Well, it's not an acceleration architecture. We're reusing Exa. It's the implementation.
Currently if you want to accelerate X11, or more precisely Xrender, you implement some acceleration architecture in your X11 driver. It may be Exa, Uxa, Xaa or something else (surely also with an X and A in the name because that seems to be a requirement here). Xrender is a bit too complicated for any 2D engine out there, which means that any code which accelerates Xrender will use the same paths OpenGL acceleration does. In turn this means that if we had an interface which exposed how hardware works we could put OpenGL and Xrender acceleration on top of the same driver. One driver, accelerating multiple APIs.
That's exactly what Gallium is all about so it shouldn't be a big surprise that this is what we're doing. We're simply writing an Xorg state tracker for Gallium in which Exa is implemented through the Gallium interface.
So with a Gallium driver, besides OpenGL, OpenGL ES and OpenVG you'll get X11 acceleration. I'm specifically saying here X11 because after implementing Exa we'll move to accelerating Xv, which will give us a nice set of ops which are accelerated in a typical X application.
21 comments:
arent you allowed to undress at the docter?
Is this in any way related to previously mentioned xf86-video-modesetting driver?
How does this fit with Intel's vision to not support EXA at all, but only UXA?
@anonymous 1: depends on the doctor. dentists make it difficult.
@Roger: yes, xf86-video-modesetting essentially became the the Xorg state tracker.
@anonymous 2: It doesn't relate. Exa does everything we need and there's just no benefit to UXA from the Gallium state tracker perspective.
Hey that's great news, if you're ever up in Edinburgh I'll buy you a pint
On the EXA / UXA issue I thought it was the same API but implemented using GEM to make it more efficient
I'm guessing if the Xorg tracker is using the gallium drivers they'll automatically use TTM or GEM anyway.
Am I right?
Following FireBurn's comment, how does Gallium relate to TTM and GEM?
Awesome, I guess. But having just upgraded from Debian Lenny KDE 3.5 to Debian Squeeze KDE 4.2 I realize I don't want acceleration I want buffering. And not the kind of buffering that was promised for Qt 4 to make the solid window dragging as smooth as Mac OS 8. No, I want static image buffering of contents of windows and menus I may click on in VRAM, as I am looking at an empty grey square for a second as I close a menu. Yes, I'm on such a slow computer that I turned off animated scrolling in konqueror to make it snappy.
Yes, perhaps I should get a faster computer even though videos play fine and complain that the Nokia N900 is a slow old cow and that 'we' realy want a 2000 dollar KDE phone. But no, I would rather have a passive video card with 8 GB of 'slow' VRAM which contains prerenders of all the menus and a perhaps even double rendering of window contents, half a pixel down, so I can have smooth scrolling better then the nineties. It would scroll as smooth as PAL-tv. Is it not awesome how readably smooth a newsticker can be compared to X on linux to make stutter free text pass by.
(A new computer would end up the same; instead of stuttering my mp3 while i browse, it would stutter my video streaming while browsing without adblocking. I know Debian has a fair sceduler, fairly interupting everything as things get maxed out. In fact Debian features cooperative multitasking, as I was shown the other day; my mouse pointer was locked in a copy drag operation even as i switched desktops, but as I switched sessions everything was fine, yet the other session remains deadlocked even as i can move the mouse to another window it remains locked in its previous task, that is effectively the same as coopertative multitasking of the nineties, here today on linux.)
Anyway I'm not blaming you, I'm just ranting. I just want big buffering, can you do PNG compression on the fly and have like everything buffered in VRAM? I have given up on a responsive system, having a limited budget and a big pipe means I will forever be maxed out by people who want to impress people who have a faster machine then me. I just want a snappy no motion system with prerendered 3D or SVG card games which actually move bitmaps or pngs arround. Oh KDE games I love you. Wait this should be an ode to Zack, please give me some PNG buffering and kick some X people straight with your smarts.
Someone direly needs to write a Great Big Glossary Of Newfangled Graphics Awesomeness. Methinks.
As far as I understand things:
- Gallium3D is a driver architecture which basically lets you write a driver for a given piece of hardware once, and, in theory, it'll automatically accelerate all of the APIs ("state trackers") and operating/windowing systems ("winsys") for which support has also been added to Gallium3D. So rather than writing X*Y*Z drivers -- one for each combination of hardware, OS, and API -- you only have to write X+Y+Z (if you think of the state trackers and winsyses as sort of drivers for the APIs and OSes). It also makes writing the drivers easier by abstracting graphics hardware in a nicer way.
- TTM is a memory manager for graphics cards written by Tungsten Graphics. A memory manager is a necessary prerequisite to making Gallium work (but also has benefits on its own, afaik).
- GEM is a memory manager for Intel graphics cards written by Intel because they thought TTM was too complicated. GEM has been merged into the Linux kernel.
- Some drivers expose the GEM API but implement it internally using TTM.
- EXA is an acceleration API for X which accelerates the difficult compositing of stuff but not the trivial simple things like drawing lines.
- UXA does what EXA does but in a different GEM-related way than EXA which I forget.
And then there's KMS and DRI2 and DRM and DDX and all the rest...
Zack: What happens when multiple state trackers make use of the driver/hardware at the same time? I assume things have been designed to handle that nicely?
And then a year later comes Google with their super fast and lightweight Chrome OS on top of DirectFB and everyone dumps X and its extensions industry for DirectFB.
It is a good time to be Linux user, wit news like this =)
@FireBurn: right, correct. The winsys part of Gallium is responsible for handling that and it can use any memory manager.
@Mike: It doesn't really relate - it simply requires a memory manager, be it GEM, TTM or something else.
@Anonymous: Technically both Qt and modern X do that. Qt4 has what's called a window surface - a pixmap for the entire window, which is simply being blitted. While X does the same for every top-level if the Composite extension is used. So it's a bit hard to say what's the problem for you.
@Illissius: They use different contexts. Gallium works in a multi-threaded, multiple-contexts environment. It's just that on Linux we don't schedule them that nicely, but that will come too.
@cl333r: See, now you should get a doctor to look at that - you seem to be talking out of your ass.
@Anonymous: Your mouse locks up in a drag-and-drop operation because of how stuff like that is implemented.
As far as I know, when you start dragging, the mouse is acquired exclusively by the application beginning the drag. (I could be wrong)
It's the input-handling equivalent of cooperative multitasking. (You were correct in equating the two)
The simplest workaround is to set either AllowDeactivateGrabs or AllowClosedownGrabs in the ServerFlags section of your xorg.conf and then hit the key combo when you find yourself in that situation. (See the xorg.conf(5) manpage for details)
They're only not enabled by default because it allows unauthorized users to bypass screensaver/locker apps unless they use a specially-written API.
Two question:
1) I'm specifically saying here X11 because after implementing Exa we'll move to accelerating Xv, which will give us a nice set of ops which are accelerated in a typical X application.
What about the G3DVL layer already available in mesa? Why another implementation?
2) Why not dropping EXA and modify Xorg to directly use the Gallium language? I.e.:
doing now: Standard Xorg <- EXA language -> Xorg state tracker <- Gallium language -> Gallium driver
proposed: Modified Xorg <- Gallium language -> Gallium driver
Could this be implemented? Could dropping the EXA layer give better performance and/or eliminate (eventual) EXA limitation?
@Fabio: The first question doesn't follow from the quote at all so I can't answer it. Now if you had asked "will you use g3dvl?" that would a) make sense, b) allow me to answer with something along the lines "after implementing exa, i'll look at the options and will make a decision. if i can reduce the amount of code i need to write by reusing g3dvl, then that's what will happen".
The second question: currently it'd simply be a marginal win (if at all) that wouldn't be worth the work required to get it.
When does it work ?
Yes, I have to agree the release readiness question is relevant at this point ;)
@bestouff and Remm: yes, there is a hard set schedule. Exa acceleration has to be usable in three weeks (so by about 18th). Xv four weeks after that (by about 16th next month). Then it's a question of whether you have a Gallium driver and if not how long will it take to write one for your card, unfortunately I can't answer that question.
Wow .. an X11 project with a hard set schedule ! Refreshingly good to hear.
Thanks a lot Zack.
@Zack. I had to smile when I read cl333r rambling about some hypothetic GoogleOS based on DirectFB. I'm using that, right now. DirectFB i mean, not that Googlething ;-) It was a mess to get right, in some ways it stays messy, but in my opinion it was worth it. Because I side with the other Anonymous here, regarding new systems. Pentium III@933 Mhz, 512 MB Ram, i815 Chipsetgraphics with additional 4MB VRAM/TextureRam/SideportMemory nowadays in the AGP-Slot.
Would this also work with Wayland?
If I wanted to test gallium, what graphics card should I buy? What works the best with kwin composite + KDE?
Post a Comment