If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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?

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.

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.

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)?

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.

Originally Posted by sourcecodereader

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.

Originally Posted by sourcecodereader

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)

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.