renesas/drm.git - libdrm, cloned from git://anongit.freedesktop.org/mesa/drm

Age	Commit message (Expand)	Author
2006-09-14	Remove the use of reserved pages, and use locked pages instead.	Thomas Hellstrom
2006-09-12	Fix some debug messages.	Thomas Hellstrom
2006-09-12	Use lazy fence wait when possible even for RW fences. Saves some CPU.	Thomas Hellstrom
2006-09-12	More bugfixes.	Thomas Hellstrom
2006-09-12	drm: use radeon specific names for radeon flags	Dave Airlie
2006-09-08	Various bugfixes.	Thomas Hellstrom
2006-09-06	Put the PCI device/vendor id in the drm_device_t.	Eric Anholt
2006-09-05	Fence all unfenced buffers function.	Thomas Hellstrom
2006-09-05	i915: Only turn on user IRQs when they are needed.	Thomas Hellstrom
2006-09-05	Fix memory cache initialization.	Thomas Hellstrom
2006-09-04	Buffer object wait IOCTL operation.	Thomas Hellstrom
2006-09-04	Make memory caches global so that they can be used with	Thomas Hellstrom
2006-09-01	Lindent drm_bo.c	Thomas Hellstrom
2006-09-01	Flag bit pattern bugfixes. Remove some error messages.	Thomas Hellstrom
2006-09-01	Export buffer info on map and validate ioctls.	Thomas Hellstrom
2006-09-01	Bugfixes,	Thomas Hellstrom
2006-09-01	Various bugfixes.	Thomas Hellstrom
2006-08-31	Validation and fencing.	Thomas Hellstrom
2006-08-31	Remove the buffer manager mutex. Use dev->struct_mutex instead.	Thomas Hellstrom
2006-08-31	More mapping synchronization.	Thomas Hellstrom
2006-08-30	Lindenting drm_bo.c and drm_ttm.c	Thomas Hellstrom
2006-08-30	Buffer object binding.	Thomas Hellstrom
2006-08-30	Buffer eviction.	Thomas Hellstrom
2006-08-30	Remove the buffer object hint field and use it only	Thomas Hellstrom
2006-08-30	Buffer object mapping and mapping synchronization for multiple clients.	Thomas Hellstrom
2006-08-30	Memory manager init and takedown.	Thomas Hellstrom
2006-08-30	Buffer object reply fill in.	Thomas Hellstrom
2006-08-29	Checkpoint commit. Buffer object flags and IOCTL argument list.	Thomas Hellstrom
2006-08-29	Checkpoint ttm addition to buffer objects.	Thomas Hellstrom
2006-08-29	64-bit IOCTL integer (Michel Dänzer & Brian Paul)	Thomas Hellstrom
2006-08-28	Buffer object creation.	Thomas Hellstrom
2006-08-28	Proper TTM dereferencing	Thomas Hellstrom
2006-08-29	Merge branch 'master' into nouveau-1	Dave Airlie
2006-08-28	Buffer object idle and mapping synchronization.	Thomas Hellstrom
2006-08-28	Checkpoint buffer object IOCTL stub.	Thomas Hellstrom
2006-08-28	Add a 64-bit drm unsigned type for 64-bit clean IOCTLS.	Thomas Hellstrom
2006-08-28	Merge branch 'master' of git+ssh://git.freedesktop.org/git/mesa/drm into drm-...	Thomas Hellstrom
2006-08-28	drm: lots of small cleanups and whitespace issues fixed up	Dave Airlie
2006-08-28	add static function, and remove bad attributions	Dave Airlie
2006-08-28	fix const pointer warnings with file_operations	Dave Airlie
2006-08-28	remove local copies of pci domain/bus/slot/num	Dave Airlie
2006-08-28	remove some DRM_ARRAY_SIZE from linux core code	Dave Airlie
2006-08-28	fixup some of the comments in drm_context.c	Dave Airlie
2006-08-28	drm: i810_dma.c: fix pointer arithmetic for 64-bit target	Dave Airlie
2006-08-27	Bugfixes.	Thomas Hellstrom
2006-08-27	Remove the ioctl multiplexing, and instead allow for generic	Thomas Hellstrom
2006-08-27	Have TTM create and reference ioctl call return the actual TTM size.	Thomas Hellstrom
2006-08-27	Add TTM map handle on reference.	Thomas Hellstrom
2006-08-27	ttm create / destroy / ref / unref ioctl.	Thomas Hellstrom
2006-08-27	initial import of nouveau code from nouveau CVS	Dave Airlie

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