TTM for developers
Background and Naming
TTM is short for Translation Table Maps which was originally a new DRM map type that could be flipped into and out of a general translation table; for example an AGP or PCI Gart. Since then it has, a bit misleading, become the name of the functionality of the DRM unified memory manager for display memory. A white-paper describing the DRM memory manager can be found here.
Upcoming changes
At the 2007 X.org developers summit at Cambridge, England, there was a TTM BOF during which we agreed on the following changes:
Needed before kernel inclusion
Change |
Description |
Implementor |
Improve memory accounting |
Come up with a better scheme for pinned memory accounting |
TBD |
API changes
Change |
Description |
Implementor |
Validate IOCTL |
Removed, replaced by Validate-submit-fence superIOCTL |
Eric Anholt? |
Fencebuffers IOCTL |
Removed, replaced by Validate-submit-fence superIOCTL |
Eric Anholt? |
Pin / Unpin buffers IOCTL |
Replaces the pin / unpin functionality of the validate IOCTL for both NO_EVICT and NO_MOVE buffers |
Eric Anholt? |
drmBODestroy functionality |
Replace with Unreference, if still needed, rename. |
Thomas Hellström |
Volatile buffer contents |
Add a flag that marks buffer contents as not needed when the buffer's fence has expired. |
Thomas Hellström |
Other important changes and comments
Change / Comment |
Description |
Implementor |
Unfenced list |
Will still be needed, but buffers on it need to be fenced if client dies |
Thomas Hellström |
Synchronization mechanism for multi client mapping of buffers |
Was agreed to not be implemented in DRM. If needed, heavyweight hardware lock can be used for now. |
N/A |
PAT |
Needed to write-combine newer chipsets that can't map the GART address space. |
TG will commit simple implementation to drm_compat.c but more elaborate implementation needed for kernel inclusion |
Separate GPU cache flushing functionality |
Fence functionality needed so we don't need to flush GPU caches on every fence submission. Already implemented as a special fence type for i915 drm, but functionality disabled at this point. Should add description how this works |
Thomas Hellström adds description |
Make evicted pages swappable |
Pages evicted from video memory are still pinned today. Need to fix. See Page swapping below. |
TBD |
Reference SuperIOCTL implementation
A link to a superIOCTL implementation with needed error paths and relocation handling should be added here.
Page swapping
A scheme is required to make graphics pages swappable. Unfortunately there is no way in Linux today for a kernel driver to say to the memory subsystem "Hey, here's a page with contents that will be needed later. Do what you want with it. Just give me a handle to it so I can get it back". The way to handle this in Linux will be to make the client provide a VMA (user-space pointer to a mmapped region) that the memory manager can populate with swappable pages from the client's buffers. Once the page added to the VMA, it can be unpinned by the memory manager, and the memory manager can get it back with get_user_pages(). Meanwhile, the kernel is free to put it in swap-space. If the client mmap() operation is ANONYMOUS, standard swap space will be used. If the client mmap operation is on a file, that file will be used as swap space. It's really up to the client. The memory manager may kill the client(?) if it doesn't provide enough VMA space. It should not really be the responsability of the memory manager to make sure the system has enough swap space.
More stuff
Will be added when time permits.