Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Direct Rendering Manager
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
==== Translation Table Maps ==== ''Translation Table Maps'' (TTM) is the name of the generic memory manager for GPUs that was developed before GEM.{{r|Corbet 2007}}{{r|drmbook-mm}} It was specifically designed to manage the different types of memory that a GPU might access, including dedicated [[Video RAM]] (commonly installed in the video card) and [[main memory|system memory]] accessible through an [[Input–output memory management unit|I/O memory management unit]] called the [[Graphics Address Remapping Table]] (GART).{{r|Corbet 2007}} TTM should also handle the portions of the video RAM that are not directly addressable by the CPU and do it with the best possible performance, considering that user-space graphics applications typically work with large amounts of video data. Another important matter was to maintain the consistency between the different memories and caches involved. The main concept of TTM are the "buffer objects", regions of video memory that at some point must be addressable by the GPU.{{r|Corbet 2007}} When a user-space graphics application wants access to a certain buffer object (usually to fill it with content), TTM may require relocating it to a type of memory addressable by the CPU. Further relocations—or GART mapping operations—could happen when the GPU needs access to a buffer object but it isn't in the GPU's address space yet. Each of these relocation operations must handle any related data and cache-coherency issues.{{r|Corbet 2007}} Another important TTM concept is ''[[Memory barrier|fences]]''. Fences are essentially a mechanism to manage concurrency between the CPU and the GPU.{{r|Corbet 2008}} A fence tracks when a buffer object is no longer used by the GPU, generally to notify any user-space process with access to it.{{r|Corbet 2007}} The fact that TTM tried to manage all kind of memory architectures, including those with and without a dedicated VRAM, in a suitable way, and to provide every conceivable feature in a memory manager for use with any type of hardware, led to an overly complex solution with an API far larger than needed.{{r|Corbet 2008}}{{r|drmbook-mm}} Some DRM developers thought that it wouldn't fit well with any specific driver, especially the API. When GEM emerged as a simpler memory manager, its API was preferred over the TTM one. But some driver developers considered that the approach taken by TTM was more suitable for discrete video cards with dedicated video memory and IOMMUs, so they decided to use TTM internally, while exposing their buffer objects as GEM objects and thus supporting the GEM API.{{r|Larabel 2008 gem-ttm}} Examples of current drivers using TTM as an internal memory manager but providing a GEM API are the radeon driver for AMD video cards and the [[nouveau (software)|nouveau]] driver for NVIDIA video cards.
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)