/* * 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. * */ #ifndef _UAPI_I915_DRM_H_ #define _UAPI_I915_DRM_H_ #include "drm.h" #if defined(__cplusplus) extern "C" { #endif /* 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 … #define I915_ERROR_UEVENT … #define I915_RESET_UEVENT … /** * 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 { … }; /* * 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 { … }; /** * 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 { … }; /** * 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 { … }; /** * DOC: perf_events exposed by i915 through /sys/bus/event_sources/drivers/i915 * */ enum drm_i915_pmu_engine_sample { … }; #define I915_PMU_SAMPLE_BITS … #define I915_PMU_SAMPLE_MASK … #define I915_PMU_SAMPLE_INSTANCE_BITS … #define I915_PMU_CLASS_SHIFT … #define __I915_PMU_ENGINE(class, instance, sample) … #define I915_PMU_ENGINE_BUSY(class, instance) … #define I915_PMU_ENGINE_WAIT(class, instance) … #define I915_PMU_ENGINE_SEMA(class, instance) … /* * Top 4 bits of every non-engine counter are GT id. */ #define __I915_PMU_GT_SHIFT … #define ___I915_PMU_OTHER(gt, x) … #define __I915_PMU_OTHER(x) … #define I915_PMU_ACTUAL_FREQUENCY … #define I915_PMU_REQUESTED_FREQUENCY … #define I915_PMU_INTERRUPTS … #define I915_PMU_RC6_RESIDENCY … #define I915_PMU_SOFTWARE_GT_AWAKE_TIME … #define I915_PMU_LAST … #define __I915_PMU_ACTUAL_FREQUENCY(gt) … #define __I915_PMU_REQUESTED_FREQUENCY(gt) … #define __I915_PMU_INTERRUPTS(gt) … #define __I915_PMU_RC6_RESIDENCY(gt) … #define __I915_PMU_SOFTWARE_GT_AWAKE_TIME(gt) … /* Each region is a minimum of 16k, and there are at most 255 of them. */ #define I915_NR_TEX_REGIONS … #define I915_LOG_MIN_TEX_REGION_SIZE … drm_i915_init_t; drm_i915_sarea_t; /* due to userspace building against these headers we need some compat here */ #define planeA_x … #define planeA_y … #define planeA_w … #define planeA_h … #define planeB_x … #define planeB_y … #define planeB_w … #define planeB_h … /* Flags for perf_boxes */ #define I915_BOX_RING_EMPTY … #define I915_BOX_FLIP … #define I915_BOX_WAIT … #define I915_BOX_TEXTURE_LOAD … #define I915_BOX_LOST_CONTEXT … /* * i915 specific ioctls. * * The device specific ioctl range is [DRM_COMMAND_BASE, DRM_COMMAND_END) ie * [0x40, 0xa0) (a0 is excluded). The numbers below are defined as offset * against DRM_COMMAND_BASE and should be between [0x0, 0x60). */ #define DRM_I915_INIT … #define DRM_I915_FLUSH … #define DRM_I915_FLIP … #define DRM_I915_BATCHBUFFER … #define DRM_I915_IRQ_EMIT … #define DRM_I915_IRQ_WAIT … #define DRM_I915_GETPARAM … #define DRM_I915_SETPARAM … #define DRM_I915_ALLOC … #define DRM_I915_FREE … #define DRM_I915_INIT_HEAP … #define DRM_I915_CMDBUFFER … #define DRM_I915_DESTROY_HEAP … #define DRM_I915_SET_VBLANK_PIPE … #define DRM_I915_GET_VBLANK_PIPE … #define DRM_I915_VBLANK_SWAP … #define DRM_I915_HWS_ADDR … #define DRM_I915_GEM_INIT … #define DRM_I915_GEM_EXECBUFFER … #define DRM_I915_GEM_PIN … #define DRM_I915_GEM_UNPIN … #define DRM_I915_GEM_BUSY … #define DRM_I915_GEM_THROTTLE … #define DRM_I915_GEM_ENTERVT … #define DRM_I915_GEM_LEAVEVT … #define DRM_I915_GEM_CREATE … #define DRM_I915_GEM_PREAD … #define DRM_I915_GEM_PWRITE … #define DRM_I915_GEM_MMAP … #define DRM_I915_GEM_SET_DOMAIN … #define DRM_I915_GEM_SW_FINISH … #define DRM_I915_GEM_SET_TILING … #define DRM_I915_GEM_GET_TILING … #define DRM_I915_GEM_GET_APERTURE … #define DRM_I915_GEM_MMAP_GTT … #define DRM_I915_GET_PIPE_FROM_CRTC_ID … #define DRM_I915_GEM_MADVISE … #define DRM_I915_OVERLAY_PUT_IMAGE … #define DRM_I915_OVERLAY_ATTRS … #define DRM_I915_GEM_EXECBUFFER2 … #define DRM_I915_GEM_EXECBUFFER2_WR … #define DRM_I915_GET_SPRITE_COLORKEY … #define DRM_I915_SET_SPRITE_COLORKEY … #define DRM_I915_GEM_WAIT … #define DRM_I915_GEM_CONTEXT_CREATE … #define DRM_I915_GEM_CONTEXT_DESTROY … #define DRM_I915_GEM_SET_CACHING … #define DRM_I915_GEM_GET_CACHING … #define DRM_I915_REG_READ … #define DRM_I915_GET_RESET_STATS … #define DRM_I915_GEM_USERPTR … #define DRM_I915_GEM_CONTEXT_GETPARAM … #define DRM_I915_GEM_CONTEXT_SETPARAM … #define DRM_I915_PERF_OPEN … #define DRM_I915_PERF_ADD_CONFIG … #define DRM_I915_PERF_REMOVE_CONFIG … #define DRM_I915_QUERY … #define DRM_I915_GEM_VM_CREATE … #define DRM_I915_GEM_VM_DESTROY … #define DRM_I915_GEM_CREATE_EXT … /* Must be kept compact -- no holes */ #define DRM_IOCTL_I915_INIT … #define DRM_IOCTL_I915_FLUSH … #define DRM_IOCTL_I915_FLIP … #define DRM_IOCTL_I915_BATCHBUFFER … #define DRM_IOCTL_I915_IRQ_EMIT … #define DRM_IOCTL_I915_IRQ_WAIT … #define DRM_IOCTL_I915_GETPARAM … #define DRM_IOCTL_I915_SETPARAM … #define DRM_IOCTL_I915_ALLOC … #define DRM_IOCTL_I915_FREE … #define DRM_IOCTL_I915_INIT_HEAP … #define DRM_IOCTL_I915_CMDBUFFER … #define DRM_IOCTL_I915_DESTROY_HEAP … #define DRM_IOCTL_I915_SET_VBLANK_PIPE … #define DRM_IOCTL_I915_GET_VBLANK_PIPE … #define DRM_IOCTL_I915_VBLANK_SWAP … #define DRM_IOCTL_I915_HWS_ADDR … #define DRM_IOCTL_I915_GEM_INIT … #define DRM_IOCTL_I915_GEM_EXECBUFFER … #define DRM_IOCTL_I915_GEM_EXECBUFFER2 … #define DRM_IOCTL_I915_GEM_EXECBUFFER2_WR … #define DRM_IOCTL_I915_GEM_PIN … #define DRM_IOCTL_I915_GEM_UNPIN … #define DRM_IOCTL_I915_GEM_BUSY … #define DRM_IOCTL_I915_GEM_SET_CACHING … #define DRM_IOCTL_I915_GEM_GET_CACHING … #define DRM_IOCTL_I915_GEM_THROTTLE … #define DRM_IOCTL_I915_GEM_ENTERVT … #define DRM_IOCTL_I915_GEM_LEAVEVT … #define DRM_IOCTL_I915_GEM_CREATE … #define DRM_IOCTL_I915_GEM_CREATE_EXT … #define DRM_IOCTL_I915_GEM_PREAD … #define DRM_IOCTL_I915_GEM_PWRITE … #define DRM_IOCTL_I915_GEM_MMAP … #define DRM_IOCTL_I915_GEM_MMAP_GTT … #define DRM_IOCTL_I915_GEM_MMAP_OFFSET … #define DRM_IOCTL_I915_GEM_SET_DOMAIN … #define DRM_IOCTL_I915_GEM_SW_FINISH … #define DRM_IOCTL_I915_GEM_SET_TILING … #define DRM_IOCTL_I915_GEM_GET_TILING … #define DRM_IOCTL_I915_GEM_GET_APERTURE … #define DRM_IOCTL_I915_GET_PIPE_FROM_CRTC_ID … #define DRM_IOCTL_I915_GEM_MADVISE … #define DRM_IOCTL_I915_OVERLAY_PUT_IMAGE … #define DRM_IOCTL_I915_OVERLAY_ATTRS … #define DRM_IOCTL_I915_SET_SPRITE_COLORKEY … #define DRM_IOCTL_I915_GET_SPRITE_COLORKEY … #define DRM_IOCTL_I915_GEM_WAIT … #define DRM_IOCTL_I915_GEM_CONTEXT_CREATE … #define DRM_IOCTL_I915_GEM_CONTEXT_CREATE_EXT … #define DRM_IOCTL_I915_GEM_CONTEXT_DESTROY … #define DRM_IOCTL_I915_REG_READ … #define DRM_IOCTL_I915_GET_RESET_STATS … #define DRM_IOCTL_I915_GEM_USERPTR … #define DRM_IOCTL_I915_GEM_CONTEXT_GETPARAM … #define DRM_IOCTL_I915_GEM_CONTEXT_SETPARAM … #define DRM_IOCTL_I915_PERF_OPEN … #define DRM_IOCTL_I915_PERF_ADD_CONFIG … #define DRM_IOCTL_I915_PERF_REMOVE_CONFIG … #define DRM_IOCTL_I915_QUERY … #define DRM_IOCTL_I915_GEM_VM_CREATE … #define DRM_IOCTL_I915_GEM_VM_DESTROY … /* Allow drivers to submit batchbuffers directly to hardware, relying * on the security mechanisms provided by hardware. */ 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. */ drm_i915_cmdbuffer_t; /* Userspace can request & wait on irq's: */ drm_i915_irq_emit_t; drm_i915_irq_wait_t; /* * Different modes of per-process Graphics Translation Table, * see I915_PARAM_HAS_ALIASING_PPGTT */ #define I915_GEM_PPGTT_NONE … #define I915_GEM_PPGTT_ALIASING … #define I915_GEM_PPGTT_FULL … /* Ioctl to query kernel params: */ #define I915_PARAM_IRQ_ACTIVE … #define I915_PARAM_ALLOW_BATCHBUFFER … #define I915_PARAM_LAST_DISPATCH … #define I915_PARAM_CHIPSET_ID … #define I915_PARAM_HAS_GEM … #define I915_PARAM_NUM_FENCES_AVAIL … #define I915_PARAM_HAS_OVERLAY … #define I915_PARAM_HAS_PAGEFLIPPING … #define I915_PARAM_HAS_EXECBUF2 … #define I915_PARAM_HAS_BSD … #define I915_PARAM_HAS_BLT … #define I915_PARAM_HAS_RELAXED_FENCING … #define I915_PARAM_HAS_COHERENT_RINGS … #define I915_PARAM_HAS_EXEC_CONSTANTS … #define I915_PARAM_HAS_RELAXED_DELTA … #define I915_PARAM_HAS_GEN7_SOL_RESET … #define I915_PARAM_HAS_LLC … #define I915_PARAM_HAS_ALIASING_PPGTT … #define I915_PARAM_HAS_WAIT_TIMEOUT … #define I915_PARAM_HAS_SEMAPHORES … #define I915_PARAM_HAS_PRIME_VMAP_FLUSH … #define I915_PARAM_HAS_VEBOX … #define I915_PARAM_HAS_SECURE_BATCHES … #define I915_PARAM_HAS_PINNED_BATCHES … #define I915_PARAM_HAS_EXEC_NO_RELOC … #define I915_PARAM_HAS_EXEC_HANDLE_LUT … #define I915_PARAM_HAS_WT … #define I915_PARAM_CMD_PARSER_VERSION … #define I915_PARAM_HAS_COHERENT_PHYS_GTT … #define I915_PARAM_MMAP_VERSION … #define I915_PARAM_HAS_BSD2 … #define I915_PARAM_REVISION … #define I915_PARAM_SUBSLICE_TOTAL … #define I915_PARAM_EU_TOTAL … #define I915_PARAM_HAS_GPU_RESET … #define I915_PARAM_HAS_RESOURCE_STREAMER … #define I915_PARAM_HAS_EXEC_SOFTPIN … #define I915_PARAM_HAS_POOLED_EU … #define I915_PARAM_MIN_EU_IN_POOL … #define I915_PARAM_MMAP_GTT_VERSION … /* * 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 … #define I915_SCHEDULER_CAP_ENABLED … #define I915_SCHEDULER_CAP_PRIORITY … #define I915_SCHEDULER_CAP_PREEMPTION … #define I915_SCHEDULER_CAP_SEMAPHORES … #define I915_SCHEDULER_CAP_ENGINE_BUSY_STATS … /* * 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 … /* * 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 … /* 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 … /* 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 … /* 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 … #define I915_PARAM_SLICE_MASK … /* Assuming it's uniform for each slice, this queries the mask of subslices * per-slice for this system. */ #define I915_PARAM_SUBSLICE_MASK … /* * 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 … /* 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 … /* * 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 … /* 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 … /* * 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 … /* * 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 … /* * 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 … /* 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 … /* Query if the kernel supports the I915_USERPTR_PROBE flag. */ #define I915_PARAM_HAS_USERPTR_PROBE … /* * 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 … /* * 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 … /* * 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 … /* Must be kept compact -- no holes and well documented */ /** * struct drm_i915_getparam - Driver parameter query structure. */ struct drm_i915_getparam { … }; /** * typedef drm_i915_getparam_t - Driver parameter query structure. * See struct drm_i915_getparam. */ drm_i915_getparam_t; /* Ioctl to set kernel params: */ #define I915_SETPARAM_USE_MI_BATCHBUFFER_START … #define I915_SETPARAM_TEX_LRU_LOG_GRANULARITY … #define I915_SETPARAM_ALLOW_BATCHBUFFER … #define I915_SETPARAM_NUM_USED_FENCES … /* Must be kept compact -- no holes */ drm_i915_setparam_t; /* A memory manager for regions of shared memory: */ #define I915_MEM_REGION_AGP … drm_i915_mem_alloc_t; drm_i915_mem_free_t; drm_i915_mem_init_heap_t; /* Allow memory manager to be torn down and re-initialized (eg on * rotate): */ drm_i915_mem_destroy_heap_t; /* Allow X server to configure which pipes to monitor for vblank signals */ #define DRM_I915_VBLANK_PIPE_A … #define DRM_I915_VBLANK_PIPE_B … drm_i915_vblank_pipe_t; /* Schedule buffer swap at given vertical blank: */ drm_i915_vblank_swap_t; drm_i915_hws_addr_t; struct drm_i915_gem_init { … }; struct drm_i915_gem_create { … }; struct drm_i915_gem_pread { … }; struct drm_i915_gem_pwrite { … }; struct drm_i915_gem_mmap { … }; struct drm_i915_gem_mmap_gtt { … }; /** * 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 { … }; /** * 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 { … }; struct drm_i915_gem_sw_finish { … }; struct drm_i915_gem_relocation_entry { … }; /** @{ * 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 … /** Render cache, used by 2D and 3D drawing */ #define I915_GEM_DOMAIN_RENDER … /** Sampler cache, used by texture engine */ #define I915_GEM_DOMAIN_SAMPLER … /** Command queue, used to load batch buffers */ #define I915_GEM_DOMAIN_COMMAND … /** Instruction cache, used by shader programs */ #define I915_GEM_DOMAIN_INSTRUCTION … /** Vertex address cache */ #define I915_GEM_DOMAIN_VERTEX … /** GTT domain - aperture and scanout */ #define I915_GEM_DOMAIN_GTT … /** WC domain - uncached access */ #define I915_GEM_DOMAIN_WC … /** @} */ struct drm_i915_gem_exec_object { … }; /* DRM_IOCTL_I915_GEM_EXECBUFFER was removed in Linux 5.13 */ struct drm_i915_gem_execbuffer { … }; struct drm_i915_gem_exec_object2 { … }; /** * 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 { … }; /** * 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 { … }; /** * struct drm_i915_gem_execbuffer2 - Structure for DRM_I915_GEM_EXECBUFFER2 * ioctl. */ struct drm_i915_gem_execbuffer2 { … }; #define I915_EXEC_CONTEXT_ID_MASK … #define i915_execbuffer2_set_context_id(eb2, context) … #define i915_execbuffer2_get_context_id(eb2) … struct drm_i915_gem_pin { … }; struct drm_i915_gem_unpin { … }; struct drm_i915_gem_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 { … }; #define I915_TILING_NONE … #define I915_TILING_X … #define I915_TILING_Y … /* * 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 … #define I915_BIT_6_SWIZZLE_NONE … #define I915_BIT_6_SWIZZLE_9 … #define I915_BIT_6_SWIZZLE_9_10 … #define I915_BIT_6_SWIZZLE_9_11 … #define I915_BIT_6_SWIZZLE_9_10_11 … /* Not seen by userland */ #define I915_BIT_6_SWIZZLE_UNKNOWN … /* Seen by userland. */ #define I915_BIT_6_SWIZZLE_9_17 … #define I915_BIT_6_SWIZZLE_9_10_17 … struct drm_i915_gem_set_tiling { … }; struct drm_i915_gem_get_tiling { … }; struct drm_i915_gem_get_aperture { … }; struct drm_i915_get_pipe_from_crtc_id { … }; #define I915_MADV_WILLNEED … #define I915_MADV_DONTNEED … #define __I915_MADV_PURGED … struct drm_i915_gem_madvise { … }; /* flags */ #define I915_OVERLAY_TYPE_MASK … #define I915_OVERLAY_YUV_PLANAR … #define I915_OVERLAY_YUV_PACKED … #define I915_OVERLAY_RGB … #define I915_OVERLAY_DEPTH_MASK … #define I915_OVERLAY_RGB24 … #define I915_OVERLAY_RGB16 … #define I915_OVERLAY_RGB15 … #define I915_OVERLAY_YUV422 … #define I915_OVERLAY_YUV411 … #define I915_OVERLAY_YUV420 … #define I915_OVERLAY_YUV410 … #define I915_OVERLAY_SWAP_MASK … #define I915_OVERLAY_NO_SWAP … #define I915_OVERLAY_UV_SWAP … #define I915_OVERLAY_Y_SWAP … #define I915_OVERLAY_Y_AND_UV_SWAP … #define I915_OVERLAY_FLAGS_MASK … #define I915_OVERLAY_ENABLE … struct drm_intel_overlay_put_image { … }; /* flags */ #define I915_OVERLAY_UPDATE_ATTRS … #define I915_OVERLAY_UPDATE_GAMMA … #define I915_OVERLAY_DISABLE_DEST_COLORKEY … struct drm_intel_overlay_attrs { … }; /* * Intel sprite handling * * Color keying works with a min/mask/max tuple. Both source and destination * color keying is allowed. * * Source keying: * Sprite pixels within the min & max values, masked against the color channels * specified in the mask field, will be transparent. All other pixels will * be displayed on top of the primary plane. For RGB surfaces, only the min * and mask fields will be used; ranged compares are not allowed. * * Destination keying: * Primary plane pixels that match the min value, masked against the color * channels specified in the mask field, will be replaced by corresponding * pixels from the sprite plane. * * Note that source & destination keying are exclusive; only one can be * active on a given plane. */ #define I915_SET_COLORKEY_NONE … #define I915_SET_COLORKEY_DESTINATION … #define I915_SET_COLORKEY_SOURCE … struct drm_intel_sprite_colorkey { … }; struct drm_i915_gem_wait { … }; struct drm_i915_gem_context_create { … }; /** * struct drm_i915_gem_context_create_ext - Structure for creating contexts. */ struct drm_i915_gem_context_create_ext { … }; /** * struct drm_i915_gem_context_param - Context parameter to set or query. */ struct drm_i915_gem_context_param { … }; /* * Context SSEU programming * * It may be necessary for either functional or performance reason to configure * a context to run with a reduced number of SSEU (where SSEU stands for Slice/ * Sub-slice/EU). * * This is done by configuring SSEU configuration using the below * @struct drm_i915_gem_context_param_sseu for every supported engine which * userspace intends to use. * * Not all GPUs or engines support this functionality in which case an error * code -ENODEV will be returned. * * Also, flexibility of possible SSEU configuration permutations varies between * GPU generations and software imposed limitations. Requesting such a * combination will return an error code of -EINVAL. * * NOTE: When perf/OA is active the context's SSEU configuration is ignored in * favour of a single global setting. */ struct drm_i915_gem_context_param_sseu { … }; /** * DOC: Virtual Engine uAPI * * Virtual engine is a concept where userspace is able to configure a set of * physical engines, submit a batch buffer, and let the driver execute it on any * engine from the set as it sees fit. * * This is primarily useful on parts which have multiple instances of a same * class engine, like for example GT3+ Skylake parts with their two VCS engines. * * For instance userspace can enumerate all engines of a certain class using the * previously described `Engine Discovery uAPI`_. After that userspace can * create a GEM context with a placeholder slot for the virtual engine (using * `I915_ENGINE_CLASS_INVALID` and `I915_ENGINE_CLASS_INVALID_NONE` for class * and instance respectively) and finally using the * `I915_CONTEXT_ENGINES_EXT_LOAD_BALANCE` extension place a virtual engine in * the same reserved slot. * * Example of creating a virtual engine and submitting a batch buffer to it: * * .. code-block:: C * * I915_DEFINE_CONTEXT_ENGINES_LOAD_BALANCE(virtual, 2) = { * .base.name = I915_CONTEXT_ENGINES_EXT_LOAD_BALANCE, * .engine_index = 0, // Place this virtual engine into engine map slot 0 * .num_siblings = 2, * .engines = { { I915_ENGINE_CLASS_VIDEO, 0 }, * { I915_ENGINE_CLASS_VIDEO, 1 }, }, * }; * I915_DEFINE_CONTEXT_PARAM_ENGINES(engines, 1) = { * .engines = { { I915_ENGINE_CLASS_INVALID, * I915_ENGINE_CLASS_INVALID_NONE } }, * .extensions = to_user_pointer(&virtual), // Chains after load_balance extension * }; * struct drm_i915_gem_context_create_ext_setparam p_engines = { * .base = { * .name = I915_CONTEXT_CREATE_EXT_SETPARAM, * }, * .param = { * .param = I915_CONTEXT_PARAM_ENGINES, * .value = to_user_pointer(&engines), * .size = sizeof(engines), * }, * }; * struct drm_i915_gem_context_create_ext create = { * .flags = I915_CONTEXT_CREATE_FLAGS_USE_EXTENSIONS, * .extensions = to_user_pointer(&p_engines); * }; * * ctx_id = gem_context_create_ext(drm_fd, &create); * * // Now we have created a GEM context with its engine map containing a * // single virtual engine. Submissions to this slot can go either to * // vcs0 or vcs1, depending on the load balancing algorithm used inside * // the driver. The load balancing is dynamic from one batch buffer to * // another and transparent to userspace. * * ... * execbuf.rsvd1 = ctx_id; * execbuf.flags = 0; // Submits to index 0 which is the virtual engine * gem_execbuf(drm_fd, &execbuf); */ /* * i915_context_engines_load_balance: * * Enable load balancing across this set of engines. * * Into the I915_EXEC_DEFAULT slot [0], a virtual engine is created that when * used will proxy the execbuffer request onto one of the set of engines * in such a way as to distribute the load evenly across the set. * * The set of engines must be compatible (e.g. the same HW class) as they * will share the same logical GPU context and ring. * * To intermix rendering with the virtual engine and direct rendering onto * the backing engines (bypassing the load balancing proxy), the context must * be defined to use a single timeline for all engines. */ struct i915_context_engines_load_balance { … } __attribute__((packed)); #define I915_DEFINE_CONTEXT_ENGINES_LOAD_BALANCE(name__, N__) … /* * i915_context_engines_bond: * * Constructed bonded pairs for execution within a virtual engine. * * All engines are equal, but some are more equal than others. Given * the distribution of resources in the HW, it may be preferable to run * a request on a given subset of engines in parallel to a request on a * specific engine. We enable this selection of engines within a virtual * engine by specifying bonding pairs, for any given master engine we will * only execute on one of the corresponding siblings within the virtual engine. * * To execute a request in parallel on the master engine and a sibling requires * coordination with a I915_EXEC_FENCE_SUBMIT. */ struct i915_context_engines_bond { … } __attribute__((packed)); #define I915_DEFINE_CONTEXT_ENGINES_BOND(name__, N__) … /** * struct i915_context_engines_parallel_submit - Configure engine for * parallel submission. * * Setup a slot in the context engine map to allow multiple BBs to be submitted * in a single execbuf IOCTL. Those BBs will then be scheduled to run on the GPU * in parallel. Multiple hardware contexts are created internally in the i915 to * run these BBs. Once a slot is configured for N BBs only N BBs can be * submitted in each execbuf IOCTL and this is implicit behavior e.g. The user * doesn't tell the execbuf IOCTL there are N BBs, the execbuf IOCTL knows how * many BBs there are based on the slot's configuration. The N BBs are the last * N buffer objects or first N if I915_EXEC_BATCH_FIRST is set. * * The default placement behavior is to create implicit bonds between each * context if each context maps to more than 1 physical engine (e.g. context is * a virtual engine). Also we only allow contexts of same engine class and these * contexts must be in logically contiguous order. Examples of the placement * behavior are described below. Lastly, the default is to not allow BBs to be * preempted mid-batch. Rather insert coordinated preemption points on all * hardware contexts between each set of BBs. Flags could be added in the future * to change both of these default behaviors. * * Returns -EINVAL if hardware context placement configuration is invalid or if * the placement configuration isn't supported on the platform / submission * interface. * Returns -ENODEV if extension isn't supported on the platform / submission * interface. * * .. code-block:: none * * Examples syntax: * CS[X] = generic engine of same class, logical instance X * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE * * Example 1 pseudo code: * set_engines(INVALID) * set_parallel(engine_index=0, width=2, num_siblings=1, * engines=CS[0],CS[1]) * * Results in the following valid placement: * CS[0], CS[1] * * Example 2 pseudo code: * set_engines(INVALID) * set_parallel(engine_index=0, width=2, num_siblings=2, * engines=CS[0],CS[2],CS[1],CS[3]) * * Results in the following valid placements: * CS[0], CS[1] * CS[2], CS[3] * * This can be thought of as two virtual engines, each containing two * engines thereby making a 2D array. However, there are bonds tying the * entries together and placing restrictions on how they can be scheduled. * Specifically, the scheduler can choose only vertical columns from the 2D * array. That is, CS[0] is bonded to CS[1] and CS[2] to CS[3]. So if the * scheduler wants to submit to CS[0], it must also choose CS[1] and vice * versa. Same for CS[2] requires also using CS[3]. * VE[0] = CS[0], CS[2] * VE[1] = CS[1], CS[3] * * Example 3 pseudo code: * set_engines(INVALID) * set_parallel(engine_index=0, width=2, num_siblings=2, * engines=CS[0],CS[1],CS[1],CS[3]) * * Results in the following valid and invalid placements: * CS[0], CS[1] * CS[1], CS[3] - Not logically contiguous, return -EINVAL */ struct i915_context_engines_parallel_submit { … } __packed; #define I915_DEFINE_CONTEXT_ENGINES_PARALLEL_SUBMIT(name__, N__) … /** * DOC: Context Engine Map uAPI * * Context engine map is a new way of addressing engines when submitting batch- * buffers, replacing the existing way of using identifiers like `I915_EXEC_BLT` * inside the flags field of `struct drm_i915_gem_execbuffer2`. * * To use it created GEM contexts need to be configured with a list of engines * the user is intending to submit to. This is accomplished using the * `I915_CONTEXT_PARAM_ENGINES` parameter and `struct * i915_context_param_engines`. * * For such contexts the `I915_EXEC_RING_MASK` field becomes an index into the * configured map. * * Example of creating such context and submitting against it: * * .. code-block:: C * * I915_DEFINE_CONTEXT_PARAM_ENGINES(engines, 2) = { * .engines = { { I915_ENGINE_CLASS_RENDER, 0 }, * { I915_ENGINE_CLASS_COPY, 0 } } * }; * struct drm_i915_gem_context_create_ext_setparam p_engines = { * .base = { * .name = I915_CONTEXT_CREATE_EXT_SETPARAM, * }, * .param = { * .param = I915_CONTEXT_PARAM_ENGINES, * .value = to_user_pointer(&engines), * .size = sizeof(engines), * }, * }; * struct drm_i915_gem_context_create_ext create = { * .flags = I915_CONTEXT_CREATE_FLAGS_USE_EXTENSIONS, * .extensions = to_user_pointer(&p_engines); * }; * * ctx_id = gem_context_create_ext(drm_fd, &create); * * // We have now created a GEM context with two engines in the map: * // Index 0 points to rcs0 while index 1 points to bcs0. Other engines * // will not be accessible from this context. * * ... * execbuf.rsvd1 = ctx_id; * execbuf.flags = 0; // Submits to index 0, which is rcs0 for this context * gem_execbuf(drm_fd, &execbuf); * * ... * execbuf.rsvd1 = ctx_id; * execbuf.flags = 1; // Submits to index 0, which is bcs0 for this context * gem_execbuf(drm_fd, &execbuf); */ struct i915_context_param_engines { … } __attribute__((packed)); #define I915_DEFINE_CONTEXT_PARAM_ENGINES(name__, N__) … struct i915_gem_context_param_context_image { … } __attribute__((packed)); /** * struct drm_i915_gem_context_create_ext_setparam - Context parameter * to set or query during context creation. */ struct drm_i915_gem_context_create_ext_setparam { … }; struct drm_i915_gem_context_destroy { … }; /** * struct drm_i915_gem_vm_control - Structure to create or destroy VM. * * DRM_I915_GEM_VM_CREATE - * * Create a new virtual memory address space (ppGTT) for use within a context * on the same file. Extensions can be provided to configure exactly how the * address space is setup upon creation. * * The id of new VM (bound to the fd) for use with I915_CONTEXT_PARAM_VM is * returned in the outparam @id. * * An extension chain maybe provided, starting with @extensions, and terminated * by the @next_extension being 0. Currently, no extensions are defined. * * DRM_I915_GEM_VM_DESTROY - * * Destroys a previously created VM id, specified in @vm_id. * * No extensions or flags are allowed currently, and so must be zero. */ struct drm_i915_gem_vm_control { … }; struct drm_i915_reg_read { … }; /* Known registers: * * Render engine timestamp - 0x2358 + 64bit - gen7+ * - Note this register returns an invalid value if using the default * single instruction 8byte read, in order to workaround that pass * flag I915_REG_READ_8B_WA in offset field. * */ /* * struct drm_i915_reset_stats - Return global reset and other context stats * * Driver keeps few stats for each contexts and also global reset count. * This struct can be used to query those stats. */ struct drm_i915_reset_stats { … }; /** * struct drm_i915_gem_userptr - Create GEM object from user allocated memory. * * Userptr objects have several restrictions on what ioctls can be used with the * object handle. */ struct drm_i915_gem_userptr { … }; enum drm_i915_oa_format { … }; enum drm_i915_perf_property_id { … }; struct drm_i915_perf_open_param { … }; /* * Enable data capture for a stream that was either opened in a disabled state * via I915_PERF_FLAG_DISABLED or was later disabled via * I915_PERF_IOCTL_DISABLE. * * It is intended to be cheaper to disable and enable a stream than it may be * to close and re-open a stream with the same configuration. * * It's undefined whether any pending data for the stream will be lost. * * This ioctl is available in perf revision 1. */ #define I915_PERF_IOCTL_ENABLE … /* * Disable data capture for a stream. * * It is an error to try and read a stream that is disabled. * * This ioctl is available in perf revision 1. */ #define I915_PERF_IOCTL_DISABLE … /* * Change metrics_set captured by a stream. * * If the stream is bound to a specific context, the configuration change * will performed inline with that context such that it takes effect before * the next execbuf submission. * * Returns the previously bound metrics set id, or a negative error code. * * This ioctl is available in perf revision 2. */ #define I915_PERF_IOCTL_CONFIG … /* * Common to all i915 perf records */ struct drm_i915_perf_record_header { … }; enum drm_i915_perf_record_type { … }; /** * struct drm_i915_perf_oa_config * * Structure to upload perf dynamic configuration into the kernel. */ struct drm_i915_perf_oa_config { … }; /** * struct drm_i915_query_item - An individual query for the kernel to process. * * The behaviour is determined by the @query_id. Note that exactly what * @data_ptr is also depends on the specific @query_id. */ struct drm_i915_query_item { … }; /** * struct drm_i915_query - Supply an array of struct drm_i915_query_item for the * kernel to fill out. * * Note that this is generally a two step process for each struct * drm_i915_query_item in the array: * * 1. Call the DRM_IOCTL_I915_QUERY, giving it our array of struct * drm_i915_query_item, with &drm_i915_query_item.length set to zero. The * kernel will then fill in the size, in bytes, which tells userspace how * memory it needs to allocate for the blob(say for an array of properties). * * 2. Next we call DRM_IOCTL_I915_QUERY again, this time with the * &drm_i915_query_item.data_ptr equal to our newly allocated blob. Note that * the &drm_i915_query_item.length should still be the same as what the * kernel previously set. At this point the kernel can fill in the blob. * * Note that for some query items it can make sense for userspace to just pass * in a buffer/blob equal to or larger than the required size. In this case only * a single ioctl call is needed. For some smaller query items this can work * quite well. * */ struct drm_i915_query { … }; /** * struct drm_i915_query_topology_info * * Describes slice/subslice/EU information queried by * %DRM_I915_QUERY_TOPOLOGY_INFO */ struct drm_i915_query_topology_info { … }; /** * DOC: Engine Discovery uAPI * * Engine discovery uAPI is a way of enumerating physical engines present in a * GPU associated with an open i915 DRM file descriptor. This supersedes the old * way of using `DRM_IOCTL_I915_GETPARAM` and engine identifiers like * `I915_PARAM_HAS_BLT`. * * The need for this interface came starting with Icelake and newer GPUs, which * started to establish a pattern of having multiple engines of a same class, * where not all instances were always completely functionally equivalent. * * Entry point for this uapi is `DRM_IOCTL_I915_QUERY` with the * `DRM_I915_QUERY_ENGINE_INFO` as the queried item id. * * Example for getting the list of engines: * * .. code-block:: C * * struct drm_i915_query_engine_info *info; * struct drm_i915_query_item item = { * .query_id = DRM_I915_QUERY_ENGINE_INFO; * }; * struct drm_i915_query query = { * .num_items = 1, * .items_ptr = (uintptr_t)&item, * }; * int err, i; * * // First query the size of the blob we need, this needs to be large * // enough to hold our array of engines. The kernel will fill out the * // item.length for us, which is the number of bytes we need. * // * // Alternatively a large buffer can be allocated straightaway enabling * // querying in one pass, in which case item.length should contain the * // length of the provided buffer. * err = ioctl(fd, DRM_IOCTL_I915_QUERY, &query); * if (err) ... * * info = calloc(1, item.length); * // Now that we allocated the required number of bytes, we call the ioctl * // again, this time with the data_ptr pointing to our newly allocated * // blob, which the kernel can then populate with info on all engines. * item.data_ptr = (uintptr_t)&info; * * err = ioctl(fd, DRM_IOCTL_I915_QUERY, &query); * if (err) ... * * // We can now access each engine in the array * for (i = 0; i < info->num_engines; i++) { * struct drm_i915_engine_info einfo = info->engines[i]; * u16 class = einfo.engine.class; * u16 instance = einfo.engine.instance; * .... * } * * free(info); * * Each of the enumerated engines, apart from being defined by its class and * instance (see `struct i915_engine_class_instance`), also can have flags and * capabilities defined as documented in i915_drm.h. * * For instance video engines which support HEVC encoding will have the * `I915_VIDEO_CLASS_CAPABILITY_HEVC` capability bit set. * * Engine discovery only fully comes to its own when combined with the new way * of addressing engines when submitting batch buffers using contexts with * engine maps configured. */ /** * struct drm_i915_engine_info * * Describes one engine and its capabilities as known to the driver. */ struct drm_i915_engine_info { … }; /** * struct drm_i915_query_engine_info * * Engine info query enumerates all engines known to the driver by filling in * an array of struct drm_i915_engine_info structures. */ struct drm_i915_query_engine_info { … }; /** * struct drm_i915_query_perf_config * * Data written by the kernel with query %DRM_I915_QUERY_PERF_CONFIG and * %DRM_I915_QUERY_GEOMETRY_SUBSLICES. */ struct drm_i915_query_perf_config { … }; /** * enum drm_i915_gem_memory_class - Supported memory classes */ enum drm_i915_gem_memory_class { … }; /** * struct drm_i915_gem_memory_class_instance - Identify particular memory region */ struct drm_i915_gem_memory_class_instance { … }; /** * struct drm_i915_memory_region_info - Describes one region as known to the * driver. * * Note this is using both struct drm_i915_query_item and struct drm_i915_query. * For this new query we are adding the new query id DRM_I915_QUERY_MEMORY_REGIONS * at &drm_i915_query_item.query_id. */ struct drm_i915_memory_region_info { … }; /** * struct drm_i915_query_memory_regions * * The region info query enumerates all regions known to the driver by filling * in an array of struct drm_i915_memory_region_info structures. * * Example for getting the list of supported regions: * * .. code-block:: C * * struct drm_i915_query_memory_regions *info; * struct drm_i915_query_item item = { * .query_id = DRM_I915_QUERY_MEMORY_REGIONS; * }; * struct drm_i915_query query = { * .num_items = 1, * .items_ptr = (uintptr_t)&item, * }; * int err, i; * * // First query the size of the blob we need, this needs to be large * // enough to hold our array of regions. The kernel will fill out the * // item.length for us, which is the number of bytes we need. * err = ioctl(fd, DRM_IOCTL_I915_QUERY, &query); * if (err) ... * * info = calloc(1, item.length); * // Now that we allocated the required number of bytes, we call the ioctl * // again, this time with the data_ptr pointing to our newly allocated * // blob, which the kernel can then populate with the all the region info. * item.data_ptr = (uintptr_t)&info, * * err = ioctl(fd, DRM_IOCTL_I915_QUERY, &query); * if (err) ... * * // We can now access each region in the array * for (i = 0; i < info->num_regions; i++) { * struct drm_i915_memory_region_info mr = info->regions[i]; * u16 class = mr.region.class; * u16 instance = mr.region.instance; * * .... * } * * free(info); */ struct drm_i915_query_memory_regions { … }; /** * struct drm_i915_query_guc_submission_version - query GuC submission interface version */ struct drm_i915_query_guc_submission_version { … }; /** * DOC: GuC HWCONFIG blob uAPI * * The GuC produces a blob with information about the current device. * i915 reads this blob from GuC and makes it available via this uAPI. * * The format and meaning of the blob content are documented in the * Programmer's Reference Manual. */ /** * struct drm_i915_gem_create_ext - Existing gem_create behaviour, with added * extension support using struct i915_user_extension. * * Note that new buffer flags should be added here, at least for the stuff that * is immutable. Previously we would have two ioctls, one to create the object * with gem_create, and another to apply various parameters, however this * creates some ambiguity for the params which are considered immutable. Also in * general we're phasing out the various SET/GET ioctls. */ struct drm_i915_gem_create_ext { … }; /** * struct drm_i915_gem_create_ext_memory_regions - The * I915_GEM_CREATE_EXT_MEMORY_REGIONS extension. * * Set the object with the desired set of placements/regions in priority * order. Each entry must be unique and supported by the device. * * This is provided as an array of struct drm_i915_gem_memory_class_instance, or * an equivalent layout of class:instance pair encodings. See struct * drm_i915_query_memory_regions and DRM_I915_QUERY_MEMORY_REGIONS for how to * query the supported regions for a device. * * As an example, on discrete devices, if we wish to set the placement as * device local-memory we can do something like: * * .. code-block:: C * * struct drm_i915_gem_memory_class_instance region_lmem = { * .memory_class = I915_MEMORY_CLASS_DEVICE, * .memory_instance = 0, * }; * struct drm_i915_gem_create_ext_memory_regions regions = { * .base = { .name = I915_GEM_CREATE_EXT_MEMORY_REGIONS }, * .regions = (uintptr_t)®ion_lmem, * .num_regions = 1, * }; * struct drm_i915_gem_create_ext create_ext = { * .size = 16 * PAGE_SIZE, * .extensions = (uintptr_t)®ions, * }; * * int err = ioctl(fd, DRM_IOCTL_I915_GEM_CREATE_EXT, &create_ext); * if (err) ... * * At which point we get the object handle in &drm_i915_gem_create_ext.handle, * along with the final object size in &drm_i915_gem_create_ext.size, which * should account for any rounding up, if required. * * Note that userspace has no means of knowing the current backing region * for objects where @num_regions is larger than one. The kernel will only * ensure that the priority order of the @regions array is honoured, either * when initially placing the object, or when moving memory around due to * memory pressure * * On Flat-CCS capable HW, compression is supported for the objects residing * in I915_MEMORY_CLASS_DEVICE. When such objects (compressed) have other * memory class in @regions and migrated (by i915, due to memory * constraints) to the non I915_MEMORY_CLASS_DEVICE region, then i915 needs to * decompress the content. But i915 doesn't have the required information to * decompress the userspace compressed objects. * * So i915 supports Flat-CCS, on the objects which can reside only on * I915_MEMORY_CLASS_DEVICE regions. */ struct drm_i915_gem_create_ext_memory_regions { … }; /** * struct drm_i915_gem_create_ext_protected_content - The * I915_OBJECT_PARAM_PROTECTED_CONTENT extension. * * If this extension is provided, buffer contents are expected to be protected * by PXP encryption and require decryption for scan out and processing. This * is only possible on platforms that have PXP enabled, on all other scenarios * using this extension will cause the ioctl to fail and return -ENODEV. The * flags parameter is reserved for future expansion and must currently be set * to zero. * * The buffer contents are considered invalid after a PXP session teardown. * * The encryption is guaranteed to be processed correctly only if the object * is submitted with a context created using the * I915_CONTEXT_PARAM_PROTECTED_CONTENT flag. This will also enable extra checks * at submission time on the validity of the objects involved. * * Below is an example on how to create a protected object: * * .. code-block:: C * * struct drm_i915_gem_create_ext_protected_content protected_ext = { * .base = { .name = I915_GEM_CREATE_EXT_PROTECTED_CONTENT }, * .flags = 0, * }; * struct drm_i915_gem_create_ext create_ext = { * .size = PAGE_SIZE, * .extensions = (uintptr_t)&protected_ext, * }; * * int err = ioctl(fd, DRM_IOCTL_I915_GEM_CREATE_EXT, &create_ext); * if (err) ... */ struct drm_i915_gem_create_ext_protected_content { … }; /** * struct drm_i915_gem_create_ext_set_pat - The * I915_GEM_CREATE_EXT_SET_PAT extension. * * If this extension is provided, the specified caching policy (PAT index) is * applied to the buffer object. * * Below is an example on how to create an object with specific caching policy: * * .. code-block:: C * * struct drm_i915_gem_create_ext_set_pat set_pat_ext = { * .base = { .name = I915_GEM_CREATE_EXT_SET_PAT }, * .pat_index = 0, * }; * struct drm_i915_gem_create_ext create_ext = { * .size = PAGE_SIZE, * .extensions = (uintptr_t)&set_pat_ext, * }; * * int err = ioctl(fd, DRM_IOCTL_I915_GEM_CREATE_EXT, &create_ext); * if (err) ... */ struct drm_i915_gem_create_ext_set_pat { … }; /* ID of the protected content session managed by i915 when PXP is active */ #define I915_PROTECTED_CONTENT_DEFAULT_SESSION … #if defined(__cplusplus) } #endif #endif /* _UAPI_I915_DRM_H_ */
Codebase Browser
linux