Results 1 to 10 of 10

Thread: Intel's GEM Driver Enters Mainline Code

  1. #1
    Join Date
    Jan 2007
    Posts
    15,130

    Default Intel's GEM Driver Enters Mainline Code

    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

  2. #2
    Join Date
    Feb 2008
    Posts
    1,083

    Default

    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.

  3. #3
    Join Date
    Jun 2008
    Posts
    61

    Default

    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

  4. #4
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,514

    Default

    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

  5. #5
    Join Date
    Mar 2008
    Location
    The Alps
    Posts
    42

    Default

    Quote Originally Posted by bridgman View Post
    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?

  6. #6
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,514

    Default

    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.
    Last edited by bridgman; 08-09-2008 at 12:49 PM.

  7. #7
    Join Date
    Aug 2008
    Posts
    2

    Default

    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

  8. #8
    Join Date
    Sep 2006
    Location
    PL
    Posts
    912

    Default

    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.

  9. #9
    Join Date
    Dec 2007
    Location
    Germany
    Posts
    365

    Default

    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.

  10. #10
    Join Date
    Jun 2007
    Posts
    145

    Default

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •