diff options
Diffstat (limited to 'linux-core/drm-gem.txt')
| -rw-r--r-- | linux-core/drm-gem.txt | 805 |
1 files changed, 0 insertions, 805 deletions
diff --git a/linux-core/drm-gem.txt b/linux-core/drm-gem.txt deleted file mode 100644 index 5cda87f8..00000000 --- a/linux-core/drm-gem.txt +++ /dev/null @@ -1,805 +0,0 @@ - The Graphics Execution Manager - Part of the Direct Rendering Manager - ============================== - - Keith Packard <keithp@keithp.com> - Eric Anholt <eric@anholt.net> - 2008-5-9 - -Contents: - - 1. GEM Overview - 2. API overview and conventions - 3. Object Creation/Destruction - 4. Reading/writing contents - 5. Mapping objects to userspace - 6. Memory Domains - 7. Execution (Intel specific) - 8. Other misc Intel-specific functions - -1. Graphics Execution Manager Overview - -Gem is designed to manage graphics memory, control access to the graphics -device execution context and handle the essentially NUMA environment unique -to modern graphics hardware. Gem allows multiple applications to share -graphics device resources without the need to constantly reload the entire -graphics card. Data may be shared between multiple applications with gem -ensuring that the correct memory synchronization occurs. - -Graphics data can consume arbitrary amounts of memory, with 3D applications -constructing ever larger sets of textures and vertices. With graphics cards -memory space growing larger every year, and graphics APIs growing more -complex, we can no longer insist that each application save a complete copy -of their graphics state so that the card can be re-initialized from user -space at each context switch. Ensuring that graphics data remains persistent -across context switches allows applications significant new functionality -while also improving performance for existing APIs. - -Modern linux desktops include significant 3D rendering as a fundemental -component of the desktop image construction process. 2D and 3D applications -paint their content to offscreen storage and the central 'compositing -manager' constructs the final screen image from those window contents. This -means that pixel image data from these applications must move within reach -of the compositing manager and used as source operands for screen image -rendering operations. - -Gem provides simple mechanisms to manage graphics data and control execution -flow within the linux operating system. Using many existing kernel -subsystems, it does this with a modest amount of code. - -2. API Overview and Conventions - -All APIs here are defined in terms of ioctls appplied to the DRM file -descriptor. To create and manipulate objects, an application must be -'authorized' using the DRI or DRI2 protocols with the X server. To relax -that, we will need to implement some better access control mechanisms within -the hardware portion of the driver to prevent inappropriate -cross-application data access. - -Any DRM driver which does not support GEM will return -ENODEV for all of -these ioctls. Invalid object handles return -EINVAL. Invalid object names -return -ENOENT. Other errors are as documented in the specific API below. - -To avoid the need to translate ioctl contents on mixed-size systems (with -32-bit user space running on a 64-bit kernel), the ioctl data structures -contain explicitly sized objects, using 64-bits for all size and pointer -data and 32-bits for identifiers. In addition, the 64-bit objects are all -carefully aligned on 64-bit boundaries. Because of this, all pointers in the -ioctl data structures are passed as uint64_t values. Suitable casts will -be necessary. - -One significant operation which is explicitly left out of this API is object -locking. Applications are expected to perform locking of shared objects -outside of the GEM api. This kind of locking is not necessary to safely -manipulate the graphics engine, and with multiple objects interacting in -unknown ways, per-object locking would likely introduce all kinds of -lock-order issues. Punting this to the application seems like the only -sensible plan. Given that DRM already offers a global lock on the hardware, -this doesn't change the current situation. - -3. Object Creation and Destruction - -Gem provides explicit memory management primitives. System pages are -allocated when the object is created, either as the fundemental storage for -hardware where system memory is used by the graphics processor directly, or -as backing store for graphics-processor resident memory. - -Objects are referenced from user space using handles. These are, for all -intents and purposes, equivalent to file descriptors. We could simply use -file descriptors were it not for the small limit (1024) of file descriptors -available to applications, and for the fact that the X server (a rather -significant user of this API) uses 'select' and has a limited maximum file -descriptor for that operation. Given the ability to allocate more file -descriptors, and given the ability to place these 'higher' in the file -descriptor space, we'd love to simply use file descriptors. - -Objects may be published with a name so that other applications can access -them. The name remains valid as long as the object exists. Right now, our -DRI APIs use 32-bit integer names, so that's what we expose here - - A. Creation - - struct drm_gem_create { - /** - * Requested size for the object. - * - * The (page-aligned) allocated size for the object - * will be returned. - */ - uint64_t size; - /** - * Returned handle for the object. - * - * Object handles are nonzero. - */ - uint32_t handle; - uint32_t pad; - }; - - /* usage */ - create.size = 16384; - ret = ioctl (fd, DRM_IOCTL_GEM_CREATE, &create); - if (ret == 0) - return create.handle; - - Note that the size is rounded up to a page boundary, and that - the rounded-up size is returned in 'size'. No name is assigned to - this object, making it local to this process. - - If insufficient memory is availabe, -ENOMEM will be returned. - - B. Closing - - struct drm_gem_close { - /** Handle of the object to be closed. */ - uint32_t handle; - uint32_t pad; - }; - - - /* usage */ - close.handle = <handle>; - ret = ioctl (fd, DRM_IOCTL_GEM_CLOSE, &close); - - This call makes the specified handle invalid, and if no other - applications are using the object, any necessary graphics hardware - synchronization is performed and the resources used by the object - released. - - C. Naming - - struct drm_gem_flink { - /** Handle for the object being named */ - uint32_t handle; - - /** Returned global name */ - uint32_t name; - }; - - /* usage */ - flink.handle = <handle>; - ret = ioctl (fd, DRM_IOCTL_GEM_FLINK, &flink); - if (ret == 0) - return flink.name; - - Flink creates a name for the object and returns it to the - application. This name can be used by other applications to gain - access to the same object. - - D. Opening by name - - struct drm_gem_open { - /** Name of object being opened */ - uint32_t name; - - /** Returned handle for the object */ - uint32_t handle; - - /** Returned size of the object */ - uint64_t size; - }; - - /* usage */ - open.name = <name>; - ret = ioctl (fd, DRM_IOCTL_GEM_OPEN, &open); - if (ret == 0) { - *sizep = open.size; - return open.handle; - } - - Open accesses an existing object and returns a handle for it. If the - object doesn't exist, -ENOENT is returned. The size of the object is - also returned. This handle has all the same capabilities as the - handle used to create the object. In particular, the object is not - destroyed until all handles are closed. - -4. Basic read/write operations - -By default, gem objects are not mapped to the applications address space, -getting data in and out of them is done with I/O operations instead. This -allows the data to reside in otherwise unmapped pages, including pages in -video memory on an attached discrete graphics card. In addition, using -explicit I/O operations allows better control over cache contents, as -graphics devices are generally not cache coherent with the CPU, mapping -pages used for graphics into an application address space requires the use -of expensive cache flushing operations. Providing direct control over -graphics data access ensures that data are handled in the most efficient -possible fashion. - - A. Reading - - struct drm_gem_pread { - /** Handle for the object being read. */ - uint32_t handle; - uint32_t pad; - /** Offset into the object to read from */ - uint64_t offset; - /** Length of data to read */ - uint64_t size; - /** Pointer to write the data into. */ - uint64_t data_ptr; /* void * */ - }; - - This copies data into the specified object at the specified - position. Any necessary graphics device synchronization and - flushing will be done automatically. - - struct drm_gem_pwrite { - /** Handle for the object being written to. */ - uint32_t handle; - uint32_t pad; - /** Offset into the object to write to */ - uint64_t offset; - /** Length of data to write */ - uint64_t size; - /** Pointer to read the data from. */ - uint64_t data_ptr; /* void * */ - }; - - This copies data out of the specified object into the - waiting user memory. Again, device synchronization will - be handled by the kernel to ensure user space sees a - consistent view of the graphics device. - -5. Mapping objects to user space - -For most objects, reading/writing is the preferred interaction mode. -However, when the CPU is involved in rendering to cover deficiencies in -hardware support for particular operations, the CPU will want to directly -access the relevant objects. - -Because mmap is fairly heavyweight, we allow applications to retain maps to -objects persistently and then update how they're using the memory through a -separate interface. Applications which fail to use this separate interface -may exhibit unpredictable behaviour as memory consistency will not be -preserved. - - A. Mapping - - struct drm_gem_mmap { - /** Handle for the object being mapped. */ - uint32_t handle; - uint32_t pad; - /** Offset in the object to map. */ - uint64_t offset; - /** - * Length of data to map. - * - * The value will be page-aligned. - */ - uint64_t size; - /** Returned pointer the data was mapped at */ - uint64_t addr_ptr; /* void * */ - }; - - /* usage */ - mmap.handle = <handle>; - mmap.offset = <offset>; - mmap.size = <size>; - ret = ioctl (fd, DRM_IOCTL_GEM_MMAP, &mmap); - if (ret == 0) - return (void *) (uintptr_t) mmap.addr_ptr; - - - B. Unmapping - - munmap (addr, length); - - Nothing strange here, just use the normal munmap syscall. - -6. Memory Domains - -Graphics devices remain a strong bastion of non cache-coherent memory. As a -result, accessing data through one functional unit will end up loading that -cache with data which then needs to be manually synchronized when that data -is used with another functional unit. - -Tracking where data are resident is done by identifying how functional units -deal with caches. Each cache is labeled as a separate memory domain. Then, -each sequence of operations is expected to load data into various read -domains and leave data in at most one write domain. Gem tracks the read and -write memory domains of each object and performs the necessary -synchronization operations when objects move from one domain set to another. - -For example, if operation 'A' constructs an image that is immediately used -by operation 'B', then when the read domain for 'B' is not the same as the -write domain for 'A', then the write domain must be flushed, and the read -domain invalidated. If these two operations are both executed in the same -command queue, then the flush operation can go inbetween them in the same -queue, avoiding any kind of CPU-based synchronization and leaving the GPU to -do the work itself. - -6.1 Memory Domains (GPU-independent) - - * DRM_GEM_DOMAIN_CPU. - - Objects in this domain are using caches which are connected to the CPU. - Moving objects from non-CPU domains into the CPU domain can involve waiting - for the GPU to finish with operations using this object. Moving objects - from this domain to a GPU domain can involve flushing CPU caches and chipset - buffers. - -6.1 GPU-independent memory domain ioctl - -This ioctl is independent of the GPU in use. So far, no use other than -synchronizing objects to the CPU domain have been found; if that turns out -to be generally true, this ioctl may be simplified further. - - A. Explicit domain control - - struct drm_gem_set_domain { - /** Handle for the object */ - uint32_t handle; - - /** New read domains */ - uint32_t read_domains; - - /** New write domain */ - uint32_t write_domain; - }; - - /* usage */ - set_domain.handle = <handle>; - set_domain.read_domains = <read_domains>; - set_domain.write_domain = <write_domain>; - ret = ioctl (fd, DRM_IOCTL_GEM_SET_DOMAIN, &set_domain); - - When the application wants to explicitly manage memory domains for - an object, it can use this function. Usually, this is only used - when the application wants to synchronize object contents between - the GPU and CPU-based application rendering. In that case, - the <read_domains> would be set to DRM_GEM_DOMAIN_CPU, and if the - application were going to write to the object, the <write_domain> - would also be set to DRM_GEM_DOMAIN_CPU. After the call, gem - guarantees that all previous rendering operations involving this - object are complete. The application is then free to access the - object through the address returned by the mmap call. Afterwards, - when the application again uses the object through the GPU, any - necessary CPU flushing will occur and the object will be correctly - synchronized with the GPU. - - Note that this synchronization is not required for any accesses - going through the driver itself. The pread, pwrite and execbuffer - ioctls all perform the necessary domain management internally. - Explicit synchronization is only necessary when accessing the object - through the mmap'd address. - -7. Execution (Intel specific) - -Managing the command buffers is inherently chip-specific, so the core of gem -doesn't have any intrinsic functions. Rather, execution is left to the -device-specific portions of the driver. - -The Intel DRM_I915_GEM_EXECBUFFER ioctl takes a list of gem objects, all of -which are mapped to the graphics device. The last object in the list is the -command buffer. - -7.1. Relocations - -Command buffers often refer to other objects, and to allow the kernel driver -to move objects around, a sequence of relocations is associated with each -object. Device-specific relocation operations are used to place the -target-object relative value into the object. - -The Intel driver has a single relocation type: - - struct drm_i915_gem_relocation_entry { - /** - * Handle of the buffer being pointed to by this - * relocation entry. - * - * It's appealing to make this be an index into the - * mm_validate_entry list to refer to the buffer, - * but this allows the driver to create a relocation - * list for state buffers and not re-write it per - * exec using the buffer. - */ - uint32_t target_handle; - - /** - * Value to be added to the offset of the target - * buffer to make up the relocation entry. - */ - uint32_t delta; - - /** - * Offset in the buffer the relocation entry will be - * written into - */ - uint64_t offset; - - /** - * Offset value of the target buffer that the - * relocation entry was last written as. - * - * If the buffer has the same offset as last time, we - * can skip syncing and writing the relocation. This - * value is written back out by the execbuffer ioctl - * when the relocation is written. - */ - uint64_t presumed_offset; - - /** - * Target memory domains read by this operation. - */ - uint32_t read_domains; - - /* - * Target memory domains written by this operation. - * - * Note that only one domain may be written by the - * whole execbuffer operation, so that where there are - * conflicts, the application will get -EINVAL back. - */ - uint32_t write_domain; - }; - - 'target_handle', the handle to the target object. This object must - be one of the objects listed in the execbuffer request or - bad things will happen. The kernel doesn't check for this. - - 'offset' is where, in the source object, the relocation data - are written. Each relocation value is a 32-bit value consisting - of the location of the target object in the GPU memory space plus - the 'delta' value included in the relocation. - - 'presumed_offset' is where user-space believes the target object - lies in GPU memory space. If this value matches where the object - actually is, then no relocation data are written, the kernel - assumes that user space has set up data in the source object - using this presumption. This offers a fairly important optimization - as writing relocation data requires mapping of the source object - into the kernel memory space. - - 'read_domains' and 'write_domains' list the usage by the source - object of the target object. The kernel unions all of the domain - information from all relocations in the execbuffer request. No more - than one write_domain is allowed, otherwise an EINVAL error is - returned. read_domains must contain write_domain. This domain - information is used to synchronize buffer contents as described - above in the section on domains. - -7.1.1 Memory Domains (Intel specific) - -The Intel GPU has several internal caches which are not coherent and hence -require explicit synchronization. Memory domains provide the necessary data -to synchronize what is needed while leaving other cache contents intact. - - * DRM_GEM_DOMAIN_I915_RENDER. - The GPU 3D and 2D rendering operations use a unified rendering cache, so - operations doing 3D painting and 2D blts will use this domain - - * DRM_GEM_DOMAIN_I915_SAMPLER - Textures are loaded by the sampler through a separate cache, so - any texture reading will use this domain. Note that the sampler - and renderer use different caches, so moving an object from render target - to texture source will require a domain transfer. - - * DRM_GEM_DOMAIN_I915_COMMAND - The command buffer doesn't have an explicit cache (although it does - read ahead quite a bit), so this domain just indicates that the object - needs to be flushed to the GPU. - - * DRM_GEM_DOMAIN_I915_INSTRUCTION - All of the programs on Gen4 and later chips use an instruction cache to - speed program execution. It must be explicitly flushed when new programs - are written to memory by the CPU. - - * DRM_GEM_DOMAIN_I915_VERTEX - Vertex data uses two different vertex caches, but they're - both flushed with the same instruction. - -7.2 Execution object list (Intel specific) - - struct drm_i915_gem_exec_object { - /** - * User's handle for a buffer to be bound into the GTT - * for this operation. - */ - uint32_t handle; - - /** - * List of relocations to be performed on this buffer - */ - uint32_t relocation_count; - /* struct drm_i915_gem_relocation_entry *relocs */ - uint64_t relocs_ptr; - - /** - * Required alignment in graphics aperture - */ - uint64_t alignment; - - /** - * Returned value of the updated offset of the object, - * for future presumed_offset writes. - */ - uint64_t offset; - }; - - Each object involved in a particular execution operation must be - listed using one of these structures. - - 'handle' references the object. - - 'relocs_ptr' is a user-mode pointer to a array of 'relocation_count' - drm_i915_gem_relocation_entry structs (see above) that - define the relocations necessary in this buffer. Note that all - relocations must reference other exec_object structures in the same - execbuffer ioctl and that those other buffers must come earlier in - the exec_object array. In other words, the dependencies mapped by the - exec_object relocations must form a directed acyclic graph. - - 'alignment' is the byte alignment necessary for this buffer. Each - object has specific alignment requirements, as the kernel doesn't - know what each object is being used for, those requirements must be - provided by user mode. If an object is used in two different ways, - it's quite possible that the alignment requirements will differ. - - 'offset' is a return value, receiving the location of the object - during this execbuffer operation. The application should use this - as the presumed offset in future operations; if the object does not - move, then kernel need not write relocation data. - -7.3 Execbuffer ioctl (Intel specific) - - struct drm_i915_gem_execbuffer { - /** - * List of buffers to be validated with their - * relocations to be performend on them. - * - * These buffers must be listed in an order such that - * all relocations a buffer is performing refer to - * buffers that have already appeared in the validate - * list. - */ - /* struct drm_i915_gem_validate_entry *buffers */ - uint64_t buffers_ptr; - uint32_t buffer_count; - - /** - * Offset in the batchbuffer to start execution from. - */ - uint32_t batch_start_offset; - - /** - * Bytes used in batchbuffer from batch_start_offset - */ - uint32_t batch_len; - uint32_t DR1; - uint32_t DR4; - uint32_t num_cliprects; - uint64_t cliprects_ptr; /* struct drm_clip_rect *cliprects */ - }; - - - 'buffers_ptr' is a user-mode pointer to an array of 'buffer_count' - drm_i915_gem_exec_object structures which contains the complete set - of objects required for this execbuffer operation. The last entry in - this array, the 'batch buffer', is the buffer of commands which will - be linked to the ring and executed. - - 'batch_start_offset' is the byte offset within the batch buffer which - contains the first command to execute. So far, we haven't found a - reason to use anything other than '0' here, but the thought was that - some space might be allocated for additional initialization which - could be skipped in some cases. This must be a multiple of 4. - - 'batch_len' is the length, in bytes, of the data to be executed - (i.e., the amount of data after batch_start_offset). This must - be a multiple of 4. - - 'num_cliprects' and 'cliprects_ptr' reference an array of - drm_clip_rect structures that is num_cliprects long. The entire - batch buffer will be executed multiple times, once for each - rectangle in this list. If num_cliprects is 0, then no clipping - rectangle will be set. - - 'DR1' and 'DR4' are portions of the 3DSTATE_DRAWING_RECTANGLE - command which will be queued when this operation is clipped - (num_cliprects != 0). - - DR1 bit definition - 31 Fast Scissor Clip Disable (debug only). - Disables a hardware optimization that - improves performance. This should have - no visible effect, other than reducing - performance - - 30 Depth Buffer Coordinate Offset Disable. - This disables the addition of the - depth buffer offset bits which are used - to change the location of the depth buffer - relative to the front buffer. - - 27:26 X Dither Offset. Specifies the X pixel - offset to use when accessing the dither table - - 25:24 Y Dither Offset. Specifies the Y pixel - offset to use when accessing the dither - table. - - DR4 bit definition - 31:16 Drawing Rectangle Origin Y. Specifies the Y - origin of coordinates relative to the - draw buffer. - - 15:0 Drawing Rectangle Origin X. Specifies the X - origin of coordinates relative to the - draw buffer. - - As you can see, these two fields are necessary for correctly - offsetting drawing within a buffer which contains multiple surfaces. - Note that DR1 is only used on Gen3 and earlier hardware and that - newer hardware sticks the dither offset elsewhere. - -7.3.1 Detailed Execution Description - - Execution of a single batch buffer requires several preparatory - steps to make the objects visible to the graphics engine and resolve - relocations to account for their current addresses. - - A. Mapping and Relocation - - Each exec_object structure in the array is examined in turn. - - If the object is not already bound to the GTT, it is assigned a - location in the graphics address space. If no space is available in - the GTT, some other object will be evicted. This may require waiting - for previous execbuffer requests to complete before that object can - be unmapped. With the location assigned, the pages for the object - are pinned in memory using find_or_create_page and the GTT entries - updated to point at the relevant pages using drm_agp_bind_pages. - - Then the array of relocations is traversed. Each relocation record - looks up the target object and, if the presumed offset does not - match the current offset (remember that this buffer has already been - assigned an address as it must have been mapped earlier), the - relocation value is computed using the current offset. If the - object is currently in use by the graphics engine, writing the data - out must be preceeded by a delay while the object is still busy. - Once it is idle, then the page containing the relocation is mapped - by the CPU and the updated relocation data written out. - - The read_domains and write_domain entries in each relocation are - used to compute the new read_domains and write_domain values for the - target buffers. The actual execution of the domain changes must wait - until all of the exec_object entries have been evaluated as the - complete set of domain information will not be available until then. - - B. Memory Domain Resolution - - After all of the new memory domain data has been pulled out of the - relocations and computed for each object, the list of objects is - again traversed and the new memory domains compared against the - current memory domains. There are two basic operations involved here: - - * Flushing the current write domain. If the new read domains - are not equal to the current write domain, then the current - write domain must be flushed. Otherwise, reads will not see data - present in the write domain cache. In addition, any new read domains - other than the current write domain must be invalidated to ensure - that the flushed data are re-read into their caches. - - * Invaliding new read domains. Any domains which were not currently - used for this object must be invalidated as old objects which - were mapped at the same location may have stale data in the new - domain caches. - - If the CPU cache is being invalidated and some GPU cache is being - flushed, then we'll have to wait for rendering to complete so that - any pending GPU writes will be complete before we flush the GPU - cache. - - If the CPU cache is being flushed, then we use 'clflush' to get data - written from the CPU. - - Because the GPU caches cannot be partially flushed or invalidated, - we don't actually flush them during this traversal stage. Rather, we - gather the invalidate and flush bits up in the device structure. - - Once all of the object domain changes have been evaluated, then the - gathered invalidate and flush bits are examined. For any GPU flush - operations, we emit a single MI_FLUSH command that performs all of - the necessary flushes. We then look to see if the CPU cache was - flushed. If so, we use the chipset flush magic (writing to a special - page) to get the data out of the chipset and into memory. - - C. Queuing Batch Buffer to the Ring - - With all of the objects resident in graphics memory space, and all - of the caches prepared with appropriate data, the batch buffer - object can be queued to the ring. If there are clip rectangles, then - the buffer is queued once per rectangle, with suitable clipping - inserted into the ring just before the batch buffer. - - D. Creating an IRQ Cookie - - Right after the batch buffer is placed in the ring, a request to - generate an IRQ is added to the ring along with a command to write a - marker into memory. When the IRQ fires, the driver can look at the - memory location to see where in the ring the GPU has passed. This - magic cookie value is stored in each object used in this execbuffer - command; it is used whereever you saw 'wait for rendering' above in - this document. - - E. Writing back the new object offsets - - So that the application has a better idea what to use for - 'presumed_offset' values later, the current object offsets are - written back to the exec_object structures. - - -8. Other misc Intel-specific functions. - -To complete the driver, a few other functions were necessary. - -8.1 Initialization from the X server - -As the X server is currently responsible for apportioning memory between 2D -and 3D, it must tell the kernel which region of the GTT aperture is -available for 3D objects to be mapped into. - - struct drm_i915_gem_init { - /** - * Beginning offset in the GTT to be managed by the - * DRM memory manager. - */ - uint64_t gtt_start; - /** - * Ending offset in the GTT to be managed by the DRM - * memory manager. - */ - uint64_t gtt_end; - }; - /* usage */ - init.gtt_start = <gtt_start>; - init.gtt_end = <gtt_end>; - ret = ioctl (fd, DRM_IOCTL_I915_GEM_INIT, &init); - - The GTT aperture between gtt_start and gtt_end will be used to map - objects. This also tells the kernel that the ring can be used, - pulling the ring addresses from the device registers. - -8.2 Pinning objects in the GTT - -For scan-out buffers and the current shared depth and back buffers, we need -to have them always available in the GTT, at least for now. Pinning means to -lock their pages in memory along with keeping them at a fixed offset in the -graphics aperture. These operations are available only to root. - - struct drm_i915_gem_pin { - /** Handle of the buffer to be pinned. */ - uint32_t handle; - uint32_t pad; - - /** alignment required within the aperture */ - uint64_t alignment; - - /** Returned GTT offset of the buffer. */ - uint64_t offset; - }; - - /* usage */ - pin.handle = <handle>; - pin.alignment = <alignment>; - ret = ioctl (fd, DRM_IOCTL_I915_GEM_PIN, &pin); - if (ret == 0) - return pin.offset; - - Pinning an object ensures that it will not be evicted from the GTT - or moved. It will stay resident until destroyed or unpinned. - - struct drm_i915_gem_unpin { - /** Handle of the buffer to be unpinned. */ - uint32_t handle; - uint32_t pad; - }; - - /* usage */ - unpin.handle = <handle>; - ret = ioctl (fd, DRM_IOCTL_I915_GEM_UNPIN, &unpin); - - Unpinning an object makes it possible to evict this object from the - GTT. It doesn't ensure that it will be evicted, just that it may. - |