Results 1 to 8 of 8

Thread: current state of GEM vs. TTM?

  1. #1

    Default current state of GEM vs. TTM?

    As far as I know, there are two competing graphics memory managers on linux: GEM vs. TTM.

    Around 2008, a great controversy flared in different forums about the merits of respective ones. Judging from the posts, people were more GEMish.

    We are in 2013 now and I just wonder about the results of the controversy. Which one the radeon drivers are using now?

    Judging from my linux source tree, both are included and both are possible with radeon:

    1) We have radeon_gem.c in the folder drivers/gpu/drm/radeon. We also have radeon_ttm.c in the same folder.

    2) We have a huge ttm folder under gpu/drm, compared with only two tiny gem-related files: gpu/drm/drm_gem.c and gpu/drm/drm_gem_cma_helper.c

    3) As far as headers go, there is a huge TTM folder under /include/drm, but the only GEM-related header file there is /include/drm/drm_gem_cma_helper.h. Some gem related header info is also included in drmP.h

    My two questions are:

    1) Can we say that the linux 3.8.6 source tree includes all the source code of TTM and GEM, and hence both are possible with radeon? If so, how do we choose between them? By some compiler options?

    2) It seems that GEM is tiny compared with DRM. Is this correct?

  2. #2
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,540

    Default

    AFAIK both radeon and nouveau essentially use a GEM API wrapped around the TTM memory manager. The actual GEM implementation was OK for IGP products using system memory for graphics, but TTM provided better support for discrete graphics with dedicated high speed video memory.

    Something like that, anyways

  3. #3
    Join Date
    Nov 2007
    Posts
    1,353

    Default

    That was my understanding as well. Basically using a GEM wrapper on top of TTM.

  4. #4

    Default

    Does this mean that radeon first calls GEM, which then calls TTM, and it is TTM code which does the real job?

    Why such a complicated arrangement?

  5. #5
    Join Date
    Dec 2007
    Posts
    2,402

    Default

    Quote Originally Posted by sourcecodereader View Post
    Does this mean that radeon first calls GEM, which then calls TTM, and it is TTM code which does the real job?

    Why such a complicated arrangement?
    It's not that complex. GEM has two parts:

    1. the API
    2. the backend memory manager implementation

    In radeon (and nouveau and just about all the other kms drivers), we use the GEM API, but use TTM as the backend memory manager since the GEM backend does not adequately handle things like vram. You still need a backend regardless of what API you expose to userspace.

  6. #6

    Default

    I think GEM is limited to UMA (unified memory architecture). So, when --and only when-- it needs to deal with VRAM, it calls TTM. Hence it uses only a subset of TTM.

    A question is: If a video card has VRAM, does it still need to access system memory to read/write data? For example, when its VRAM is full, will it start to use system memory? Or, do the graphics cards that have VRAM never use system memory?

    A clearer way to express this question is: Do graphics cards which has VRAM act UMA'ish (hence still need the UMA related part of GEM, in addition to VRAM related part of TTM)?

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

    Default

    Quote Originally Posted by sourcecodereader View Post
    A clearer way to express this question is: Do graphics cards which has VRAM act UMA'ish (hence still need the UMA related part of GEM, in addition to VRAM related part of TTM)?
    Yes and no. GPUs with dedicated VRAM still need to access system memory. Most of the access is reading (command buffers, vertex buffers, textures etc..) but the access is still required. Since buffers do need to move between video and system memory it's generally a lot better to have a single memory manager handling all graphics memory so everything is managed in TTM.

    Quote Originally Posted by sourcecodereader View Post
    I think GEM is limited to UMA (unified memory architecture). So, when --and only when-- it needs to deal with VRAM, it calls TTM. Hence it uses only a subset of TTM.
    Yes, the current GEM implementation is limited to UMA, but I don't think radeon, nouveau etc.. use the "system memory" part of GART at all -- just the API.

    Quote Originally Posted by sourcecodereader View Post
    A question is: If a video card has VRAM, does it still need to access system memory to read/write data? For example, when its VRAM is full, will it start to use system memory? Or, do the graphics cards that have VRAM never use system memory?
    A lot of the buffers consumed by the GPU are only used once (created by the CPU, read by the GPU) then discarded, so they are often created in GPU-accessible system memory (GART) and deleted before they ever make it to the high speed video memory. In other cases, video memory will fill up and less active buffers will need to be moved to GART or system memory.

    There are arguably three areas of memory, not two :

    1. dedicated video memory (or the carved-out equivalent in UMA)

    2. GART memory (blocks of system memory mapped into a contiguous chunk by GPU or chipset hardware)

    3. regular system memory
    Last edited by bridgman; 04-20-2013 at 11:23 AM.

  8. #8
    Join Date
    Dec 2007
    Posts
    2,402

    Default

    Quote Originally Posted by sourcecodereader View Post
    I think GEM is limited to UMA (unified memory architecture). So, when --and only when-- it needs to deal with VRAM, it calls TTM. Hence it uses only a subset of TTM.

    A question is: If a video card has VRAM, does it still need to access system memory to read/write data? For example, when its VRAM is full, will it start to use system memory? Or, do the graphics cards that have VRAM never use system memory?

    A clearer way to express this question is: Do graphics cards which has VRAM act UMA'ish (hence still need the UMA related part of GEM, in addition to VRAM related part of TTM)?
    TTM can handle any type of memory pool. The intel drivers originally used TTM (in fact it was originally designed on Intel hardware). The radeon/nouveau/etc. drivers all use ttm to handle vram and GPU accessible system memory pools (often called GART). Modern GPUs use both VRAM and system memory if available. VRAM has better performance for bandwidth heavy operations, but there are cases were system memory can be more performant (e.g., if the memory has to be accessed by both the CPU and GPU). As I said before there are two parts to GEM: 1. the userspace API (i.e., the interface userspace drivers like the GL driver or the ddx request memory) and 2. the backend part that actually manages the memory pools (vram or system memory, etc.). The radeon drivers use 1. (the API) from GEM, but they use TTM as the actual backend (2.). There is no "UMA part" of GEM per se. It's just that the backend of GEM (2. from above) happens to only be implemented on Intel hw which is UMA. The GEM API (1. from above) is memory type agnostic.

Posting Permissions

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