Intel's Eric Anholt has announced on the dri-devel mailing list that they are getting close to merging GEM to master. There was one last bug hitting the GEM folks but that seems to be worked out and the Intel engineers will proceed to merge GEM to master in all three repositories.GEM, or the Graphics Execution Manager, is a memory-management implementation spawned a month ago by Intel to address the shortcomings of the TTM memory manager, which has been in development and the talk of many X.Org video driver discussions for the past few months...
Ok. I am just a linux user with almost no knowledge in developing, I'm not acknowledged enough to understand the difference in memory managers. So, please don't blame me too much.
From what I read in the article, Intel got bored of waiting Tungsten to fix up TTM and release the first version of that Gallium thing, then, after waiting for an year or so, they developed their own memory manager in just a month and they're ready to deploy it in the next version of their driver and libs. Just the time to dump entirely TTMeries from their driver.
And, by pushing it into the libdrm, looks (IMHO) they're trying to force GEM into xorg as the standard memory manager... and TTM?
The only drivers which 3d part was relying on TTM were Intel and Nouveau. Now Intel dropped TTM, and Nouveau looks stalled (last git entry was 3 weeks ago!). Will it make a sense to continue developing TTM if no one uses it? And if so, does it mean a large portion of nouveau have to be rewritten "the GEM way" and "bye bye Gallium, it has been a very pleasant YEAR together"?
Just one more question: is the worst GPU gonna be the best supported by non-windoze OSes?
TTM didn't leave the devs with much flexibility, GEM allowed them to have more flexibility, and increased performance.
Nouveau just wanted something working, and I think they'll implement TTM, move modesetting to DRM, then maybe replace TTM with GEM, though if they aren't far with TTM, they might just switch to GEM right now...
I think TTM did have its share of technical and performance issues (I don't wholly understand it, but the fencing API seemed really inefficient considering how some hardware is designed), but this quick action seems like Intel is forcing this direction. I read the previous GEM discussion and it seemed to get a little political. While I'd like things to get moving (so we actually see DRI2, kernel modesetting, Gallium, etc.) forcing this isn't the best thing Intel can do right now.
I certainly understand their dev. team's frustration, but in the OSS world you need to be a better team player. I'd love to be wrong and see some non-Intel devs come on this thread and reassure us that this direction is unanimous. However, I have a feeling its not and we're going to loose even more productivity here.