Documentation/gpu/i915.rst

7 blocks. This excludes a set of SoC platforms with an SGX rendering unit,
79 its own tailor-made infrastructure for executing a display configuration
274 - BCS is a blitting (copy) engine, this is named `I915_EXEC_BLT` in user
276 - VCS is a video encode and decode engine, this is named `I915_EXEC_BSD`
281   instead it is to be used by user space to specify a default rendering
284 The Intel GPU family is a family of integrated GPU's using Unified
291 `DRM_IOCTL_I915_GEM_CREATE`). An ioctl providing a batchbuffer for the GPU
296 The i915 driver allows user space to create a context via the ioctl
297 `DRM_IOCTL_I915_GEM_CONTEXT_CREATE` which is identified by a 32-bit
298 integer. Such a context should be viewed by user-space as -loosely-
299 analogous to the idea of a CPU process of an operating system. The i915
300 driver guarantees that commands issued to a fixed context are to be
301 executed so that writes of a previously issued command are seen by
306 Gen4, also have that a context carries with it a GPU HW context;
307 the HW context is essentially (most of at least) the state of a GPU.
309 state via HW context when commands are issued to a context, this saves
317 GPUs (i.e. those before Gen8), there is a single global such translation
318 table, a global Graphics Translation Table (GTT). For newer generation
322 submits a batchbuffer, the kernel walks the list of GEM buffer objects
328 the GPU address when a GEM BO is assigned a GPU address and the kernel
329 might evict a different GEM BO from the (PP)GTT to make address room
330 for another GEM BO. Consequently, the ioctls submitting a batchbuffer
331 for execution also include a list of all locations within buffers that
339    This is a description of how the locking should be after
356 	  allocate memory while holding these looks we get a rehash