A GEM-ified TTM Manager For Radeon
Phoronix: A GEM-ified TTM Manager For Radeon
Back in May when X.Org developers were voicing concerns about Tungsten's TTM as being the kernel memory manager used for graphics drivers, Keith Packard had unveiled the work Intel had been doing for an alternate kernel memory manager. This memory manager they call GEM, or the Graphics Execution Manager, is a competing solution but it has some advantages such as being simpler to develop drivers around (A Technical Explanation of Intel's GEM)...
GEM == graphics execution manager /* Intel */
TTM == Translation Table Maps // from Tungsten Graphics
XAA == XFree86 Acceleration Architecture
EXA == Extended Acceleration Architecture // This is a guess.
DRI == Direct Rendering Infrastructure
DRI2 == Direct Rendering Infrastructure 2 // Abandoned or delayed?
Why doesn't AMD make up it's own memory manager for X? I'm dreaming at the moment I know, but it's an idea.
The reason AMD doesn't develop its own memory manager is the same reason people were (are) upset when Intel decided to ditch TTM and release GEM into the wild. One of the great things about open source is code reuse. What's the point of having a bunch of different low-level programs that do the same thing?
Ideally everyone would work together so that GEM was graphics card agnostic (which apparently it is), and so that DRI2 is memory manager agnostic, and so that acceleration architectures are memory manager agnostic.
I know, at first that sounds like it runs counter to my first paragraph. It's not so much that I want it so that half-baked projects can be swapped in before another, similar project can reach its potential. It'll just work better in the long run (I think), and will prevent Xorg-wide shake-ups when somebody realizes/decides there's a better way to do things.
IMHO Keith Packard is now some kind of "troll", continuously spawning new projects and pissing at the others work.
Come on man, stop, collaborate and listen!
Well maybe if AMD has some input into GEM then it will help balance the tendency towards Intel only design?
I do feel that X is like an old dinosaur sometimes, and it's not getting much smaller either.
As the Hoff once said: "This is a mess".
@bugmenot et al.: Come on please, don't post flamboyant crap if you're uninformed.
It's not that Keith Packard is some kind of nobody who has a history only in writing Intel IGP hardware drivers - this guy is responsible for SO VERY MANY of X11's state-of-the-art-features that it's really downright irresponsible to accuse him of any such a thing as to deliberately sabotage the work of AMD/ATI's engineers.
He saw TTM not meet the requirements a memory manager for X apparently should (and Keith Packard possibly is the most experienced X-hacker there is, so if someone ought to know, I bet it's him), and developed an alternative that better fit his needs. He did not just rant about shortcomings of TTM, but chose to act, and actually delivered a competing implementation.
I don't know much about gfx hardware, but the way I understand, it does not really differ that much from graphics chip to g. c. how you are supposed to do this, and the architecture of GEM wasn't conceived in a way that limits it to an Intel-only design. It's just a simpler play on a similar theme as TTM, and as far as system programming goes, simple is to be preferred over complex, ever.
I know who he is. That's why I said "now". I appreciate hard work of all open source developers (hence the post) but we're again and again at unstable "state". Just focus on one good idea (system) in each application and make us all happy.
Keith's crime was coming up with a new memory management API which the other devs thought was good enough to justify re-implementing parts of their existing code.
I'm sure there was a bit of "oh crap, if Intel is going this way then we'd better go that way too so we can all stay compatible" feeling but honestly the X devs are a pretty strong-willed lot and I don't think any of them would go along with GEM unless they felt that GEM had something good to offer.
TTM was very important because it provided enough of a common API for the community to implement (there are prototype Intel, Radeon and Nouveau implementations, possibly more) and to build on (DRI2), but after all the implementation work I think there was some general feeling that "this isn't quite right". GEM seems to have come along at the right time and so it received fairly broad support from the developers, even the ones who had just finished working on TTM.
Assuming Keith cares about any of this discussion, he might want to work on his "naming skills". If he had called GEM "TTM Reloaded" everyone would be calling him a hero. Same with UXA -- if he called it "EXA re-implemented over a real memory manager, with a different name so I don't over-write the existing EXA files" everyone would be dancing in the streets.
Last edited by bridgman; 08-26-2008 at 02:37 PM.
I'm just glad Intel has realized how awesome FOSS is. One of these days, microsoft is going to do something dumb and refuse to make it better, and intel will beat them over the head with linux to get their attention.
It will probably involve SSD's and file systems.
It sucks to have everything up in the air all the time, but you know what, the dust /will/ settle, and when it does, we'll have a superior system because of it all. I think this whole thing is awesome actually. Instead of dragging their feet and kind of half heartedly supporting standards, they're jumping into things enthusiastically and making drastic improvements where they see they're needed.
I applaud them for this. --and the radeon folks, I applaud /them/ for this too. Eventually, we should have architectural elegance on the level where we're the easiest OS to make gpu drivers for, hands down.