Lines Matching defs:engine
159 * engine serving each role. enum drm_i915_gem_engine_class provides a
160 * classification of the role of the engine, which may be used when requesting
176 * There may be more than one engine fulfilling any role within the system.
177 * Each engine of a class is given a unique instance number and therefore
178 * any engine can be specified by its class:instance tuplet. APIs that allow
179 * access to any engine in the system will use struct i915_engine_class_instance
632 * As not every engine across every gen support contexts, the returned
634 * returning a bitmask of each engine class set to true if that class supports
1035 /** Sampler cache, used by texture engine */
1408 * Furthermore, if the object is busy, which engine is busy is only
1410 * (there may be more than one engine in each class). There are race
1417 * the engine classess on which the object is being read, and the
1418 * engine class on which it is currently being written (if any).
1421 * to by any engine (there can only be one, as the GEM implicit
1423 * engine class (offset by 1, I915_ENGINE_CLASS_RENDER is reported as
1430 * The value of each engine class is the same as specified in the
1811 * an index into this array of engines; I915_EXEC_DEFAULT selecting engine[0]
1817 * virtual engine used for load balancing.
1862 * @struct drm_i915_gem_context_param_sseu for every supported engine which
1877 * Engine class & instance to be configured or queried.
1879 struct i915_engine_class_instance engine;
1914 * DOC: Virtual Engine uAPI
1916 * Virtual engine is a concept where userspace is able to configure a set of
1918 * engine from the set as it sees fit.
1921 * class engine, like for example GT3+ Skylake parts with their two VCS engines.
1924 * previously described `Engine Discovery uAPI`_. After that userspace can
1925 * create a GEM context with a placeholder slot for the virtual engine (using
1928 * `I915_CONTEXT_ENGINES_EXT_LOAD_BALANCE` extension place a virtual engine in
1931 * Example of creating a virtual engine and submitting a batch buffer to it:
1937 * .engine_index = 0, // Place this virtual engine into engine map slot 0
1964 * // Now we have created a GEM context with its engine map containing a
1965 * // single virtual engine. Submissions to this slot can go either to
1972 * execbuf.flags = 0; // Submits to index 0 which is the virtual engine
1981 * Into the I915_EXEC_DEFAULT slot [0], a virtual engine is created that when
1988 * To intermix rendering with the virtual engine and direct rendering onto
2016 * Constructed bonded pairs for execution within a virtual engine.
2021 * specific engine. We enable this selection of engines within a virtual
2022 * engine by specifying bonding pairs, for any given master engine we will
2023 * only execute on one of the corresponding siblings within the virtual engine.
2025 * To execute a request in parallel on the master engine and a sibling requires
2033 __u16 virtual_index; /* index of virtual engine in ctx->engines[] */
2053 * DOC: Context Engine Map uAPI
2055 * Context engine map is a new way of addressing engines when submitting batch-
2177 * Render engine timestamp - 0x2358 + 64bit - gen7+
2646 * DOC: Engine Discovery uAPI
2648 * Engine discovery uAPI is a way of enumerating physical engines present in a
2650 * way of using `DRM_IOCTL_I915_GETPARAM` and engine identifiers like
2693 * // We can now access each engine in the array
2696 * u16 class = einfo.engine.class;
2697 * u16 instance = einfo.engine.instance;
2710 * Engine discovery only fully comes to its own when combined with the new way
2712 * engine maps configured.
2718 * Describes one engine and it's capabilities as known to the driver.
2721 /** @engine: Engine class and instance. */
2722 struct i915_engine_class_instance engine;
2727 /** @flags: Engine flags. */
2730 /** @capabilities: Capabilities of this engine. */
2742 * Engine info query enumerates all engines known to the driver by filling in
Indexes created Fri Jul 24 00:25:35 UTC 2026