Intel's GEM Driver Enters Mainline Code

[phoronix]

Phoronix: Intel's GEM Driver Enters Mainline Code

Following concerns regarding the TTM memory manager, Intel had introduced their own kernel memory manager for graphics processors which they have called GEM, or the Graphics Execution Manager (A Technical Explanation of GEM). Intel's GEM is designed to be easier to implement than Tungsten's TTM that had only lived in the limelight for a short time. This switching though from TTM to GEM though has caused a few problems (some technical and some political) within the X.Org community...

http://www.phoronix.com/vr.php?view=NjY0Nw

[dungeon]

I'm not see Intel's brutality like those on X, since AAA's bombarding of my country... And those two are always legal "in the name of God"... wts more.

[puelocesar]

Well, for me the most important is, will my intel laptop be faster next year with GEM? If yes, them I'm ok with that

[bridgman]

I think most of the devs see GEM as a good thing, albeit with extremely unfortunate timing.

It would have been much better if Keith had thought of it two years earlier

[Pickup]

Originally Posted by bridgman

I think most of the devs see GEM as a good thing, albeit with extremely unfortunate timing.

It would have been much better if Keith had thought of it two years earlier

Are you planning to implement GEM in both Ati and RadeonHD drivers soon? and what about fglrx?

[bridgman]

In the open source drivers definitely -- Dave Airlie is already working on it as part of his kernel modesetting work (memory management is a pre-requisite for both kernel modesetting and DRI2) :

http://airlied.livejournal.com/61839.html

For fglrx I expecdt that we would just expose enough of the GEM API to make DRI2 happy and and build that on top of our existing memory manager. Our proprietary driver stack already does the equivalent of redirected direct rendering in Vista and MacOS -- we just don't have the framework support in X/DRI yet so we either need to implement something different and bypass DRI completely or wait for DRI2 to stabilize (IMO it is pretty close).

BTW the "command submission" stuff Dave is talking about is AFAIK primarily related to the fact that when you have a "real" memory manager you don't pass physical addresses around any more -- instead you pass handles and let the memory manager (in the DRM) lock down the buffers and translate handles into physical addresses as the command buffer is being submitted to the chip. This allows the memory manager to move things around (either relocating buffers within their current memory area or moving them between system and video memory) to optimize performance without totally confusing the acceleration code.

This is less of an issue for integrated (UMA) GPUs because everything is in system memory anyways. You still need to deal with relocation and cache coherency but you don't need to worry about buffers migrating between video and system memory.

[VisitorQ]

Actually, I am mainly following this kind of news (intel and graphics drivers) because I have a intel X3100 chipset in my laptop and I want to use both Compiz and OpenGL applications. Right now, this causes flickering unless I use the much slower XGL. This was supposed to be fixed when DRI2 would be implemented. So now, I hope that this GEM thing will still bring me these features in the next year.

I chose an Intel graphics card based on the availability of open source drivers, but I can also see the benefits of using closed source drivers where these features are already implemented. I am not a developer of drivers or Xorg apps, but I do want to support the development of open source apps/drivers, so I'll stick to the intel graphics for now, but I sincerely hope that I can use multiple OpenGL apps in the future

[yoshi314]

i guess that means that there will be no mesa 7.1/new x.org release until gem gets stabilized and most drivers will start using it.

but i guess it's probably well worth the wait.

[NeoBrain]

I think the development of GEM was neccessary in order to finally get real OpenGL 2.0 support in OSS drivers. Without it, we'd still stick with TTM which was overcomplicated and wasn't much used because of that.
However, I am a bit concerned about GEM's performance: How does GEM compare to the binary blobs' memory managers? Is it even possible to reach the same level of perfomance via GEM? No offense regarding OSS development here (especially since Intel controls the development here), but we already had the discussion about the speed advantage of blobs compared to OSS drivers because of patented technologies.

[Regenwald]

really good question, i'm waiting for an answer, too