Merge branch 'drm-gem'

Conflicts:

	shared-core/i915_dma.c

This brings in kernel support and userland interface for intel GEM.

1 files changed, 805 insertions, 0 deletions

diff --git a/linux-core/drm-gem.txt b/linux-core/drm-gem.txt
new file mode 100644
index 00000000..5cda87f8
--- /dev/null
+++ b/linux-core/drm-gem.txt
@@ -0,0 +1,805 @@
+                  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.
+