/* * Copyright 2003 Tungsten Graphics, Inc., Cedar Park, Texas. * All Rights Reserved. * * Permission is hereby granted, free of charge, to any person obtaining a * copy of this software and associated documentation files (the * "Software"), to deal in the Software without restriction, including * without limitation the rights to use, copy, modify, merge, publish, * distribute, sub license, and/or sell copies of the Software, and to * permit persons to whom the Software is furnished to do so, subject to * the following conditions: * * The above copyright notice and this permission notice (including the * next paragraph) shall be included in all copies or substantial portions * of the Software. * * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. * IN NO EVENT SHALL TUNGSTEN GRAPHICS AND/OR ITS SUPPLIERS BE LIABLE FOR * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. *
*/
/* Please note that modifications to all structs defined here are * subject to backwards-compatibility constraints.
*/
/** * DOC: uevents generated by i915 on its device node * * I915_L3_PARITY_UEVENT - Generated when the driver receives a parity mismatch * event from the GPU L3 cache. Additional information supplied is ROW, * BANK, SUBBANK, SLICE of the affected cacheline. Userspace should keep * track of these events, and if a specific cache-line seems to have a * persistent error, remap it with the L3 remapping tool supplied in * intel-gpu-tools. The value supplied with the event is always 1. * * I915_ERROR_UEVENT - Generated upon error detection, currently only via * hangcheck. The error detection event is a good indicator of when things * began to go badly. The value supplied with the event is a 1 upon error * detection, and a 0 upon reset completion, signifying no more error * exists. NOTE: Disabling hangcheck or reset via module parameter will * cause the related events to not be seen. * * I915_RESET_UEVENT - Event is generated just before an attempt to reset the * GPU. The value supplied with the event is always 1. NOTE: Disable * reset via module parameter will cause this event to not be seen.
*/ #define I915_L3_PARITY_UEVENT "L3_PARITY_ERROR" #define I915_ERROR_UEVENT "ERROR" #define I915_RESET_UEVENT "RESET"
/** * struct i915_user_extension - Base class for defining a chain of extensions * * Many interfaces need to grow over time. In most cases we can simply * extend the struct and have userspace pass in more data. Another option, * as demonstrated by Vulkan's approach to providing extensions for forward * and backward compatibility, is to use a list of optional structs to * provide those extra details. * * The key advantage to using an extension chain is that it allows us to * redefine the interface more easily than an ever growing struct of * increasing complexity, and for large parts of that interface to be * entirely optional. The downside is more pointer chasing; chasing across * the __user boundary with pointers encapsulated inside u64. * * Example chaining: * * .. code-block:: C * * struct i915_user_extension ext3 { * .next_extension = 0, // end * .name = ..., * }; * struct i915_user_extension ext2 { * .next_extension = (uintptr_t)&ext3, * .name = ..., * }; * struct i915_user_extension ext1 { * .next_extension = (uintptr_t)&ext2, * .name = ..., * }; * * Typically the struct i915_user_extension would be embedded in some uAPI * struct, and in this case we would feed it the head of the chain(i.e ext1), * which would then apply all of the above extensions. *
*/ struct i915_user_extension { /** * @next_extension: * * Pointer to the next struct i915_user_extension, or zero if the end.
*/
__u64 next_extension; /** * @name: Name of the extension. * * Note that the name here is just some integer. * * Also note that the name space for this is not global for the whole * driver, but rather its scope/meaning is limited to the specific piece * of uAPI which has embedded the struct i915_user_extension.
*/
__u32 name; /** * @flags: MBZ * * All undefined bits must be zero.
*/
__u32 flags; /** * @rsvd: MBZ * * Reserved for future use; must be zero.
*/
__u32 rsvd[4];
};
/* * MOCS indexes used for GPU surfaces, defining the cacheability of the * surface data and the coherency for this data wrt. CPU vs. GPU accesses.
*/ enum i915_mocs_table_index { /* * Not cached anywhere, coherency between CPU and GPU accesses is * guaranteed.
*/
I915_MOCS_UNCACHED, /* * Cacheability and coherency controlled by the kernel automatically * based on the DRM_I915_GEM_SET_CACHING IOCTL setting and the current * usage of the surface (used for display scanout or not).
*/
I915_MOCS_PTE, /* * Cached in all GPU caches available on the platform. * Coherency between CPU and GPU accesses to the surface is not * guaranteed without extra synchronization.
*/
I915_MOCS_CACHED,
};
/** * enum drm_i915_gem_engine_class - uapi engine type enumeration * * Different engines serve different roles, and there may be more than one * engine serving each role. This enum provides a classification of the role * of the engine, which may be used when requesting operations to be performed * on a certain subset of engines, or for providing information about that * group.
*/ enum drm_i915_gem_engine_class { /** * @I915_ENGINE_CLASS_RENDER: * * Render engines support instructions used for 3D, Compute (GPGPU), * and programmable media workloads. These instructions fetch data and * dispatch individual work items to threads that operate in parallel. * The threads run small programs (called "kernels" or "shaders") on * the GPU's execution units (EUs).
*/
I915_ENGINE_CLASS_RENDER = 0,
/** * @I915_ENGINE_CLASS_COPY: * * Copy engines (also referred to as "blitters") support instructions * that move blocks of data from one location in memory to another, * or that fill a specified location of memory with fixed data. * Copy engines can perform pre-defined logical or bitwise operations * on the source, destination, or pattern data.
*/
I915_ENGINE_CLASS_COPY = 1,
/** * @I915_ENGINE_CLASS_VIDEO: * * Video engines (also referred to as "bit stream decode" (BSD) or * "vdbox") support instructions that perform fixed-function media * decode and encode.
*/
I915_ENGINE_CLASS_VIDEO = 2,
/** * @I915_ENGINE_CLASS_VIDEO_ENHANCE: * * Video enhancement engines (also referred to as "vebox") support * instructions related to image enhancement.
*/
I915_ENGINE_CLASS_VIDEO_ENHANCE = 3,
/** * @I915_ENGINE_CLASS_COMPUTE: * * Compute engines support a subset of the instructions available * on render engines: compute engines support Compute (GPGPU) and * programmable media workloads, but do not support the 3D pipeline.
*/
I915_ENGINE_CLASS_COMPUTE = 4,
/* Values in this enum should be kept compact. */
/** * @I915_ENGINE_CLASS_INVALID: * * Placeholder value to represent an invalid engine class assignment.
*/
I915_ENGINE_CLASS_INVALID = -1
};
/** * struct i915_engine_class_instance - Engine class/instance identifier * * There may be more than one engine fulfilling any role within the system. * Each engine of a class is given a unique instance number and therefore * any engine can be specified by its class:instance tuplet. APIs that allow * access to any engine in the system will use struct i915_engine_class_instance * for this identification.
*/ struct i915_engine_class_instance { /** * @engine_class: * * Engine class from enum drm_i915_gem_engine_class
*/
__u16 engine_class; #define I915_ENGINE_CLASS_INVALID_NONE -1 #define I915_ENGINE_CLASS_INVALID_VIRTUAL -2
/* Each region is a minimum of 16k, and there are at most 255 of them.
*/ #define I915_NR_TEX_REGIONS 255 /* table size 2k - maximum due to use
* of chars for next/prev indices */ #define I915_LOG_MIN_TEX_REGION_SIZE 14
typedefstruct _drm_i915_sarea { struct drm_tex_region texList[I915_NR_TEX_REGIONS + 1]; int last_upload; /* last time texture was uploaded */ int last_enqueue; /* last time a buffer was enqueued */ int last_dispatch; /* age of the most recently dispatched buffer */ int ctxOwner; /* last context to upload state */ int texAge; int pf_enabled; /* is pageflipping allowed? */ int pf_active; int pf_current_page; /* which buffer is being displayed? */ int perf_boxes; /* performance boxes to be displayed */ int width, height; /* screen size in pixels */
drm_handle_t front_handle; int front_offset; int front_size;
drm_handle_t back_handle; int back_offset; int back_size;
drm_handle_t depth_handle; int depth_offset; int depth_size;
drm_handle_t tex_handle; int tex_offset; int tex_size; int log_tex_granularity; int pitch; int rotation; /* 0, 90, 180 or 270 */ int rotated_offset; int rotated_size; int rotated_pitch; int virtualX, virtualY;
int pipeA_x; int pipeA_y; int pipeA_w; int pipeA_h; int pipeB_x; int pipeB_y; int pipeB_w; int pipeB_h;
/* fill out some space for old userspace triple buffer */
drm_handle_t unused_handle;
__u32 unused1, unused2, unused3;
/* buffer object handles for static buffers. May change * over the lifetime of the client.
*/
__u32 front_bo_handle;
__u32 back_bo_handle;
__u32 unused_bo_handle;
__u32 depth_bo_handle;
} drm_i915_sarea_t;
/* due to userspace building against these headers we need some compat here */ #define planeA_x pipeA_x #define planeA_y pipeA_y #define planeA_w pipeA_w #define planeA_h pipeA_h #define planeB_x pipeB_x #define planeB_y pipeB_y #define planeB_w pipeB_w #define planeB_h pipeB_h
/* Allow drivers to submit batchbuffers directly to hardware, relying * on the security mechanisms provided by hardware.
*/ typedefstruct drm_i915_batchbuffer { int start; /* agp offset */ int used; /* nr bytes in use */ int DR1; /* hw flags for GFX_OP_DRAWRECT_INFO */ int DR4; /* window origin for GFX_OP_DRAWRECT_INFO */ int num_cliprects; /* mulitpass with multiple cliprects? */ struct drm_clip_rect __user *cliprects; /* pointer to userspace cliprects */
} drm_i915_batchbuffer_t;
/* As above, but pass a pointer to userspace buffer which can be * validated by the kernel prior to sending to hardware.
*/ typedefstruct _drm_i915_cmdbuffer { char __user *buf; /* pointer to userspace command buffer */ int sz; /* nr bytes in buf */ int DR1; /* hw flags for GFX_OP_DRAWRECT_INFO */ int DR4; /* window origin for GFX_OP_DRAWRECT_INFO */ int num_cliprects; /* mulitpass with multiple cliprects? */ struct drm_clip_rect __user *cliprects; /* pointer to userspace cliprects */
} drm_i915_cmdbuffer_t;
/* Userspace can request & wait on irq's:
*/ typedefstruct drm_i915_irq_emit { int __user *irq_seq;
} drm_i915_irq_emit_t;
typedefstruct drm_i915_irq_wait { int irq_seq;
} drm_i915_irq_wait_t;
/* * Different modes of per-process Graphics Translation Table, * see I915_PARAM_HAS_ALIASING_PPGTT
*/ #define I915_GEM_PPGTT_NONE 0 #define I915_GEM_PPGTT_ALIASING 1 #define I915_GEM_PPGTT_FULL 2
/* * Query whether DRM_I915_GEM_EXECBUFFER2 supports user defined execution * priorities and the driver will attempt to execute batches in priority order. * The param returns a capability bitmask, nonzero implies that the scheduler * is enabled, with different features present according to the mask. * * The initial priority for each batch is supplied by the context and is * controlled via I915_CONTEXT_PARAM_PRIORITY.
*/ #define I915_PARAM_HAS_SCHEDULER 41 #define I915_SCHEDULER_CAP_ENABLED (1ul << 0) #define I915_SCHEDULER_CAP_PRIORITY (1ul << 1) #define I915_SCHEDULER_CAP_PREEMPTION (1ul << 2) #define I915_SCHEDULER_CAP_SEMAPHORES (1ul << 3) #define I915_SCHEDULER_CAP_ENGINE_BUSY_STATS (1ul << 4) /* * Indicates the 2k user priority levels are statically mapped into 3 buckets as * follows: * * -1k to -1 Low priority * 0 Normal priority * 1 to 1k Highest priority
*/ #define I915_SCHEDULER_CAP_STATIC_PRIORITY_MAP (1ul << 5)
/* * Query the status of HuC load. * * The query can fail in the following scenarios with the listed error codes: * -ENODEV if HuC is not present on this platform, * -EOPNOTSUPP if HuC firmware usage is disabled, * -ENOPKG if HuC firmware fetch failed, * -ENOEXEC if HuC firmware is invalid or mismatched, * -ENOMEM if i915 failed to prepare the FW objects for transfer to the uC, * -EIO if the FW transfer or the FW authentication failed. * * If the IOCTL is successful, the returned parameter will be set to one of the * following values: * * 0 if HuC firmware load is not complete, * * 1 if HuC firmware is loaded and fully authenticated, * * 2 if HuC firmware is loaded and authenticated for clear media only
*/ #define I915_PARAM_HUC_STATUS 42
/* Query whether DRM_I915_GEM_EXECBUFFER2 supports the ability to opt-out of * synchronisation with implicit fencing on individual objects. * See EXEC_OBJECT_ASYNC.
*/ #define I915_PARAM_HAS_EXEC_ASYNC 43
/* Query whether DRM_I915_GEM_EXECBUFFER2 supports explicit fence support - * both being able to pass in a sync_file fd to wait upon before executing, * and being able to return a new sync_file fd that is signaled when the * current request is complete. See I915_EXEC_FENCE_IN and I915_EXEC_FENCE_OUT.
*/ #define I915_PARAM_HAS_EXEC_FENCE 44
/* Query whether DRM_I915_GEM_EXECBUFFER2 supports the ability to capture * user-specified buffers for post-mortem debugging of GPU hangs. See * EXEC_OBJECT_CAPTURE.
*/ #define I915_PARAM_HAS_EXEC_CAPTURE 45
#define I915_PARAM_SLICE_MASK 46
/* Assuming it's uniform for each slice, this queries the mask of subslices * per-slice for this system.
*/ #define I915_PARAM_SUBSLICE_MASK 47
/* * Query whether DRM_I915_GEM_EXECBUFFER2 supports supplying the batch buffer * as the first execobject as opposed to the last. See I915_EXEC_BATCH_FIRST.
*/ #define I915_PARAM_HAS_EXEC_BATCH_FIRST 48
/* Query whether DRM_I915_GEM_EXECBUFFER2 supports supplying an array of * drm_i915_gem_exec_fence structures. See I915_EXEC_FENCE_ARRAY.
*/ #define I915_PARAM_HAS_EXEC_FENCE_ARRAY 49
/* * Query whether every context (both per-file default and user created) is * isolated (insofar as HW supports). If this parameter is not true, then * freshly created contexts may inherit values from an existing context, * rather than default HW values. If true, it also ensures (insofar as HW * supports) that all state set by this context will not leak to any other * context. * * As not every engine across every gen support contexts, the returned * value reports the support of context isolation for individual engines by * returning a bitmask of each engine class set to true if that class supports * isolation.
*/ #define I915_PARAM_HAS_CONTEXT_ISOLATION 50
/* Frequency of the command streamer timestamps given by the *_TIMESTAMP * registers. This used to be fixed per platform but from CNL onwards, this * might vary depending on the parts.
*/ #define I915_PARAM_CS_TIMESTAMP_FREQUENCY 51
/* * Once upon a time we supposed that writes through the GGTT would be * immediately in physical memory (once flushed out of the CPU path). However, * on a few different processors and chipsets, this is not necessarily the case * as the writes appear to be buffered internally. Thus a read of the backing * storage (physical memory) via a different path (with different physical tags * to the indirect write via the GGTT) will see stale values from before * the GGTT write. Inside the kernel, we can for the most part keep track of * the different read/write domains in use (e.g. set-domain), but the assumption * of coherency is baked into the ABI, hence reporting its true state in this * parameter. * * Reports true when writes via mmap_gtt are immediately visible following an * lfence to flush the WCB. * * Reports false when writes via mmap_gtt are indeterminately delayed in an in * internal buffer and are _not_ immediately visible to third parties accessing * directly via mmap_cpu/mmap_wc. Use of mmap_gtt as part of an IPC * communications channel when reporting false is strongly disadvised.
*/ #define I915_PARAM_MMAP_GTT_COHERENT 52
/* * Query whether DRM_I915_GEM_EXECBUFFER2 supports coordination of parallel * execution through use of explicit fence support. * See I915_EXEC_FENCE_OUT and I915_EXEC_FENCE_SUBMIT.
*/ #define I915_PARAM_HAS_EXEC_SUBMIT_FENCE 53
/* * Revision of the i915-perf uAPI. The value returned helps determine what * i915-perf features are available. See drm_i915_perf_property_id.
*/ #define I915_PARAM_PERF_REVISION 54
/* Query whether DRM_I915_GEM_EXECBUFFER2 supports supplying an array of * timeline syncobj through drm_i915_gem_execbuffer_ext_timeline_fences. See * I915_EXEC_USE_EXTENSIONS.
*/ #define I915_PARAM_HAS_EXEC_TIMELINE_FENCES 55
/* Query if the kernel supports the I915_USERPTR_PROBE flag. */ #define I915_PARAM_HAS_USERPTR_PROBE 56
/* * Frequency of the timestamps in OA reports. This used to be the same as the CS * timestamp frequency, but differs on some platforms.
*/ #define I915_PARAM_OA_TIMESTAMP_FREQUENCY 57
/* * Query the status of PXP support in i915. * * The query can fail in the following scenarios with the listed error codes: * -ENODEV = PXP support is not available on the GPU device or in the * kernel due to missing component drivers or kernel configs. * * If the IOCTL is successful, the returned parameter will be set to one of * the following values: * 1 = PXP feature is supported and is ready for use. * 2 = PXP feature is supported but should be ready soon (pending * initialization of non-i915 system dependencies). * * NOTE: When param is supported (positive return values), user space should * still refer to the GEM PXP context-creation UAPI header specs to be * aware of possible failure due to system state machine at the time.
*/ #define I915_PARAM_PXP_STATUS 58
/* * Query if kernel allows marking a context to send a Freq hint to SLPC. This * will enable use of the strategies allowed by the SLPC algorithm.
*/ #define I915_PARAM_HAS_CONTEXT_FREQ_HINT 59
/* Must be kept compact -- no holes and well documented */
/** * @value: Address of memory where queried value should be put. * * WARNING: Using pointers instead of fixed-size u64 means we need to write * compat32 code. Don't repeat this mistake.
*/ int __user *value;
};
/* Ioctl to set kernel params:
*/ #define I915_SETPARAM_USE_MI_BATCHBUFFER_START 1 #define I915_SETPARAM_TEX_LRU_LOG_GRANULARITY 2 #define I915_SETPARAM_ALLOW_BATCHBUFFER 3 #define I915_SETPARAM_NUM_USED_FENCES 4 /* Must be kept compact -- no holes */
typedefstruct drm_i915_setparam { int param; int value;
} drm_i915_setparam_t;
/* A memory manager for regions of shared memory:
*/ #define I915_MEM_REGION_AGP 1
typedefstruct drm_i915_mem_alloc { int region; int alignment; int size; int __user *region_offset; /* offset from start of fb or agp */
} drm_i915_mem_alloc_t;
typedefstruct drm_i915_mem_free { int region; int region_offset;
} drm_i915_mem_free_t;
typedefstruct drm_i915_mem_init_heap { int region; int size; int start;
} drm_i915_mem_init_heap_t;
/* Allow memory manager to be torn down and re-initialized (eg on * rotate):
*/ typedefstruct drm_i915_mem_destroy_heap { int region;
} drm_i915_mem_destroy_heap_t;
/* Allow X server to configure which pipes to monitor for vblank signals
*/ #define DRM_I915_VBLANK_PIPE_A 1 #define DRM_I915_VBLANK_PIPE_B 2
typedefstruct drm_i915_vblank_pipe { int pipe;
} drm_i915_vblank_pipe_t;
struct drm_i915_gem_init { /** * Beginning offset in the GTT to be managed by the DRM memory * manager.
*/
__u64 gtt_start; /** * Ending offset in the GTT to be managed by the DRM memory * manager.
*/
__u64 gtt_end;
};
struct drm_i915_gem_create { /** * Requested size for the object. * * The (page-aligned) allocated size for the object will be returned.
*/
__u64 size; /** * Returned handle for the object. * * Object handles are nonzero.
*/
__u32 handle;
__u32 pad;
};
struct drm_i915_gem_pread { /** Handle for the object being read. */
__u32 handle;
__u32 pad; /** Offset into the object to read from */
__u64 offset; /** Length of data to read */
__u64 size; /** * Pointer to write the data into. * * This is a fixed-size type for 32/64 compatibility.
*/
__u64 data_ptr;
};
struct drm_i915_gem_pwrite { /** Handle for the object being written to. */
__u32 handle;
__u32 pad; /** Offset into the object to write to */
__u64 offset; /** Length of data to write */
__u64 size; /** * Pointer to read the data from. * * This is a fixed-size type for 32/64 compatibility.
*/
__u64 data_ptr;
};
struct drm_i915_gem_mmap { /** Handle for the object being mapped. */
__u32 handle;
__u32 pad; /** Offset in the object to map. */
__u64 offset; /** * Length of data to map. * * The value will be page-aligned.
*/
__u64 size; /** * Returned pointer the data was mapped at. * * This is a fixed-size type for 32/64 compatibility.
*/
__u64 addr_ptr;
/** * Flags for extended behaviour. * * Added in version 2.
*/
__u64 flags; #define I915_MMAP_WC 0x1
};
struct drm_i915_gem_mmap_gtt { /** Handle for the object being mapped. */
__u32 handle;
__u32 pad; /** * Fake offset to use for subsequent mmap call * * This is a fixed-size type for 32/64 compatibility.
*/
__u64 offset;
};
/** * struct drm_i915_gem_mmap_offset - Retrieve an offset so we can mmap this buffer object. * * This struct is passed as argument to the `DRM_IOCTL_I915_GEM_MMAP_OFFSET` ioctl, * and is used to retrieve the fake offset to mmap an object specified by &handle. * * The legacy way of using `DRM_IOCTL_I915_GEM_MMAP` is removed on gen12+. * `DRM_IOCTL_I915_GEM_MMAP_GTT` is an older supported alias to this struct, but will behave * as setting the &extensions to 0, and &flags to `I915_MMAP_OFFSET_GTT`.
*/ struct drm_i915_gem_mmap_offset { /** @handle: Handle for the object being mapped. */
__u32 handle; /** @pad: Must be zero */
__u32 pad; /** * @offset: The fake offset to use for subsequent mmap call * * This is a fixed-size type for 32/64 compatibility.
*/
__u64 offset;
/** * @flags: Flags for extended behaviour. * * It is mandatory that one of the `MMAP_OFFSET` types * should be included: * * - `I915_MMAP_OFFSET_GTT`: Use mmap with the object bound to GTT. (Write-Combined) * - `I915_MMAP_OFFSET_WC`: Use Write-Combined caching. * - `I915_MMAP_OFFSET_WB`: Use Write-Back caching. * - `I915_MMAP_OFFSET_FIXED`: Use object placement to determine caching. * * On devices with local memory `I915_MMAP_OFFSET_FIXED` is the only valid * type. On devices without local memory, this caching mode is invalid. * * As caching mode when specifying `I915_MMAP_OFFSET_FIXED`, WC or WB will * be used, depending on the object placement on creation. WB will be used * when the object can only exist in system memory, WC otherwise.
*/
__u64 flags;
/** * @extensions: Zero-terminated chain of extensions. * * No current extensions defined; mbz.
*/
__u64 extensions;
};
/** * struct drm_i915_gem_set_domain - Adjust the objects write or read domain, in * preparation for accessing the pages via some CPU domain. * * Specifying a new write or read domain will flush the object out of the * previous domain(if required), before then updating the objects domain * tracking with the new domain. * * Note this might involve waiting for the object first if it is still active on * the GPU. * * Supported values for @read_domains and @write_domain: * * - I915_GEM_DOMAIN_WC: Uncached write-combined domain * - I915_GEM_DOMAIN_CPU: CPU cache domain * - I915_GEM_DOMAIN_GTT: Mappable aperture domain * * All other domains are rejected. * * Note that for discrete, starting from DG1, this is no longer supported, and * is instead rejected. On such platforms the CPU domain is effectively static, * where we also only support a single &drm_i915_gem_mmap_offset cache mode, * which can't be set explicitly and instead depends on the object placements, * as per the below. * * Implicit caching rules, starting from DG1: * * - If any of the object placements (see &drm_i915_gem_create_ext_memory_regions) * contain I915_MEMORY_CLASS_DEVICE then the object will be allocated and * mapped as write-combined only. * * - Everything else is always allocated and mapped as write-back, with the * guarantee that everything is also coherent with the GPU. * * Note that this is likely to change in the future again, where we might need * more flexibility on future devices, so making this all explicit as part of a * new &drm_i915_gem_create_ext extension is probable.
*/ struct drm_i915_gem_set_domain { /** @handle: Handle for the object. */
__u32 handle;
/** @read_domains: New read domains. */
__u32 read_domains;
/** * @write_domain: New write domain. * * Note that having something in the write domain implies it's in the * read domain, and only that read domain.
*/
__u32 write_domain;
};
struct drm_i915_gem_sw_finish { /** Handle for the object */
__u32 handle;
};
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.
*/
__u32 target_handle;
/** * Value to be added to the offset of the target buffer to make up * the relocation entry.
*/
__u32 delta;
/** Offset in the buffer the relocation entry will be written into */
__u64 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.
*/
__u64 presumed_offset;
/** * Target memory domains read by this operation.
*/
__u32 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.
*/
__u32 write_domain;
};
/** @{ * Intel memory domains * * Most of these just align with the various caches in * the system and are used to flush and invalidate as * objects end up cached in different domains.
*/ /** CPU cache */ #define I915_GEM_DOMAIN_CPU 0x00000001 /** Render cache, used by 2D and 3D drawing */ #define I915_GEM_DOMAIN_RENDER 0x00000002 /** Sampler cache, used by texture engine */ #define I915_GEM_DOMAIN_SAMPLER 0x00000004 /** Command queue, used to load batch buffers */ #define I915_GEM_DOMAIN_COMMAND 0x00000008 /** Instruction cache, used by shader programs */ #define I915_GEM_DOMAIN_INSTRUCTION 0x00000010 /** Vertex address cache */ #define I915_GEM_DOMAIN_VERTEX 0x00000020 /** GTT domain - aperture and scanout */ #define I915_GEM_DOMAIN_GTT 0x00000040 /** WC domain - uncached access */ #define I915_GEM_DOMAIN_WC 0x00000080 /** @} */
struct drm_i915_gem_exec_object { /** * User's handle for a buffer to be bound into the GTT for this * operation.
*/
__u32 handle;
/** Number of relocations to be performed on this buffer */
__u32 relocation_count; /** * Pointer to array of struct drm_i915_gem_relocation_entry containing * the relocations to be performed in this buffer.
*/
__u64 relocs_ptr;
/** Required alignment in graphics aperture */
__u64 alignment;
/** * Returned value of the updated offset of the object, for future * presumed_offset writes.
*/
__u64 offset;
};
/* DRM_IOCTL_I915_GEM_EXECBUFFER was removed in Linux 5.13 */ struct drm_i915_gem_execbuffer { /** * List of buffers to be validated with their relocations to be * performend on them. * * This is a pointer to an array of struct drm_i915_gem_validate_entry. * * 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.
*/
__u64 buffers_ptr;
__u32 buffer_count;
/** Offset in the batchbuffer to start execution from. */
__u32 batch_start_offset; /** Bytes used in batchbuffer from batch_start_offset */
__u32 batch_len;
__u32 DR1;
__u32 DR4;
__u32 num_cliprects; /** This is a struct drm_clip_rect *cliprects */
__u64 cliprects_ptr;
};
struct drm_i915_gem_exec_object2 { /** * User's handle for a buffer to be bound into the GTT for this * operation.
*/
__u32 handle;
/** Number of relocations to be performed on this buffer */
__u32 relocation_count; /** * Pointer to array of struct drm_i915_gem_relocation_entry containing * the relocations to be performed in this buffer.
*/
__u64 relocs_ptr;
/** Required alignment in graphics aperture */
__u64 alignment;
/** * When the EXEC_OBJECT_PINNED flag is specified this is populated by * the user with the GTT offset at which this object will be pinned. * * When the I915_EXEC_NO_RELOC flag is specified this must contain the * presumed_offset of the object. * * During execbuffer2 the kernel populates it with the value of the * current GTT offset of the object, for future presumed_offset writes. * * See struct drm_i915_gem_create_ext for the rules when dealing with * alignment restrictions with I915_MEMORY_CLASS_DEVICE, on devices with * minimum page sizes, like DG2.
*/
__u64 offset;
#define EXEC_OBJECT_NEEDS_FENCE (1<<0) #define EXEC_OBJECT_NEEDS_GTT (1<<1) #define EXEC_OBJECT_WRITE (1<<2) #define EXEC_OBJECT_SUPPORTS_48B_ADDRESS (1<<3) #define EXEC_OBJECT_PINNED (1<<4) #define EXEC_OBJECT_PAD_TO_SIZE (1<<5) /* The kernel implicitly tracks GPU activity on all GEM objects, and * synchronises operations with outstanding rendering. This includes * rendering on other devices if exported via dma-buf. However, sometimes * this tracking is too coarse and the user knows better. For example, * if the object is split into non-overlapping ranges shared between different * clients or engines (i.e. suballocating objects), the implicit tracking * by kernel assumes that each operation affects the whole object rather * than an individual range, causing needless synchronisation between clients. * The kernel will also forgo any CPU cache flushes prior to rendering from * the object as the client is expected to be also handling such domain * tracking. * * The kernel maintains the implicit tracking in order to manage resources * used by the GPU - this flag only disables the synchronisation prior to * rendering with this object in this execbuf. * * Opting out of implicit synhronisation requires the user to do its own * explicit tracking to avoid rendering corruption. See, for example, * I915_PARAM_HAS_EXEC_FENCE to order execbufs and execute them asynchronously.
*/ #define EXEC_OBJECT_ASYNC (1<<6) /* Request that the contents of this execobject be copied into the error * state upon a GPU hang involving this batch for post-mortem debugging. * These buffers are recorded in no particular order as "user" in * /sys/class/drm/cardN/error. Query I915_PARAM_HAS_EXEC_CAPTURE to see * if the kernel supports this flag.
*/ #define EXEC_OBJECT_CAPTURE (1<<7) /* All remaining bits are MBZ and RESERVED FOR FUTURE USE */ #define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_CAPTURE<<1)
__u64 flags;
union {
__u64 rsvd1;
__u64 pad_to_size;
};
__u64 rsvd2;
};
/** * struct drm_i915_gem_exec_fence - An input or output fence for the execbuf * ioctl. * * The request will wait for input fence to signal before submission. * * The returned output fence will be signaled after the completion of the * request.
*/ struct drm_i915_gem_exec_fence { /** @handle: User's handle for a drm_syncobj to wait on or signal. */
__u32 handle;
/** * struct drm_i915_gem_execbuffer_ext_timeline_fences - Timeline fences * for execbuf ioctl. * * This structure describes an array of drm_syncobj and associated points for * timeline variants of drm_syncobj. It is invalid to append this structure to * the execbuf if I915_EXEC_FENCE_ARRAY is set.
*/ struct drm_i915_gem_execbuffer_ext_timeline_fences { #define DRM_I915_GEM_EXECBUFFER_EXT_TIMELINE_FENCES 0 /** @base: Extension link. See struct i915_user_extension. */ struct i915_user_extension base;
/** * @fence_count: Number of elements in the @handles_ptr & @value_ptr * arrays.
*/
__u64 fence_count;
/** * @handles_ptr: Pointer to an array of struct drm_i915_gem_exec_fence * of length @fence_count.
*/
__u64 handles_ptr;
/** * @values_ptr: Pointer to an array of u64 values of length * @fence_count. * Values must be 0 for a binary drm_syncobj. A Value of 0 for a * timeline drm_syncobj is invalid as it turns a drm_syncobj into a * binary one.
*/
__u64 values_ptr;
};
/** * struct drm_i915_gem_execbuffer2 - Structure for DRM_I915_GEM_EXECBUFFER2 * ioctl.
*/ struct drm_i915_gem_execbuffer2 { /** @buffers_ptr: Pointer to a list of gem_exec_object2 structs */
__u64 buffers_ptr;
/** @buffer_count: Number of elements in @buffers_ptr array */
__u32 buffer_count;
/** * @batch_start_offset: Offset in the batchbuffer to start execution * from.
*/
__u32 batch_start_offset;
/** * @batch_len: Length in bytes of the batch buffer, starting from the * @batch_start_offset. If 0, length is assumed to be the batch buffer * object size.
*/
__u32 batch_len;
/** @DR1: deprecated */
__u32 DR1;
/** @DR4: deprecated */
__u32 DR4;
/** @num_cliprects: See @cliprects_ptr */
__u32 num_cliprects;
/** * @cliprects_ptr: Kernel clipping was a DRI1 misfeature. * * It is invalid to use this field if I915_EXEC_FENCE_ARRAY or * I915_EXEC_USE_EXTENSIONS flags are not set. * * If I915_EXEC_FENCE_ARRAY is set, then this is a pointer to an array * of &drm_i915_gem_exec_fence and @num_cliprects is the length of the * array. * * If I915_EXEC_USE_EXTENSIONS is set, then this is a pointer to a * single &i915_user_extension and num_cliprects is 0.
*/
__u64 cliprects_ptr;
/* Used for switching the constants addressing mode on gen4+ RENDER ring. * Gen6+ only supports relative addressing to dynamic state (default) and * absolute addressing. * * These flags are ignored for the BSD and BLT rings.
*/ #define I915_EXEC_CONSTANTS_MASK (3<<6) #define I915_EXEC_CONSTANTS_REL_GENERAL (0<<6) /* default */ #define I915_EXEC_CONSTANTS_ABSOLUTE (1<<6) #define I915_EXEC_CONSTANTS_REL_SURFACE (2<<6) /* gen4/5 only */
/** Resets the SO write offset registers for transform feedback on gen7. */ #define I915_EXEC_GEN7_SOL_RESET (1<<8)
/** Request a privileged ("secure") batch buffer. Note only available for * DRM_ROOT_ONLY | DRM_MASTER processes.
*/ #define I915_EXEC_SECURE (1<<9)
/** Inform the kernel that the batch is and will always be pinned. This * negates the requirement for a workaround to be performed to avoid * an incoherent CS (such as can be found on 830/845). If this flag is * not passed, the kernel will endeavour to make sure the batch is * coherent with the CS before execution. If this flag is passed, * userspace assumes the responsibility for ensuring the same.
*/ #define I915_EXEC_IS_PINNED (1<<10)
/** Provide a hint to the kernel that the command stream and auxiliary * state buffers already holds the correct presumed addresses and so the * relocation process may be skipped if no buffers need to be moved in * preparation for the execbuffer.
*/ #define I915_EXEC_NO_RELOC (1<<11)
/** Use the reloc.handle as an index into the exec object array rather * than as the per-file handle.
*/ #define I915_EXEC_HANDLE_LUT (1<<12)
/** Used for switching BSD rings on the platforms with two BSD rings */ #define I915_EXEC_BSD_SHIFT (13) #define I915_EXEC_BSD_MASK (3 << I915_EXEC_BSD_SHIFT) /* default ping-pong mode */ #define I915_EXEC_BSD_DEFAULT (0 << I915_EXEC_BSD_SHIFT) #define I915_EXEC_BSD_RING1 (1 << I915_EXEC_BSD_SHIFT) #define I915_EXEC_BSD_RING2 (2 << I915_EXEC_BSD_SHIFT)
/** Tell the kernel that the batchbuffer is processed by * the resource streamer.
*/ #define I915_EXEC_RESOURCE_STREAMER (1<<15)
/* Setting I915_EXEC_FENCE_IN implies that lower_32_bits(rsvd2) represent * a sync_file fd to wait upon (in a nonblocking manner) prior to executing * the batch. * * Returns -EINVAL if the sync_file fd cannot be found.
*/ #define I915_EXEC_FENCE_IN (1<<16)
/* Setting I915_EXEC_FENCE_OUT causes the ioctl to return a sync_file fd * in the upper_32_bits(rsvd2) upon success. Ownership of the fd is given * to the caller, and it should be close() after use. (The fd is a regular * file descriptor and will be cleaned up on process termination. It holds * a reference to the request, but nothing else.) * * The sync_file fd can be combined with other sync_file and passed either * to execbuf using I915_EXEC_FENCE_IN, to atomic KMS ioctls (so that a flip * will only occur after this request completes), or to other devices. * * Using I915_EXEC_FENCE_OUT requires use of * DRM_IOCTL_I915_GEM_EXECBUFFER2_WR ioctl so that the result is written * back to userspace. Failure to do so will cause the out-fence to always * be reported as zero, and the real fence fd to be leaked.
*/ #define I915_EXEC_FENCE_OUT (1<<17)
/* * Traditionally the execbuf ioctl has only considered the final element in * the execobject[] to be the executable batch. Often though, the client * will known the batch object prior to construction and being able to place * it into the execobject[] array first can simplify the relocation tracking. * Setting I915_EXEC_BATCH_FIRST tells execbuf to use element 0 of the * execobject[] as the * batch instead (the default is to use the last * element).
*/ #define I915_EXEC_BATCH_FIRST (1<<18)
/* Setting I915_FENCE_ARRAY implies that num_cliprects and cliprects_ptr * define an array of i915_gem_exec_fence structures which specify a set of * dma fences to wait upon or signal.
*/ #define I915_EXEC_FENCE_ARRAY (1<<19)
/* * Setting I915_EXEC_FENCE_SUBMIT implies that lower_32_bits(rsvd2) represent * a sync_file fd to wait upon (in a nonblocking manner) prior to executing * the batch. * * Returns -EINVAL if the sync_file fd cannot be found.
*/ #define I915_EXEC_FENCE_SUBMIT (1 << 20)
/* * Setting I915_EXEC_USE_EXTENSIONS implies that * drm_i915_gem_execbuffer2.cliprects_ptr is treated as a pointer to an linked * list of i915_user_extension. Each i915_user_extension node is the base of a * larger structure. The list of supported structures are listed in the * drm_i915_gem_execbuffer_ext enum.
*/ #define I915_EXEC_USE_EXTENSIONS (1 << 21) #define __I915_EXEC_UNKNOWN_FLAGS (-(I915_EXEC_USE_EXTENSIONS << 1))
/** @rsvd1: Context id */
__u64 rsvd1;
/** * @rsvd2: in and out sync_file file descriptors. * * When I915_EXEC_FENCE_IN or I915_EXEC_FENCE_SUBMIT flag is set, the * lower 32 bits of this field will have the in sync_file fd (input). * * When I915_EXEC_FENCE_OUT flag is set, the upper 32 bits of this * field will have the out sync_file fd (output).
*/
__u64 rsvd2;
};
struct drm_i915_gem_pin { /** Handle of the buffer to be pinned. */
__u32 handle;
__u32 pad;
/** alignment required within the aperture */
__u64 alignment;
/** Returned GTT offset of the buffer. */
__u64 offset;
};
struct drm_i915_gem_unpin { /** Handle of the buffer to be unpinned. */
__u32 handle;
__u32 pad;
};
struct drm_i915_gem_busy { /** Handle of the buffer to check for busy */
__u32 handle;
/** Return busy status * * A return of 0 implies that the object is idle (after * having flushed any pending activity), and a non-zero return that * the object is still in-flight on the GPU. (The GPU has not yet * signaled completion for all pending requests that reference the * object.) An object is guaranteed to become idle eventually (so * long as no new GPU commands are executed upon it). Due to the * asynchronous nature of the hardware, an object reported * as busy may become idle before the ioctl is completed. * * Furthermore, if the object is busy, which engine is busy is only * provided as a guide and only indirectly by reporting its class * (there may be more than one engine in each class). There are race * conditions which prevent the report of which engines are busy from * being always accurate. However, the converse is not true. If the * object is idle, the result of the ioctl, that all engines are idle, * is accurate. * * The returned dword is split into two fields to indicate both * the engine classes on which the object is being read, and the * engine class on which it is currently being written (if any). * * The low word (bits 0:15) indicate if the object is being written * to by any engine (there can only be one, as the GEM implicit * synchronisation rules force writes to be serialised). Only the * engine class (offset by 1, I915_ENGINE_CLASS_RENDER is reported as * 1 not 0 etc) for the last write is reported. * * The high word (bits 16:31) are a bitmask of which engines classes * are currently reading from the object. Multiple engines may be * reading from the object simultaneously. * * The value of each engine class is the same as specified in the * I915_CONTEXT_PARAM_ENGINES context parameter and via perf, i.e. * I915_ENGINE_CLASS_RENDER, I915_ENGINE_CLASS_COPY, etc. * Some hardware may have parallel execution engines, e.g. multiple * media engines, which are mapped to the same class identifier and so * are not separately reported for busyness. * * Caveat emptor: * Only the boolean result of this query is reliable; that is whether * the object is idle or busy. The report of which engines are busy * should be only used as a heuristic.
*/
__u32 busy;
};
/** * struct drm_i915_gem_caching - Set or get the caching for given object * handle. * * Allow userspace to control the GTT caching bits for a given object when the * object is later mapped through the ppGTT(or GGTT on older platforms lacking * ppGTT support, or if the object is used for scanout). Note that this might * require unbinding the object from the GTT first, if its current caching value * doesn't match. * * Note that this all changes on discrete platforms, starting from DG1, the * set/get caching is no longer supported, and is now rejected. Instead the CPU * caching attributes(WB vs WC) will become an immutable creation time property * for the object, along with the GTT caching level. For now we don't expose any * new uAPI for this, instead on DG1 this is all implicit, although this largely * shouldn't matter since DG1 is coherent by default(without any way of * controlling it). * * Implicit caching rules, starting from DG1: * * - If any of the object placements (see &drm_i915_gem_create_ext_memory_regions) * contain I915_MEMORY_CLASS_DEVICE then the object will be allocated and * mapped as write-combined only. * * - Everything else is always allocated and mapped as write-back, with the * guarantee that everything is also coherent with the GPU. * * Note that this is likely to change in the future again, where we might need * more flexibility on future devices, so making this all explicit as part of a * new &drm_i915_gem_create_ext extension is probable. * * Side note: Part of the reason for this is that changing the at-allocation-time CPU * caching attributes for the pages might be required(and is expensive) if we * need to then CPU map the pages later with different caching attributes. This * inconsistent caching behaviour, while supported on x86, is not universally * supported on other architectures. So for simplicity we opt for setting * everything at creation time, whilst also making it immutable, on discrete * platforms.
*/ struct drm_i915_gem_caching { /** * @handle: Handle of the buffer to set/get the caching level.
*/
__u32 handle;
/** * @caching: The GTT caching level to apply or possible return value. * * The supported @caching values: * * I915_CACHING_NONE: * * GPU access is not coherent with CPU caches. Default for machines * without an LLC. This means manual flushing might be needed, if we * want GPU access to be coherent. * * I915_CACHING_CACHED: * * GPU access is coherent with CPU caches and furthermore the data is * cached in last-level caches shared between CPU cores and the GPU GT. * * I915_CACHING_DISPLAY: * * Special GPU caching mode which is coherent with the scanout engines. * Transparently falls back to I915_CACHING_NONE on platforms where no * special cache mode (like write-through or gfdt flushing) is * available. The kernel automatically sets this mode when using a * buffer as a scanout target. Userspace can manually set this mode to * avoid a costly stall and clflush in the hotpath of drawing the first * frame.
*/ #define I915_CACHING_NONE 0 #define I915_CACHING_CACHED 1 #define I915_CACHING_DISPLAY 2
__u32 caching;
};
#define I915_TILING_NONE 0 #define I915_TILING_X 1 #define I915_TILING_Y 2 /* * Do not add new tiling types here. The I915_TILING_* values are for * de-tiling fence registers that no longer exist on modern platforms. Although * the hardware may support new types of tiling in general (e.g., Tile4), we * do not need to add them to the uapi that is specific to now-defunct ioctls.
*/ #define I915_TILING_LAST I915_TILING_Y
#define I915_BIT_6_SWIZZLE_NONE 0 #define I915_BIT_6_SWIZZLE_9 1 #define I915_BIT_6_SWIZZLE_9_10 2 #define I915_BIT_6_SWIZZLE_9_11 3 #define I915_BIT_6_SWIZZLE_9_10_11 4 /* Not seen by userland */ #define I915_BIT_6_SWIZZLE_UNKNOWN 5 /* Seen by userland. */ #define I915_BIT_6_SWIZZLE_9_17 6 #define I915_BIT_6_SWIZZLE_9_10_17 7
struct drm_i915_gem_set_tiling { /** Handle of the buffer to have its tiling state updated */
__u32 handle;
/** * Tiling mode for the object (I915_TILING_NONE, I915_TILING_X, * I915_TILING_Y). * * This value is to be set on request, and will be updated by the * kernel on successful return with the actual chosen tiling layout. * * The tiling mode may be demoted to I915_TILING_NONE when the system * has bit 6 swizzling that can't be managed correctly by GEM. * * Buffer contents become undefined when changing tiling_mode.
*/
__u32 tiling_mode;
/** * Stride in bytes for the object when in I915_TILING_X or * I915_TILING_Y.
*/
__u32 stride;
/** * Returned address bit 6 swizzling required for CPU access through * mmap mapping.
*/
__u32 swizzle_mode;
};
struct drm_i915_gem_get_tiling { /** Handle of the buffer to get tiling state for. */
__u32 handle;
/** * Current tiling mode for the object (I915_TILING_NONE, I915_TILING_X, * I915_TILING_Y).
*/
__u32 tiling_mode;
/** * Returned address bit 6 swizzling required for CPU access through * mmap mapping.
*/
__u32 swizzle_mode;
/** * Returned address bit 6 swizzling required for CPU access through * mmap mapping whilst bound.
*/
__u32 phys_swizzle_mode;
};
struct drm_i915_gem_get_aperture { /** Total size of the aperture used by i915_gem_execbuffer, in bytes */
__u64 aper_size;
/** * Available space in the aperture used by i915_gem_execbuffer, in * bytes
*/
__u64 aper_available_size;
};
struct drm_i915_get_pipe_from_crtc_id { /** ID of CRTC being requested **/
__u32 crtc_id;
Die Informationen auf dieser Webseite wurden
nach bestem Wissen sorgfältig zusammengestellt. Es wird jedoch weder Vollständigkeit, noch Richtigkeit,
noch Qualität der bereit gestellten Informationen zugesichert.
Bemerkung:
Die farbliche Syntaxdarstellung und die Messung sind noch experimentell.
