2012-10-05 00:21:50 +07:00
|
|
|
/*
|
|
|
|
* 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_
|
|
|
|
|
2015-11-30 21:10:47 +07:00
|
|
|
#include "drm.h"
|
2012-10-05 00:21:50 +07:00
|
|
|
|
2016-04-08 01:00:35 +07:00
|
|
|
#if defined(__cplusplus)
|
|
|
|
extern "C" {
|
|
|
|
#endif
|
|
|
|
|
2012-10-05 00:21:50 +07:00
|
|
|
/* Please note that modifications to all structs defined here are
|
|
|
|
* subject to backwards-compatibility constraints.
|
|
|
|
*/
|
|
|
|
|
2013-07-19 23:16:42 +07:00
|
|
|
/**
|
|
|
|
* DOC: uevents generated by i915 on it's 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,
|
2013-09-20 01:13:41 +07:00
|
|
|
* 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.
|
2013-07-19 23:16:42 +07:00
|
|
|
*
|
|
|
|
* 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
|
|
|
|
* 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"
|
2012-10-05 00:21:50 +07:00
|
|
|
|
2019-03-22 16:23:22 +07:00
|
|
|
/*
|
|
|
|
* 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.
|
|
|
|
*/
|
|
|
|
struct i915_user_extension {
|
|
|
|
__u64 next_extension;
|
|
|
|
__u32 name;
|
|
|
|
__u32 flags; /* All undefined bits must be zero. */
|
|
|
|
__u32 rsvd[4]; /* Reserved for future use; must be zero. */
|
|
|
|
};
|
|
|
|
|
2016-07-01 21:32:08 +07:00
|
|
|
/*
|
|
|
|
* 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,
|
|
|
|
};
|
|
|
|
|
2017-11-10 21:26:27 +07:00
|
|
|
/*
|
|
|
|
* Different engines serve different roles, and there may be more than one
|
|
|
|
* engine serving each role. enum drm_i915_gem_engine_class 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 = 0,
|
|
|
|
I915_ENGINE_CLASS_COPY = 1,
|
|
|
|
I915_ENGINE_CLASS_VIDEO = 2,
|
|
|
|
I915_ENGINE_CLASS_VIDEO_ENHANCE = 3,
|
|
|
|
|
2019-02-18 16:46:28 +07:00
|
|
|
/* should be kept compact */
|
|
|
|
|
2017-11-10 21:26:27 +07:00
|
|
|
I915_ENGINE_CLASS_INVALID = -1
|
|
|
|
};
|
|
|
|
|
2019-04-12 14:14:16 +07:00
|
|
|
/*
|
|
|
|
* 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 {
|
|
|
|
__u16 engine_class; /* see enum drm_i915_gem_engine_class */
|
|
|
|
__u16 engine_instance;
|
drm/i915: Allow a context to define its set of engines
Over the last few years, we have debated how to extend the user API to
support an increase in the number of engines, that may be sparse and
even be heterogeneous within a class (not all video decoders created
equal). We settled on using (class, instance) tuples to identify a
specific engine, with an API for the user to construct a map of engines
to capabilities. Into this picture, we then add a challenge of virtual
engines; one user engine that maps behind the scenes to any number of
physical engines. To keep it general, we want the user to have full
control over that mapping. To that end, we allow the user to constrain a
context to define the set of engines that it can access, order fully
controlled by the user via (class, instance). With such precise control
in context setup, we can continue to use the existing execbuf uABI of
specifying a single index; only now it doesn't automagically map onto
the engines, it uses the user defined engine map from the context.
v2: Fixup freeing of local on success of get_engines()
v3: Allow empty engines[]
v4: s/nengine/num_engines/
v5: Replace 64 limit on num_engines with a note that execbuf is
currently limited to only using the first 64 engines.
v6: Actually use the engines_mutex to guard the ctx->engines.
Testcase: igt/gem_ctx_engines
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190521211134.16117-2-chris@chris-wilson.co.uk
2019-05-22 04:11:26 +07:00
|
|
|
#define I915_ENGINE_CLASS_INVALID_NONE -1
|
drm/i915: Load balancing across a virtual engine
Having allowed the user to define a set of engines that they will want
to only use, we go one step further and allow them to bind those engines
into a single virtual instance. Submitting a batch to the virtual engine
will then forward it to any one of the set in a manner as best to
distribute load. The virtual engine has a single timeline across all
engines (it operates as a single queue), so it is not able to concurrently
run batches across multiple engines by itself; that is left up to the user
to submit multiple concurrent batches to multiple queues. Multiple users
will be load balanced across the system.
The mechanism used for load balancing in this patch is a late greedy
balancer. When a request is ready for execution, it is added to each
engine's queue, and when an engine is ready for its next request it
claims it from the virtual engine. The first engine to do so, wins, i.e.
the request is executed at the earliest opportunity (idle moment) in the
system.
As not all HW is created equal, the user is still able to skip the
virtual engine and execute the batch on a specific engine, all within the
same queue. It will then be executed in order on the correct engine,
with execution on other virtual engines being moved away due to the load
detection.
A couple of areas for potential improvement left!
- The virtual engine always take priority over equal-priority tasks.
Mostly broken up by applying FQ_CODEL rules for prioritising new clients,
and hopefully the virtual and real engines are not then congested (i.e.
all work is via virtual engines, or all work is to the real engine).
- We require the breadcrumb irq around every virtual engine request. For
normal engines, we eliminate the need for the slow round trip via
interrupt by using the submit fence and queueing in order. For virtual
engines, we have to allow any job to transfer to a new ring, and cannot
coalesce the submissions, so require the completion fence instead,
forcing the persistent use of interrupts.
- We only drip feed single requests through each virtual engine and onto
the physical engines, even if there was enough work to fill all ELSP,
leaving small stalls with an idle CS event at the end of every request.
Could we be greedy and fill both slots? Being lazy is virtuous for load
distribution on less-than-full workloads though.
Other areas of improvement are more general, such as reducing lock
contention, reducing dispatch overhead, looking at direct submission
rather than bouncing around tasklets etc.
sseu: Lift the restriction to allow sseu to be reconfigured on virtual
engines composed of RENDER_CLASS (rcs).
v2: macroize check_user_mbz()
v3: Cancel virtual engines on wedging
v4: Commence commenting
v5: Replace 64b sibling_mask with a list of class:instance
v6: Drop the one-element array in the uabi
v7: Assert it is an virtual engine in to_virtual_engine()
v8: Skip over holes in [class][inst] so we can selftest with (vcs0, vcs2)
Link: https://github.com/intel/media-driver/pull/283
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190521211134.16117-6-chris@chris-wilson.co.uk
2019-05-22 04:11:30 +07:00
|
|
|
#define I915_ENGINE_CLASS_INVALID_VIRTUAL -2
|
2019-04-12 14:14:16 +07:00
|
|
|
};
|
|
|
|
|
drm/i915/pmu: Expose a PMU interface for perf queries
From: Chris Wilson <chris@chris-wilson.co.uk>
From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
From: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
The first goal is to be able to measure GPU (and invidual ring) busyness
without having to poll registers from userspace. (Which not only incurs
holding the forcewake lock indefinitely, perturbing the system, but also
runs the risk of hanging the machine.) As an alternative we can use the
perf event counter interface to sample the ring registers periodically
and send those results to userspace.
Functionality we are exporting to userspace is via the existing perf PMU
API and can be exercised via the existing tools. For example:
perf stat -a -e i915/rcs0-busy/ -I 1000
Will print the render engine busynnes once per second. All the performance
counters can be enumerated (perf list) and have their unit of measure
correctly reported in sysfs.
v1-v2 (Chris Wilson):
v2: Use a common timer for the ring sampling.
v3: (Tvrtko Ursulin)
* Decouple uAPI from i915 engine ids.
* Complete uAPI defines.
* Refactor some code to helpers for clarity.
* Skip sampling disabled engines.
* Expose counters in sysfs.
* Pass in fake regs to avoid null ptr deref in perf core.
* Convert to class/instance uAPI.
* Use shared driver code for rc6 residency, power and frequency.
v4: (Dmitry Rogozhkin)
* Register PMU with .task_ctx_nr=perf_invalid_context
* Expose cpumask for the PMU with the single CPU in the mask
* Properly support pmu->stop(): it should call pmu->read()
* Properly support pmu->del(): it should call stop(event, PERF_EF_UPDATE)
* Introduce refcounting of event subscriptions.
* Make pmu.busy_stats a refcounter to avoid busy stats going away
with some deleted event.
* Expose cpumask for i915 PMU to avoid multiple events creation of
the same type followed by counter aggregation by perf-stat.
* Track CPUs getting online/offline to migrate perf context. If (likely)
cpumask will initially set CPU0, CONFIG_BOOTPARAM_HOTPLUG_CPU0 will be
needed to see effect of CPU status tracking.
* End result is that only global events are supported and perf stat
works correctly.
* Deny perf driver level sampling - it is prohibited for uncore PMU.
v5: (Tvrtko Ursulin)
* Don't hardcode number of engine samplers.
* Rewrite event ref-counting for correctness and simplicity.
* Store initial counter value when starting already enabled events
to correctly report values to all listeners.
* Fix RC6 residency readout.
* Comments, GPL header.
v6:
* Add missing entry to v4 changelog.
* Fix accounting in CPU hotplug case by copying the approach from
arch/x86/events/intel/cstate.c. (Dmitry Rogozhkin)
v7:
* Log failure message only on failure.
* Remove CPU hotplug notification state on unregister.
v8:
* Fix error unwind on failed registration.
* Checkpatch cleanup.
v9:
* Drop the energy metric, it is available via intel_rapl_perf.
(Ville Syrjälä)
* Use HAS_RC6(p). (Chris Wilson)
* Handle unsupported non-engine events. (Dmitry Rogozhkin)
* Rebase for intel_rc6_residency_ns needing caller managed
runtime pm.
* Drop HAS_RC6 checks from the read callback since creating those
events will be rejected at init time already.
* Add counter units to sysfs so perf stat output is nicer.
* Cleanup the attribute tables for brevity and readability.
v10:
* Fixed queued accounting.
v11:
* Move intel_engine_lookup_user to intel_engine_cs.c
* Commit update. (Joonas Lahtinen)
v12:
* More accurate sampling. (Chris Wilson)
* Store and report frequency in MHz for better usability from
perf stat.
* Removed metrics: queued, interrupts, rc6 counters.
* Sample engine busyness based on seqno difference only
for less MMIO (and forcewake) on all platforms. (Chris Wilson)
v13:
* Comment spelling, use mul_u32_u32 to work around potential GCC
issue and somne code alignment changes. (Chris Wilson)
v14:
* Rebase.
v15:
* Rebase for RPS refactoring.
v16:
* Use the dynamic slot in the CPU hotplug state machine so that we are
free to setup our state as multi-instance. Previously we were re-using
the CPUHP_AP_PERF_X86_UNCORE_ONLINE slot which is neither used as
multi-instance, nor owned by our driver to start with.
* Register the CPU hotplug handlers after the PMU, otherwise the callback
will get called before the PMU is initialized which can end up in
perf_pmu_migrate_context with an un-initialized base.
* Added workaround for a probable bug in cpuhp core.
v17:
* Remove workaround for the cpuhp bug.
v18:
* Rebase for drm_i915_gem_engine_class getting upstream before us.
v19:
* Rebase. (trivial)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171121181852.16128-2-tvrtko.ursulin@linux.intel.com
2017-11-22 01:18:45 +07:00
|
|
|
/**
|
|
|
|
* DOC: perf_events exposed by i915 through /sys/bus/event_sources/drivers/i915
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
|
|
|
enum drm_i915_pmu_engine_sample {
|
|
|
|
I915_SAMPLE_BUSY = 0,
|
|
|
|
I915_SAMPLE_WAIT = 1,
|
2017-11-23 17:07:01 +07:00
|
|
|
I915_SAMPLE_SEMA = 2
|
drm/i915/pmu: Expose a PMU interface for perf queries
From: Chris Wilson <chris@chris-wilson.co.uk>
From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
From: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
The first goal is to be able to measure GPU (and invidual ring) busyness
without having to poll registers from userspace. (Which not only incurs
holding the forcewake lock indefinitely, perturbing the system, but also
runs the risk of hanging the machine.) As an alternative we can use the
perf event counter interface to sample the ring registers periodically
and send those results to userspace.
Functionality we are exporting to userspace is via the existing perf PMU
API and can be exercised via the existing tools. For example:
perf stat -a -e i915/rcs0-busy/ -I 1000
Will print the render engine busynnes once per second. All the performance
counters can be enumerated (perf list) and have their unit of measure
correctly reported in sysfs.
v1-v2 (Chris Wilson):
v2: Use a common timer for the ring sampling.
v3: (Tvrtko Ursulin)
* Decouple uAPI from i915 engine ids.
* Complete uAPI defines.
* Refactor some code to helpers for clarity.
* Skip sampling disabled engines.
* Expose counters in sysfs.
* Pass in fake regs to avoid null ptr deref in perf core.
* Convert to class/instance uAPI.
* Use shared driver code for rc6 residency, power and frequency.
v4: (Dmitry Rogozhkin)
* Register PMU with .task_ctx_nr=perf_invalid_context
* Expose cpumask for the PMU with the single CPU in the mask
* Properly support pmu->stop(): it should call pmu->read()
* Properly support pmu->del(): it should call stop(event, PERF_EF_UPDATE)
* Introduce refcounting of event subscriptions.
* Make pmu.busy_stats a refcounter to avoid busy stats going away
with some deleted event.
* Expose cpumask for i915 PMU to avoid multiple events creation of
the same type followed by counter aggregation by perf-stat.
* Track CPUs getting online/offline to migrate perf context. If (likely)
cpumask will initially set CPU0, CONFIG_BOOTPARAM_HOTPLUG_CPU0 will be
needed to see effect of CPU status tracking.
* End result is that only global events are supported and perf stat
works correctly.
* Deny perf driver level sampling - it is prohibited for uncore PMU.
v5: (Tvrtko Ursulin)
* Don't hardcode number of engine samplers.
* Rewrite event ref-counting for correctness and simplicity.
* Store initial counter value when starting already enabled events
to correctly report values to all listeners.
* Fix RC6 residency readout.
* Comments, GPL header.
v6:
* Add missing entry to v4 changelog.
* Fix accounting in CPU hotplug case by copying the approach from
arch/x86/events/intel/cstate.c. (Dmitry Rogozhkin)
v7:
* Log failure message only on failure.
* Remove CPU hotplug notification state on unregister.
v8:
* Fix error unwind on failed registration.
* Checkpatch cleanup.
v9:
* Drop the energy metric, it is available via intel_rapl_perf.
(Ville Syrjälä)
* Use HAS_RC6(p). (Chris Wilson)
* Handle unsupported non-engine events. (Dmitry Rogozhkin)
* Rebase for intel_rc6_residency_ns needing caller managed
runtime pm.
* Drop HAS_RC6 checks from the read callback since creating those
events will be rejected at init time already.
* Add counter units to sysfs so perf stat output is nicer.
* Cleanup the attribute tables for brevity and readability.
v10:
* Fixed queued accounting.
v11:
* Move intel_engine_lookup_user to intel_engine_cs.c
* Commit update. (Joonas Lahtinen)
v12:
* More accurate sampling. (Chris Wilson)
* Store and report frequency in MHz for better usability from
perf stat.
* Removed metrics: queued, interrupts, rc6 counters.
* Sample engine busyness based on seqno difference only
for less MMIO (and forcewake) on all platforms. (Chris Wilson)
v13:
* Comment spelling, use mul_u32_u32 to work around potential GCC
issue and somne code alignment changes. (Chris Wilson)
v14:
* Rebase.
v15:
* Rebase for RPS refactoring.
v16:
* Use the dynamic slot in the CPU hotplug state machine so that we are
free to setup our state as multi-instance. Previously we were re-using
the CPUHP_AP_PERF_X86_UNCORE_ONLINE slot which is neither used as
multi-instance, nor owned by our driver to start with.
* Register the CPU hotplug handlers after the PMU, otherwise the callback
will get called before the PMU is initialized which can end up in
perf_pmu_migrate_context with an un-initialized base.
* Added workaround for a probable bug in cpuhp core.
v17:
* Remove workaround for the cpuhp bug.
v18:
* Rebase for drm_i915_gem_engine_class getting upstream before us.
v19:
* Rebase. (trivial)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171121181852.16128-2-tvrtko.ursulin@linux.intel.com
2017-11-22 01:18:45 +07:00
|
|
|
};
|
|
|
|
|
|
|
|
#define I915_PMU_SAMPLE_BITS (4)
|
|
|
|
#define I915_PMU_SAMPLE_MASK (0xf)
|
|
|
|
#define I915_PMU_SAMPLE_INSTANCE_BITS (8)
|
|
|
|
#define I915_PMU_CLASS_SHIFT \
|
|
|
|
(I915_PMU_SAMPLE_BITS + I915_PMU_SAMPLE_INSTANCE_BITS)
|
|
|
|
|
|
|
|
#define __I915_PMU_ENGINE(class, instance, sample) \
|
|
|
|
((class) << I915_PMU_CLASS_SHIFT | \
|
|
|
|
(instance) << I915_PMU_SAMPLE_BITS | \
|
|
|
|
(sample))
|
|
|
|
|
|
|
|
#define I915_PMU_ENGINE_BUSY(class, instance) \
|
|
|
|
__I915_PMU_ENGINE(class, instance, I915_SAMPLE_BUSY)
|
|
|
|
|
|
|
|
#define I915_PMU_ENGINE_WAIT(class, instance) \
|
|
|
|
__I915_PMU_ENGINE(class, instance, I915_SAMPLE_WAIT)
|
|
|
|
|
|
|
|
#define I915_PMU_ENGINE_SEMA(class, instance) \
|
|
|
|
__I915_PMU_ENGINE(class, instance, I915_SAMPLE_SEMA)
|
|
|
|
|
|
|
|
#define __I915_PMU_OTHER(x) (__I915_PMU_ENGINE(0xff, 0xff, 0xf) + 1 + (x))
|
|
|
|
|
|
|
|
#define I915_PMU_ACTUAL_FREQUENCY __I915_PMU_OTHER(0)
|
|
|
|
#define I915_PMU_REQUESTED_FREQUENCY __I915_PMU_OTHER(1)
|
2017-11-22 01:18:50 +07:00
|
|
|
#define I915_PMU_INTERRUPTS __I915_PMU_OTHER(2)
|
2017-11-22 01:18:52 +07:00
|
|
|
#define I915_PMU_RC6_RESIDENCY __I915_PMU_OTHER(3)
|
|
|
|
|
2017-11-25 00:13:31 +07:00
|
|
|
#define I915_PMU_LAST I915_PMU_RC6_RESIDENCY
|
drm/i915/pmu: Expose a PMU interface for perf queries
From: Chris Wilson <chris@chris-wilson.co.uk>
From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
From: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
The first goal is to be able to measure GPU (and invidual ring) busyness
without having to poll registers from userspace. (Which not only incurs
holding the forcewake lock indefinitely, perturbing the system, but also
runs the risk of hanging the machine.) As an alternative we can use the
perf event counter interface to sample the ring registers periodically
and send those results to userspace.
Functionality we are exporting to userspace is via the existing perf PMU
API and can be exercised via the existing tools. For example:
perf stat -a -e i915/rcs0-busy/ -I 1000
Will print the render engine busynnes once per second. All the performance
counters can be enumerated (perf list) and have their unit of measure
correctly reported in sysfs.
v1-v2 (Chris Wilson):
v2: Use a common timer for the ring sampling.
v3: (Tvrtko Ursulin)
* Decouple uAPI from i915 engine ids.
* Complete uAPI defines.
* Refactor some code to helpers for clarity.
* Skip sampling disabled engines.
* Expose counters in sysfs.
* Pass in fake regs to avoid null ptr deref in perf core.
* Convert to class/instance uAPI.
* Use shared driver code for rc6 residency, power and frequency.
v4: (Dmitry Rogozhkin)
* Register PMU with .task_ctx_nr=perf_invalid_context
* Expose cpumask for the PMU with the single CPU in the mask
* Properly support pmu->stop(): it should call pmu->read()
* Properly support pmu->del(): it should call stop(event, PERF_EF_UPDATE)
* Introduce refcounting of event subscriptions.
* Make pmu.busy_stats a refcounter to avoid busy stats going away
with some deleted event.
* Expose cpumask for i915 PMU to avoid multiple events creation of
the same type followed by counter aggregation by perf-stat.
* Track CPUs getting online/offline to migrate perf context. If (likely)
cpumask will initially set CPU0, CONFIG_BOOTPARAM_HOTPLUG_CPU0 will be
needed to see effect of CPU status tracking.
* End result is that only global events are supported and perf stat
works correctly.
* Deny perf driver level sampling - it is prohibited for uncore PMU.
v5: (Tvrtko Ursulin)
* Don't hardcode number of engine samplers.
* Rewrite event ref-counting for correctness and simplicity.
* Store initial counter value when starting already enabled events
to correctly report values to all listeners.
* Fix RC6 residency readout.
* Comments, GPL header.
v6:
* Add missing entry to v4 changelog.
* Fix accounting in CPU hotplug case by copying the approach from
arch/x86/events/intel/cstate.c. (Dmitry Rogozhkin)
v7:
* Log failure message only on failure.
* Remove CPU hotplug notification state on unregister.
v8:
* Fix error unwind on failed registration.
* Checkpatch cleanup.
v9:
* Drop the energy metric, it is available via intel_rapl_perf.
(Ville Syrjälä)
* Use HAS_RC6(p). (Chris Wilson)
* Handle unsupported non-engine events. (Dmitry Rogozhkin)
* Rebase for intel_rc6_residency_ns needing caller managed
runtime pm.
* Drop HAS_RC6 checks from the read callback since creating those
events will be rejected at init time already.
* Add counter units to sysfs so perf stat output is nicer.
* Cleanup the attribute tables for brevity and readability.
v10:
* Fixed queued accounting.
v11:
* Move intel_engine_lookup_user to intel_engine_cs.c
* Commit update. (Joonas Lahtinen)
v12:
* More accurate sampling. (Chris Wilson)
* Store and report frequency in MHz for better usability from
perf stat.
* Removed metrics: queued, interrupts, rc6 counters.
* Sample engine busyness based on seqno difference only
for less MMIO (and forcewake) on all platforms. (Chris Wilson)
v13:
* Comment spelling, use mul_u32_u32 to work around potential GCC
issue and somne code alignment changes. (Chris Wilson)
v14:
* Rebase.
v15:
* Rebase for RPS refactoring.
v16:
* Use the dynamic slot in the CPU hotplug state machine so that we are
free to setup our state as multi-instance. Previously we were re-using
the CPUHP_AP_PERF_X86_UNCORE_ONLINE slot which is neither used as
multi-instance, nor owned by our driver to start with.
* Register the CPU hotplug handlers after the PMU, otherwise the callback
will get called before the PMU is initialized which can end up in
perf_pmu_migrate_context with an un-initialized base.
* Added workaround for a probable bug in cpuhp core.
v17:
* Remove workaround for the cpuhp bug.
v18:
* Rebase for drm_i915_gem_engine_class getting upstream before us.
v19:
* Rebase. (trivial)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171121181852.16128-2-tvrtko.ursulin@linux.intel.com
2017-11-22 01:18:45 +07:00
|
|
|
|
2012-10-05 00:21:50 +07:00
|
|
|
/* 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
|
|
|
|
|
|
|
|
typedef struct _drm_i915_init {
|
|
|
|
enum {
|
|
|
|
I915_INIT_DMA = 0x01,
|
|
|
|
I915_CLEANUP_DMA = 0x02,
|
|
|
|
I915_RESUME_DMA = 0x03
|
|
|
|
} func;
|
|
|
|
unsigned int mmio_offset;
|
|
|
|
int sarea_priv_offset;
|
|
|
|
unsigned int ring_start;
|
|
|
|
unsigned int ring_end;
|
|
|
|
unsigned int ring_size;
|
|
|
|
unsigned int front_offset;
|
|
|
|
unsigned int back_offset;
|
|
|
|
unsigned int depth_offset;
|
|
|
|
unsigned int w;
|
|
|
|
unsigned int h;
|
|
|
|
unsigned int pitch;
|
|
|
|
unsigned int pitch_bits;
|
|
|
|
unsigned int back_pitch;
|
|
|
|
unsigned int depth_pitch;
|
|
|
|
unsigned int cpp;
|
|
|
|
unsigned int chipset;
|
|
|
|
} drm_i915_init_t;
|
|
|
|
|
|
|
|
typedef struct _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;
|
|
|
|
|
|
|
|
unsigned int front_tiled;
|
|
|
|
unsigned int back_tiled;
|
|
|
|
unsigned int depth_tiled;
|
|
|
|
unsigned int rotated_tiled;
|
|
|
|
unsigned int rotated2_tiled;
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
/* Flags for perf_boxes
|
|
|
|
*/
|
|
|
|
#define I915_BOX_RING_EMPTY 0x1
|
|
|
|
#define I915_BOX_FLIP 0x2
|
|
|
|
#define I915_BOX_WAIT 0x4
|
|
|
|
#define I915_BOX_TEXTURE_LOAD 0x8
|
|
|
|
#define I915_BOX_LOST_CONTEXT 0x10
|
|
|
|
|
2015-05-26 20:57:19 +07:00
|
|
|
/*
|
|
|
|
* 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).
|
2012-10-05 00:21:50 +07:00
|
|
|
*/
|
|
|
|
#define DRM_I915_INIT 0x00
|
|
|
|
#define DRM_I915_FLUSH 0x01
|
|
|
|
#define DRM_I915_FLIP 0x02
|
|
|
|
#define DRM_I915_BATCHBUFFER 0x03
|
|
|
|
#define DRM_I915_IRQ_EMIT 0x04
|
|
|
|
#define DRM_I915_IRQ_WAIT 0x05
|
|
|
|
#define DRM_I915_GETPARAM 0x06
|
|
|
|
#define DRM_I915_SETPARAM 0x07
|
|
|
|
#define DRM_I915_ALLOC 0x08
|
|
|
|
#define DRM_I915_FREE 0x09
|
|
|
|
#define DRM_I915_INIT_HEAP 0x0a
|
|
|
|
#define DRM_I915_CMDBUFFER 0x0b
|
|
|
|
#define DRM_I915_DESTROY_HEAP 0x0c
|
|
|
|
#define DRM_I915_SET_VBLANK_PIPE 0x0d
|
|
|
|
#define DRM_I915_GET_VBLANK_PIPE 0x0e
|
|
|
|
#define DRM_I915_VBLANK_SWAP 0x0f
|
|
|
|
#define DRM_I915_HWS_ADDR 0x11
|
|
|
|
#define DRM_I915_GEM_INIT 0x13
|
|
|
|
#define DRM_I915_GEM_EXECBUFFER 0x14
|
|
|
|
#define DRM_I915_GEM_PIN 0x15
|
|
|
|
#define DRM_I915_GEM_UNPIN 0x16
|
|
|
|
#define DRM_I915_GEM_BUSY 0x17
|
|
|
|
#define DRM_I915_GEM_THROTTLE 0x18
|
|
|
|
#define DRM_I915_GEM_ENTERVT 0x19
|
|
|
|
#define DRM_I915_GEM_LEAVEVT 0x1a
|
|
|
|
#define DRM_I915_GEM_CREATE 0x1b
|
|
|
|
#define DRM_I915_GEM_PREAD 0x1c
|
|
|
|
#define DRM_I915_GEM_PWRITE 0x1d
|
|
|
|
#define DRM_I915_GEM_MMAP 0x1e
|
|
|
|
#define DRM_I915_GEM_SET_DOMAIN 0x1f
|
|
|
|
#define DRM_I915_GEM_SW_FINISH 0x20
|
|
|
|
#define DRM_I915_GEM_SET_TILING 0x21
|
|
|
|
#define DRM_I915_GEM_GET_TILING 0x22
|
|
|
|
#define DRM_I915_GEM_GET_APERTURE 0x23
|
|
|
|
#define DRM_I915_GEM_MMAP_GTT 0x24
|
|
|
|
#define DRM_I915_GET_PIPE_FROM_CRTC_ID 0x25
|
|
|
|
#define DRM_I915_GEM_MADVISE 0x26
|
|
|
|
#define DRM_I915_OVERLAY_PUT_IMAGE 0x27
|
|
|
|
#define DRM_I915_OVERLAY_ATTRS 0x28
|
|
|
|
#define DRM_I915_GEM_EXECBUFFER2 0x29
|
2017-01-27 16:40:08 +07:00
|
|
|
#define DRM_I915_GEM_EXECBUFFER2_WR DRM_I915_GEM_EXECBUFFER2
|
2012-10-05 00:21:50 +07:00
|
|
|
#define DRM_I915_GET_SPRITE_COLORKEY 0x2a
|
|
|
|
#define DRM_I915_SET_SPRITE_COLORKEY 0x2b
|
|
|
|
#define DRM_I915_GEM_WAIT 0x2c
|
|
|
|
#define DRM_I915_GEM_CONTEXT_CREATE 0x2d
|
|
|
|
#define DRM_I915_GEM_CONTEXT_DESTROY 0x2e
|
|
|
|
#define DRM_I915_GEM_SET_CACHING 0x2f
|
|
|
|
#define DRM_I915_GEM_GET_CACHING 0x30
|
|
|
|
#define DRM_I915_REG_READ 0x31
|
2013-10-30 20:44:16 +07:00
|
|
|
#define DRM_I915_GET_RESET_STATS 0x32
|
drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl
By exporting the ability to map user address and inserting PTEs
representing their backing pages into the GTT, we can exploit UMA in order
to utilize normal application data as a texture source or even as a
render target (depending upon the capabilities of the chipset). This has
a number of uses, with zero-copy downloads to the GPU and efficient
readback making the intermixed streaming of CPU and GPU operations
fairly efficient. This ability has many widespread implications from
faster rendering of client-side software rasterisers (chromium),
mitigation of stalls due to read back (firefox) and to faster pipelining
of texture data (such as pixel buffer objects in GL or data blobs in CL).
v2: Compile with CONFIG_MMU_NOTIFIER
v3: We can sleep while performing invalidate-range, which we can utilise
to drop our page references prior to the kernel manipulating the vma
(for either discard or cloning) and so protect normal users.
v4: Only run the invalidate notifier if the range intercepts the bo.
v5: Prevent userspace from attempting to GTT mmap non-page aligned buffers
v6: Recheck after reacquire mutex for lost mmu.
v7: Fix implicit padding of ioctl struct by rounding to next 64bit boundary.
v8: Fix rebasing error after forwarding porting the back port.
v9: Limit the userptr to page aligned entries. We now expect userspace
to handle all the offset-in-page adjustments itself.
v10: Prevent vma from being copied across fork to avoid issues with cow.
v11: Drop vma behaviour changes -- locking is nigh on impossible.
Use a worker to load user pages to avoid lock inversions.
v12: Use get_task_mm()/mmput() for correct refcounting of mm.
v13: Use a worker to release the mmu_notifier to avoid lock inversion
v14: Decouple mmu_notifier from struct_mutex using a custom mmu_notifer
with its own locking and tree of objects for each mm/mmu_notifier.
v15: Prevent overlapping userptr objects, and invalidate all objects
within the mmu_notifier range
v16: Fix a typo for iterating over multiple objects in the range and
rearrange error path to destroy the mmu_notifier locklessly.
Also close a race between invalidate_range and the get_pages_worker.
v17: Close a race between get_pages_worker/invalidate_range and fresh
allocations of the same userptr range - and notice that
struct_mutex was presumed to be held when during creation it wasn't.
v18: Sigh. Fix the refactor of st_set_pages() to allocate enough memory
for the struct sg_table and to clear it before reporting an error.
v19: Always error out on read-only userptr requests as we don't have the
hardware infrastructure to support them at the moment.
v20: Refuse to implement read-only support until we have the required
infrastructure - but reserve the bit in flags for future use.
v21: use_mm() is not required for get_user_pages(). It is only meant to
be used to fix up the kernel thread's current->mm for use with
copy_user().
v22: Use sg_alloc_table_from_pages for that chunky feeling
v23: Export a function for sanity checking dma-buf rather than encode
userptr details elsewhere, and clean up comments based on
suggestions by Bradley.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: "Gong, Zhipeng" <zhipeng.gong@intel.com>
Cc: Akash Goel <akash.goel@intel.com>
Cc: "Volkin, Bradley D" <bradley.d.volkin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: Brad Volkin <bradley.d.volkin@intel.com>
[danvet: Frob ioctl allocation to pick the next one - will cause a bit
of fuss with create2 apparently, but such are the rules.]
[danvet2: oops, forgot to git add after manual patch application]
[danvet3: Appease sparse.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-16 20:22:37 +07:00
|
|
|
#define DRM_I915_GEM_USERPTR 0x33
|
2014-12-24 23:13:40 +07:00
|
|
|
#define DRM_I915_GEM_CONTEXT_GETPARAM 0x34
|
|
|
|
#define DRM_I915_GEM_CONTEXT_SETPARAM 0x35
|
drm/i915: Add i915 perf infrastructure
Adds base i915 perf infrastructure for Gen performance metrics.
This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
properties to configure a stream of metrics and returns a new fd usable
with standard VFS system calls including read() to read typed and sized
records; ioctl() to enable or disable capture and poll() to wait for
data.
A stream is opened something like:
uint64_t properties[] = {
/* Single context sampling */
DRM_I915_PERF_PROP_CTX_HANDLE, ctx_handle,
/* Include OA reports in samples */
DRM_I915_PERF_PROP_SAMPLE_OA, true,
/* OA unit configuration */
DRM_I915_PERF_PROP_OA_METRICS_SET, metrics_set_id,
DRM_I915_PERF_PROP_OA_FORMAT, report_format,
DRM_I915_PERF_PROP_OA_EXPONENT, period_exponent,
};
struct drm_i915_perf_open_param parm = {
.flags = I915_PERF_FLAG_FD_CLOEXEC |
I915_PERF_FLAG_FD_NONBLOCK |
I915_PERF_FLAG_DISABLED,
.properties_ptr = (uint64_t)properties,
.num_properties = sizeof(properties) / 16,
};
int fd = drmIoctl(drm_fd, DRM_IOCTL_I915_PERF_OPEN, ¶m);
Records read all start with a common { type, size } header with
DRM_I915_PERF_RECORD_SAMPLE being of most interest. Sample records
contain an extensible number of fields and it's the
DRM_I915_PERF_PROP_SAMPLE_xyz properties given when opening that
determine what's included in every sample.
No specific streams are supported yet so any attempt to open a stream
will return an error.
v2:
use i915_gem_context_get() - Chris Wilson
v3:
update read() interface to avoid passing state struct - Chris Wilson
fix some rebase fallout, with i915-perf init/deinit
v4:
s/DRM_IORW/DRM_IOW/ - Emil Velikov
Signed-off-by: Robert Bragg <robert@sixbynine.org>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Sourab Gupta <sourab.gupta@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161107194957.3385-2-robert@sixbynine.org
2016-11-08 02:49:47 +07:00
|
|
|
#define DRM_I915_PERF_OPEN 0x36
|
2017-08-04 00:05:50 +07:00
|
|
|
#define DRM_I915_PERF_ADD_CONFIG 0x37
|
|
|
|
#define DRM_I915_PERF_REMOVE_CONFIG 0x38
|
2018-03-06 19:28:56 +07:00
|
|
|
#define DRM_I915_QUERY 0x39
|
2019-05-22 04:11:25 +07:00
|
|
|
#define DRM_I915_GEM_VM_CREATE 0x3a
|
|
|
|
#define DRM_I915_GEM_VM_DESTROY 0x3b
|
2019-02-18 16:46:28 +07:00
|
|
|
/* Must be kept compact -- no holes */
|
2012-10-05 00:21:50 +07:00
|
|
|
|
|
|
|
#define DRM_IOCTL_I915_INIT DRM_IOW( DRM_COMMAND_BASE + DRM_I915_INIT, drm_i915_init_t)
|
|
|
|
#define DRM_IOCTL_I915_FLUSH DRM_IO ( DRM_COMMAND_BASE + DRM_I915_FLUSH)
|
|
|
|
#define DRM_IOCTL_I915_FLIP DRM_IO ( DRM_COMMAND_BASE + DRM_I915_FLIP)
|
|
|
|
#define DRM_IOCTL_I915_BATCHBUFFER DRM_IOW( DRM_COMMAND_BASE + DRM_I915_BATCHBUFFER, drm_i915_batchbuffer_t)
|
|
|
|
#define DRM_IOCTL_I915_IRQ_EMIT DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_IRQ_EMIT, drm_i915_irq_emit_t)
|
|
|
|
#define DRM_IOCTL_I915_IRQ_WAIT DRM_IOW( DRM_COMMAND_BASE + DRM_I915_IRQ_WAIT, drm_i915_irq_wait_t)
|
|
|
|
#define DRM_IOCTL_I915_GETPARAM DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GETPARAM, drm_i915_getparam_t)
|
|
|
|
#define DRM_IOCTL_I915_SETPARAM DRM_IOW( DRM_COMMAND_BASE + DRM_I915_SETPARAM, drm_i915_setparam_t)
|
|
|
|
#define DRM_IOCTL_I915_ALLOC DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_ALLOC, drm_i915_mem_alloc_t)
|
|
|
|
#define DRM_IOCTL_I915_FREE DRM_IOW( DRM_COMMAND_BASE + DRM_I915_FREE, drm_i915_mem_free_t)
|
|
|
|
#define DRM_IOCTL_I915_INIT_HEAP DRM_IOW( DRM_COMMAND_BASE + DRM_I915_INIT_HEAP, drm_i915_mem_init_heap_t)
|
|
|
|
#define DRM_IOCTL_I915_CMDBUFFER DRM_IOW( DRM_COMMAND_BASE + DRM_I915_CMDBUFFER, drm_i915_cmdbuffer_t)
|
|
|
|
#define DRM_IOCTL_I915_DESTROY_HEAP DRM_IOW( DRM_COMMAND_BASE + DRM_I915_DESTROY_HEAP, drm_i915_mem_destroy_heap_t)
|
|
|
|
#define DRM_IOCTL_I915_SET_VBLANK_PIPE DRM_IOW( DRM_COMMAND_BASE + DRM_I915_SET_VBLANK_PIPE, drm_i915_vblank_pipe_t)
|
|
|
|
#define DRM_IOCTL_I915_GET_VBLANK_PIPE DRM_IOR( DRM_COMMAND_BASE + DRM_I915_GET_VBLANK_PIPE, drm_i915_vblank_pipe_t)
|
|
|
|
#define DRM_IOCTL_I915_VBLANK_SWAP DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_VBLANK_SWAP, drm_i915_vblank_swap_t)
|
|
|
|
#define DRM_IOCTL_I915_HWS_ADDR DRM_IOW(DRM_COMMAND_BASE + DRM_I915_HWS_ADDR, struct drm_i915_gem_init)
|
|
|
|
#define DRM_IOCTL_I915_GEM_INIT DRM_IOW(DRM_COMMAND_BASE + DRM_I915_GEM_INIT, struct drm_i915_gem_init)
|
|
|
|
#define DRM_IOCTL_I915_GEM_EXECBUFFER DRM_IOW(DRM_COMMAND_BASE + DRM_I915_GEM_EXECBUFFER, struct drm_i915_gem_execbuffer)
|
|
|
|
#define DRM_IOCTL_I915_GEM_EXECBUFFER2 DRM_IOW(DRM_COMMAND_BASE + DRM_I915_GEM_EXECBUFFER2, struct drm_i915_gem_execbuffer2)
|
2017-01-27 16:40:08 +07:00
|
|
|
#define DRM_IOCTL_I915_GEM_EXECBUFFER2_WR DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_EXECBUFFER2_WR, struct drm_i915_gem_execbuffer2)
|
2012-10-05 00:21:50 +07:00
|
|
|
#define DRM_IOCTL_I915_GEM_PIN DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_PIN, struct drm_i915_gem_pin)
|
|
|
|
#define DRM_IOCTL_I915_GEM_UNPIN DRM_IOW(DRM_COMMAND_BASE + DRM_I915_GEM_UNPIN, struct drm_i915_gem_unpin)
|
|
|
|
#define DRM_IOCTL_I915_GEM_BUSY DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_BUSY, struct drm_i915_gem_busy)
|
|
|
|
#define DRM_IOCTL_I915_GEM_SET_CACHING DRM_IOW(DRM_COMMAND_BASE + DRM_I915_GEM_SET_CACHING, struct drm_i915_gem_caching)
|
|
|
|
#define DRM_IOCTL_I915_GEM_GET_CACHING DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_GET_CACHING, struct drm_i915_gem_caching)
|
|
|
|
#define DRM_IOCTL_I915_GEM_THROTTLE DRM_IO ( DRM_COMMAND_BASE + DRM_I915_GEM_THROTTLE)
|
|
|
|
#define DRM_IOCTL_I915_GEM_ENTERVT DRM_IO(DRM_COMMAND_BASE + DRM_I915_GEM_ENTERVT)
|
|
|
|
#define DRM_IOCTL_I915_GEM_LEAVEVT DRM_IO(DRM_COMMAND_BASE + DRM_I915_GEM_LEAVEVT)
|
|
|
|
#define DRM_IOCTL_I915_GEM_CREATE DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_CREATE, struct drm_i915_gem_create)
|
|
|
|
#define DRM_IOCTL_I915_GEM_PREAD DRM_IOW (DRM_COMMAND_BASE + DRM_I915_GEM_PREAD, struct drm_i915_gem_pread)
|
|
|
|
#define DRM_IOCTL_I915_GEM_PWRITE DRM_IOW (DRM_COMMAND_BASE + DRM_I915_GEM_PWRITE, struct drm_i915_gem_pwrite)
|
|
|
|
#define DRM_IOCTL_I915_GEM_MMAP DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_MMAP, struct drm_i915_gem_mmap)
|
|
|
|
#define DRM_IOCTL_I915_GEM_MMAP_GTT DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_MMAP_GTT, struct drm_i915_gem_mmap_gtt)
|
|
|
|
#define DRM_IOCTL_I915_GEM_SET_DOMAIN DRM_IOW (DRM_COMMAND_BASE + DRM_I915_GEM_SET_DOMAIN, struct drm_i915_gem_set_domain)
|
|
|
|
#define DRM_IOCTL_I915_GEM_SW_FINISH DRM_IOW (DRM_COMMAND_BASE + DRM_I915_GEM_SW_FINISH, struct drm_i915_gem_sw_finish)
|
|
|
|
#define DRM_IOCTL_I915_GEM_SET_TILING DRM_IOWR (DRM_COMMAND_BASE + DRM_I915_GEM_SET_TILING, struct drm_i915_gem_set_tiling)
|
|
|
|
#define DRM_IOCTL_I915_GEM_GET_TILING DRM_IOWR (DRM_COMMAND_BASE + DRM_I915_GEM_GET_TILING, struct drm_i915_gem_get_tiling)
|
|
|
|
#define DRM_IOCTL_I915_GEM_GET_APERTURE DRM_IOR (DRM_COMMAND_BASE + DRM_I915_GEM_GET_APERTURE, struct drm_i915_gem_get_aperture)
|
|
|
|
#define DRM_IOCTL_I915_GET_PIPE_FROM_CRTC_ID DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GET_PIPE_FROM_CRTC_ID, struct drm_i915_get_pipe_from_crtc_id)
|
|
|
|
#define DRM_IOCTL_I915_GEM_MADVISE DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_MADVISE, struct drm_i915_gem_madvise)
|
|
|
|
#define DRM_IOCTL_I915_OVERLAY_PUT_IMAGE DRM_IOW(DRM_COMMAND_BASE + DRM_I915_OVERLAY_PUT_IMAGE, struct drm_intel_overlay_put_image)
|
|
|
|
#define DRM_IOCTL_I915_OVERLAY_ATTRS DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_OVERLAY_ATTRS, struct drm_intel_overlay_attrs)
|
|
|
|
#define DRM_IOCTL_I915_SET_SPRITE_COLORKEY DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_SET_SPRITE_COLORKEY, struct drm_intel_sprite_colorkey)
|
2015-03-27 02:47:16 +07:00
|
|
|
#define DRM_IOCTL_I915_GET_SPRITE_COLORKEY DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GET_SPRITE_COLORKEY, struct drm_intel_sprite_colorkey)
|
2012-10-05 00:21:50 +07:00
|
|
|
#define DRM_IOCTL_I915_GEM_WAIT DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_WAIT, struct drm_i915_gem_wait)
|
|
|
|
#define DRM_IOCTL_I915_GEM_CONTEXT_CREATE DRM_IOWR (DRM_COMMAND_BASE + DRM_I915_GEM_CONTEXT_CREATE, struct drm_i915_gem_context_create)
|
2019-03-22 16:23:24 +07:00
|
|
|
#define DRM_IOCTL_I915_GEM_CONTEXT_CREATE_EXT DRM_IOWR (DRM_COMMAND_BASE + DRM_I915_GEM_CONTEXT_CREATE, struct drm_i915_gem_context_create_ext)
|
2012-10-05 00:21:50 +07:00
|
|
|
#define DRM_IOCTL_I915_GEM_CONTEXT_DESTROY DRM_IOW (DRM_COMMAND_BASE + DRM_I915_GEM_CONTEXT_DESTROY, struct drm_i915_gem_context_destroy)
|
|
|
|
#define DRM_IOCTL_I915_REG_READ DRM_IOWR (DRM_COMMAND_BASE + DRM_I915_REG_READ, struct drm_i915_reg_read)
|
2013-10-30 20:44:16 +07:00
|
|
|
#define DRM_IOCTL_I915_GET_RESET_STATS DRM_IOWR (DRM_COMMAND_BASE + DRM_I915_GET_RESET_STATS, struct drm_i915_reset_stats)
|
drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl
By exporting the ability to map user address and inserting PTEs
representing their backing pages into the GTT, we can exploit UMA in order
to utilize normal application data as a texture source or even as a
render target (depending upon the capabilities of the chipset). This has
a number of uses, with zero-copy downloads to the GPU and efficient
readback making the intermixed streaming of CPU and GPU operations
fairly efficient. This ability has many widespread implications from
faster rendering of client-side software rasterisers (chromium),
mitigation of stalls due to read back (firefox) and to faster pipelining
of texture data (such as pixel buffer objects in GL or data blobs in CL).
v2: Compile with CONFIG_MMU_NOTIFIER
v3: We can sleep while performing invalidate-range, which we can utilise
to drop our page references prior to the kernel manipulating the vma
(for either discard or cloning) and so protect normal users.
v4: Only run the invalidate notifier if the range intercepts the bo.
v5: Prevent userspace from attempting to GTT mmap non-page aligned buffers
v6: Recheck after reacquire mutex for lost mmu.
v7: Fix implicit padding of ioctl struct by rounding to next 64bit boundary.
v8: Fix rebasing error after forwarding porting the back port.
v9: Limit the userptr to page aligned entries. We now expect userspace
to handle all the offset-in-page adjustments itself.
v10: Prevent vma from being copied across fork to avoid issues with cow.
v11: Drop vma behaviour changes -- locking is nigh on impossible.
Use a worker to load user pages to avoid lock inversions.
v12: Use get_task_mm()/mmput() for correct refcounting of mm.
v13: Use a worker to release the mmu_notifier to avoid lock inversion
v14: Decouple mmu_notifier from struct_mutex using a custom mmu_notifer
with its own locking and tree of objects for each mm/mmu_notifier.
v15: Prevent overlapping userptr objects, and invalidate all objects
within the mmu_notifier range
v16: Fix a typo for iterating over multiple objects in the range and
rearrange error path to destroy the mmu_notifier locklessly.
Also close a race between invalidate_range and the get_pages_worker.
v17: Close a race between get_pages_worker/invalidate_range and fresh
allocations of the same userptr range - and notice that
struct_mutex was presumed to be held when during creation it wasn't.
v18: Sigh. Fix the refactor of st_set_pages() to allocate enough memory
for the struct sg_table and to clear it before reporting an error.
v19: Always error out on read-only userptr requests as we don't have the
hardware infrastructure to support them at the moment.
v20: Refuse to implement read-only support until we have the required
infrastructure - but reserve the bit in flags for future use.
v21: use_mm() is not required for get_user_pages(). It is only meant to
be used to fix up the kernel thread's current->mm for use with
copy_user().
v22: Use sg_alloc_table_from_pages for that chunky feeling
v23: Export a function for sanity checking dma-buf rather than encode
userptr details elsewhere, and clean up comments based on
suggestions by Bradley.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: "Gong, Zhipeng" <zhipeng.gong@intel.com>
Cc: Akash Goel <akash.goel@intel.com>
Cc: "Volkin, Bradley D" <bradley.d.volkin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: Brad Volkin <bradley.d.volkin@intel.com>
[danvet: Frob ioctl allocation to pick the next one - will cause a bit
of fuss with create2 apparently, but such are the rules.]
[danvet2: oops, forgot to git add after manual patch application]
[danvet3: Appease sparse.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-16 20:22:37 +07:00
|
|
|
#define DRM_IOCTL_I915_GEM_USERPTR DRM_IOWR (DRM_COMMAND_BASE + DRM_I915_GEM_USERPTR, struct drm_i915_gem_userptr)
|
2014-12-24 23:13:40 +07:00
|
|
|
#define DRM_IOCTL_I915_GEM_CONTEXT_GETPARAM DRM_IOWR (DRM_COMMAND_BASE + DRM_I915_GEM_CONTEXT_GETPARAM, struct drm_i915_gem_context_param)
|
|
|
|
#define DRM_IOCTL_I915_GEM_CONTEXT_SETPARAM DRM_IOWR (DRM_COMMAND_BASE + DRM_I915_GEM_CONTEXT_SETPARAM, struct drm_i915_gem_context_param)
|
drm/i915: Add i915 perf infrastructure
Adds base i915 perf infrastructure for Gen performance metrics.
This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
properties to configure a stream of metrics and returns a new fd usable
with standard VFS system calls including read() to read typed and sized
records; ioctl() to enable or disable capture and poll() to wait for
data.
A stream is opened something like:
uint64_t properties[] = {
/* Single context sampling */
DRM_I915_PERF_PROP_CTX_HANDLE, ctx_handle,
/* Include OA reports in samples */
DRM_I915_PERF_PROP_SAMPLE_OA, true,
/* OA unit configuration */
DRM_I915_PERF_PROP_OA_METRICS_SET, metrics_set_id,
DRM_I915_PERF_PROP_OA_FORMAT, report_format,
DRM_I915_PERF_PROP_OA_EXPONENT, period_exponent,
};
struct drm_i915_perf_open_param parm = {
.flags = I915_PERF_FLAG_FD_CLOEXEC |
I915_PERF_FLAG_FD_NONBLOCK |
I915_PERF_FLAG_DISABLED,
.properties_ptr = (uint64_t)properties,
.num_properties = sizeof(properties) / 16,
};
int fd = drmIoctl(drm_fd, DRM_IOCTL_I915_PERF_OPEN, ¶m);
Records read all start with a common { type, size } header with
DRM_I915_PERF_RECORD_SAMPLE being of most interest. Sample records
contain an extensible number of fields and it's the
DRM_I915_PERF_PROP_SAMPLE_xyz properties given when opening that
determine what's included in every sample.
No specific streams are supported yet so any attempt to open a stream
will return an error.
v2:
use i915_gem_context_get() - Chris Wilson
v3:
update read() interface to avoid passing state struct - Chris Wilson
fix some rebase fallout, with i915-perf init/deinit
v4:
s/DRM_IORW/DRM_IOW/ - Emil Velikov
Signed-off-by: Robert Bragg <robert@sixbynine.org>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Sourab Gupta <sourab.gupta@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161107194957.3385-2-robert@sixbynine.org
2016-11-08 02:49:47 +07:00
|
|
|
#define DRM_IOCTL_I915_PERF_OPEN DRM_IOW(DRM_COMMAND_BASE + DRM_I915_PERF_OPEN, struct drm_i915_perf_open_param)
|
2017-08-04 00:05:50 +07:00
|
|
|
#define DRM_IOCTL_I915_PERF_ADD_CONFIG DRM_IOW(DRM_COMMAND_BASE + DRM_I915_PERF_ADD_CONFIG, struct drm_i915_perf_oa_config)
|
|
|
|
#define DRM_IOCTL_I915_PERF_REMOVE_CONFIG DRM_IOW(DRM_COMMAND_BASE + DRM_I915_PERF_REMOVE_CONFIG, __u64)
|
2018-03-06 19:28:56 +07:00
|
|
|
#define DRM_IOCTL_I915_QUERY DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_QUERY, struct drm_i915_query)
|
2019-05-22 04:11:25 +07:00
|
|
|
#define DRM_IOCTL_I915_GEM_VM_CREATE DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_VM_CREATE, struct drm_i915_gem_vm_control)
|
|
|
|
#define DRM_IOCTL_I915_GEM_VM_DESTROY DRM_IOW (DRM_COMMAND_BASE + DRM_I915_GEM_VM_DESTROY, struct drm_i915_gem_vm_control)
|
2012-10-05 00:21:50 +07:00
|
|
|
|
|
|
|
/* Allow drivers to submit batchbuffers directly to hardware, relying
|
|
|
|
* on the security mechanisms provided by hardware.
|
|
|
|
*/
|
|
|
|
typedef struct 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.
|
|
|
|
*/
|
|
|
|
typedef struct _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:
|
|
|
|
*/
|
|
|
|
typedef struct drm_i915_irq_emit {
|
|
|
|
int __user *irq_seq;
|
|
|
|
} drm_i915_irq_emit_t;
|
|
|
|
|
|
|
|
typedef struct drm_i915_irq_wait {
|
|
|
|
int irq_seq;
|
|
|
|
} drm_i915_irq_wait_t;
|
|
|
|
|
2018-09-27 03:12:22 +07:00
|
|
|
/*
|
|
|
|
* 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
|
|
|
|
|
2012-10-05 00:21:50 +07:00
|
|
|
/* Ioctl to query kernel params:
|
|
|
|
*/
|
|
|
|
#define I915_PARAM_IRQ_ACTIVE 1
|
|
|
|
#define I915_PARAM_ALLOW_BATCHBUFFER 2
|
|
|
|
#define I915_PARAM_LAST_DISPATCH 3
|
|
|
|
#define I915_PARAM_CHIPSET_ID 4
|
|
|
|
#define I915_PARAM_HAS_GEM 5
|
|
|
|
#define I915_PARAM_NUM_FENCES_AVAIL 6
|
|
|
|
#define I915_PARAM_HAS_OVERLAY 7
|
|
|
|
#define I915_PARAM_HAS_PAGEFLIPPING 8
|
|
|
|
#define I915_PARAM_HAS_EXECBUF2 9
|
|
|
|
#define I915_PARAM_HAS_BSD 10
|
|
|
|
#define I915_PARAM_HAS_BLT 11
|
|
|
|
#define I915_PARAM_HAS_RELAXED_FENCING 12
|
|
|
|
#define I915_PARAM_HAS_COHERENT_RINGS 13
|
|
|
|
#define I915_PARAM_HAS_EXEC_CONSTANTS 14
|
|
|
|
#define I915_PARAM_HAS_RELAXED_DELTA 15
|
|
|
|
#define I915_PARAM_HAS_GEN7_SOL_RESET 16
|
|
|
|
#define I915_PARAM_HAS_LLC 17
|
|
|
|
#define I915_PARAM_HAS_ALIASING_PPGTT 18
|
|
|
|
#define I915_PARAM_HAS_WAIT_TIMEOUT 19
|
|
|
|
#define I915_PARAM_HAS_SEMAPHORES 20
|
|
|
|
#define I915_PARAM_HAS_PRIME_VMAP_FLUSH 21
|
2013-05-29 09:22:34 +07:00
|
|
|
#define I915_PARAM_HAS_VEBOX 22
|
2012-10-22 19:34:51 +07:00
|
|
|
#define I915_PARAM_HAS_SECURE_BATCHES 23
|
2012-12-17 22:21:27 +07:00
|
|
|
#define I915_PARAM_HAS_PINNED_BATCHES 24
|
2013-01-18 04:23:36 +07:00
|
|
|
#define I915_PARAM_HAS_EXEC_NO_RELOC 25
|
2013-01-08 17:53:17 +07:00
|
|
|
#define I915_PARAM_HAS_EXEC_HANDLE_LUT 26
|
2013-08-08 20:41:10 +07:00
|
|
|
#define I915_PARAM_HAS_WT 27
|
2014-02-19 01:15:56 +07:00
|
|
|
#define I915_PARAM_CMD_PARSER_VERSION 28
|
2014-11-04 19:51:40 +07:00
|
|
|
#define I915_PARAM_HAS_COHERENT_PHYS_GTT 29
|
drm/i915: Support creation of unbound wc user mappings for objects
This patch provides support to create write-combining virtual mappings of
GEM object. It intends to provide the same funtionality of 'mmap_gtt'
interface without the constraints and contention of a limited aperture
space, but requires clients handles the linear to tile conversion on their
own. This is for improving the CPU write operation performance, as with such
mapping, writes and reads are almost 50% faster than with mmap_gtt. Similar
to the GTT mmapping, unlike the regular CPU mmapping, it avoids the cache
flush after update from CPU side, when object is passed onto GPU. This
type of mapping is specially useful in case of sub-region update,
i.e. when only a portion of the object is to be updated. Using a CPU mmap
in such cases would normally incur a clflush of the whole object, and
using a GTT mmapping would likely require eviction of an active object or
fence and thus stall. The write-combining CPU mmap avoids both.
To ensure the cache coherency, before using this mapping, the GTT domain
has been reused here. This provides the required cache flush if the object
is in CPU domain or synchronization against the concurrent rendering.
Although the access through an uncached mmap should automatically
invalidate the cache lines, this may not be true for non-temporal write
instructions and also not all pages of the object may be updated at any
given point of time through this mapping. Having a call to get_pages in
set_to_gtt_domain function, as added in the earlier patch 'drm/i915:
Broaden application of set-domain(GTT)', would guarantee the clflush and
so there will be no cachelines holding the data for the object before it
is accessed through this map.
The drm_i915_gem_mmap structure (for the DRM_I915_GEM_MMAP_IOCTL) has been
extended with a new flags field (defaulting to 0 for existent users). In
order for userspace to detect the extended ioctl, a new parameter
I915_PARAM_MMAP_VERSION has been added for versioning the ioctl interface.
v2: Fix error handling, invalid flag detection, renaming (ickle)
v3: Rebase to latest drm-intel-nightly codebase
The new mmapping is exercised by igt/gem_mmap_wc,
igt/gem_concurrent_blit and igt/gem_gtt_speed.
Change-Id: Ie883942f9e689525f72fe9a8d3780c3a9faa769a
Signed-off-by: Akash Goel <akash.goel@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-02 17:59:30 +07:00
|
|
|
#define I915_PARAM_MMAP_VERSION 30
|
2015-01-13 07:48:25 +07:00
|
|
|
#define I915_PARAM_HAS_BSD2 31
|
2015-03-04 21:41:16 +07:00
|
|
|
#define I915_PARAM_REVISION 32
|
2015-03-10 06:06:54 +07:00
|
|
|
#define I915_PARAM_SUBSLICE_TOTAL 33
|
|
|
|
#define I915_PARAM_EU_TOTAL 34
|
2015-06-15 18:23:48 +07:00
|
|
|
#define I915_PARAM_HAS_GPU_RESET 35
|
2015-07-01 14:12:23 +07:00
|
|
|
#define I915_PARAM_HAS_RESOURCE_STREAMER 36
|
2015-12-08 18:55:07 +07:00
|
|
|
#define I915_PARAM_HAS_EXEC_SOFTPIN 37
|
2016-07-01 17:43:02 +07:00
|
|
|
#define I915_PARAM_HAS_POOLED_EU 38
|
|
|
|
#define I915_PARAM_MIN_EU_IN_POOL 39
|
2016-08-26 01:05:19 +07:00
|
|
|
#define I915_PARAM_MMAP_GTT_VERSION 40
|
2012-10-05 00:21:50 +07:00
|
|
|
|
2017-10-04 03:34:51 +07:00
|
|
|
/*
|
|
|
|
* Query whether DRM_I915_GEM_EXECBUFFER2 supports user defined execution
|
2016-11-15 03:41:01 +07:00
|
|
|
* priorities and the driver will attempt to execute batches in priority order.
|
2017-10-04 03:34:51 +07:00
|
|
|
* The param returns a capability bitmask, nonzero implies that the scheduler
|
|
|
|
* is enabled, with different features present according to the mask.
|
drm/i915/scheduler: Support user-defined priorities
Use a priority stored in the context as the initial value when
submitting a request. This allows us to change the default priority on a
per-context basis, allowing different contexts to be favoured with GPU
time at the expense of lower importance work. The user can adjust the
context's priority via I915_CONTEXT_PARAM_PRIORITY, with more positive
values being higher priority (they will be serviced earlier, after their
dependencies have been resolved). Any prerequisite work for an execbuf
will have its priority raised to match the new request as required.
Normal users can specify any value in the range of -1023 to 0 [default],
i.e. they can reduce the priority of their workloads (and temporarily
boost it back to normal if so desired).
Privileged users can specify any value in the range of -1023 to 1023,
[default is 0], i.e. they can raise their priority above all overs and
so potentially starve the system.
Note that the existing schedulers are not fair, nor load balancing, the
execution is strictly by priority on a first-come, first-served basis,
and the driver may choose to boost some requests above the range
available to users.
This priority was originally based around nice(2), but evolved to allow
clients to adjust their priority within a small range, and allow for a
privileged high priority range.
For example, this can be used to implement EGL_IMG_context_priority
https://www.khronos.org/registry/egl/extensions/IMG/EGL_IMG_context_priority.txt
EGL_CONTEXT_PRIORITY_LEVEL_IMG determines the priority level of
the context to be created. This attribute is a hint, as an
implementation may not support multiple contexts at some
priority levels and system policy may limit access to high
priority contexts to appropriate system privilege level. The
default value for EGL_CONTEXT_PRIORITY_LEVEL_IMG is
EGL_CONTEXT_PRIORITY_MEDIUM_IMG."
so we can map
PRIORITY_HIGH -> 1023 [privileged, will failback to 0]
PRIORITY_MED -> 0 [default]
PRIORITY_LOW -> -1023
They also map onto the priorities used by VkQueue (and a VkQueue is
essentially a timeline, our i915_gem_context under full-ppgtt).
v2: s/CAP_SYS_ADMIN/CAP_SYS_NICE/
v3: Report min/max user priorities as defines in the uapi, and rebase
internal priorities on the exposed values.
Testcase: igt/gem_exec_schedule
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171003203453.15692-9-chris@chris-wilson.co.uk
2017-10-04 03:34:53 +07:00
|
|
|
*
|
|
|
|
* The initial priority for each batch is supplied by the context and is
|
|
|
|
* controlled via I915_CONTEXT_PARAM_PRIORITY.
|
2016-11-15 03:41:01 +07:00
|
|
|
*/
|
|
|
|
#define I915_PARAM_HAS_SCHEDULER 41
|
2017-10-04 03:34:51 +07:00
|
|
|
#define I915_SCHEDULER_CAP_ENABLED (1ul << 0)
|
|
|
|
#define I915_SCHEDULER_CAP_PRIORITY (1ul << 1)
|
|
|
|
#define I915_SCHEDULER_CAP_PREEMPTION (1ul << 2)
|
2019-03-02 00:09:00 +07:00
|
|
|
#define I915_SCHEDULER_CAP_SEMAPHORES (1ul << 3)
|
2017-10-04 03:34:51 +07:00
|
|
|
|
2017-01-18 23:05:58 +07:00
|
|
|
#define I915_PARAM_HUC_STATUS 42
|
2016-11-15 03:41:01 +07:00
|
|
|
|
2017-01-27 16:40:07 +07:00
|
|
|
/* 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
|
|
|
|
|
2017-01-27 16:40:08 +07:00
|
|
|
/* 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
|
|
|
|
|
2017-04-15 16:39:02 +07:00
|
|
|
/* Query whether DRM_I915_GEM_EXECBUFFER2 supports the ability to capture
|
|
|
|
* user specified bufffers for post-mortem debugging of GPU hangs. See
|
|
|
|
* EXEC_OBJECT_CAPTURE.
|
|
|
|
*/
|
|
|
|
#define I915_PARAM_HAS_EXEC_CAPTURE 45
|
|
|
|
|
2017-06-13 18:22:59 +07:00
|
|
|
#define I915_PARAM_SLICE_MASK 46
|
|
|
|
|
2017-06-13 18:23:00 +07:00
|
|
|
/* Assuming it's uniform for each slice, this queries the mask of subslices
|
|
|
|
* per-slice for this system.
|
|
|
|
*/
|
|
|
|
#define I915_PARAM_SUBSLICE_MASK 47
|
|
|
|
|
2017-06-16 21:05:23 +07:00
|
|
|
/*
|
|
|
|
* 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
|
|
|
|
|
2017-08-15 21:57:33 +07:00
|
|
|
/* 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
|
|
|
|
|
2017-11-10 21:26:33 +07:00
|
|
|
/*
|
|
|
|
* 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
|
|
|
|
|
2017-11-11 02:08:44 +07:00
|
|
|
/* 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
|
|
|
|
|
2018-07-20 17:19:10 +07:00
|
|
|
/*
|
|
|
|
* 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
|
|
|
|
|
2019-05-22 04:11:34 +07:00
|
|
|
/*
|
|
|
|
* 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
|
2019-02-18 16:46:28 +07:00
|
|
|
/* Must be kept compact -- no holes and well documented */
|
|
|
|
|
2012-10-05 00:21:50 +07:00
|
|
|
typedef struct drm_i915_getparam {
|
2015-09-02 18:41:18 +07:00
|
|
|
__s32 param;
|
2015-07-14 23:07:30 +07:00
|
|
|
/*
|
|
|
|
* WARNING: Using pointers instead of fixed-size u64 means we need to write
|
|
|
|
* compat32 code. Don't repeat this mistake.
|
|
|
|
*/
|
2012-10-05 00:21:50 +07:00
|
|
|
int __user *value;
|
|
|
|
} drm_i915_getparam_t;
|
|
|
|
|
|
|
|
/* 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
|
2019-02-18 16:46:28 +07:00
|
|
|
/* Must be kept compact -- no holes */
|
2012-10-05 00:21:50 +07:00
|
|
|
|
|
|
|
typedef struct 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
|
|
|
|
|
|
|
|
typedef struct 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;
|
|
|
|
|
|
|
|
typedef struct drm_i915_mem_free {
|
|
|
|
int region;
|
|
|
|
int region_offset;
|
|
|
|
} drm_i915_mem_free_t;
|
|
|
|
|
|
|
|
typedef struct 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):
|
|
|
|
*/
|
|
|
|
typedef struct 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
|
|
|
|
|
|
|
|
typedef struct drm_i915_vblank_pipe {
|
|
|
|
int pipe;
|
|
|
|
} drm_i915_vblank_pipe_t;
|
|
|
|
|
|
|
|
/* Schedule buffer swap at given vertical blank:
|
|
|
|
*/
|
|
|
|
typedef struct drm_i915_vblank_swap {
|
|
|
|
drm_drawable_t drawable;
|
|
|
|
enum drm_vblank_seq_type seqtype;
|
|
|
|
unsigned int sequence;
|
|
|
|
} drm_i915_vblank_swap_t;
|
|
|
|
|
|
|
|
typedef struct drm_i915_hws_addr {
|
|
|
|
__u64 addr;
|
|
|
|
} drm_i915_hws_addr_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;
|
drm/i915: Support creation of unbound wc user mappings for objects
This patch provides support to create write-combining virtual mappings of
GEM object. It intends to provide the same funtionality of 'mmap_gtt'
interface without the constraints and contention of a limited aperture
space, but requires clients handles the linear to tile conversion on their
own. This is for improving the CPU write operation performance, as with such
mapping, writes and reads are almost 50% faster than with mmap_gtt. Similar
to the GTT mmapping, unlike the regular CPU mmapping, it avoids the cache
flush after update from CPU side, when object is passed onto GPU. This
type of mapping is specially useful in case of sub-region update,
i.e. when only a portion of the object is to be updated. Using a CPU mmap
in such cases would normally incur a clflush of the whole object, and
using a GTT mmapping would likely require eviction of an active object or
fence and thus stall. The write-combining CPU mmap avoids both.
To ensure the cache coherency, before using this mapping, the GTT domain
has been reused here. This provides the required cache flush if the object
is in CPU domain or synchronization against the concurrent rendering.
Although the access through an uncached mmap should automatically
invalidate the cache lines, this may not be true for non-temporal write
instructions and also not all pages of the object may be updated at any
given point of time through this mapping. Having a call to get_pages in
set_to_gtt_domain function, as added in the earlier patch 'drm/i915:
Broaden application of set-domain(GTT)', would guarantee the clflush and
so there will be no cachelines holding the data for the object before it
is accessed through this map.
The drm_i915_gem_mmap structure (for the DRM_I915_GEM_MMAP_IOCTL) has been
extended with a new flags field (defaulting to 0 for existent users). In
order for userspace to detect the extended ioctl, a new parameter
I915_PARAM_MMAP_VERSION has been added for versioning the ioctl interface.
v2: Fix error handling, invalid flag detection, renaming (ickle)
v3: Rebase to latest drm-intel-nightly codebase
The new mmapping is exercised by igt/gem_mmap_wc,
igt/gem_concurrent_blit and igt/gem_gtt_speed.
Change-Id: Ie883942f9e689525f72fe9a8d3780c3a9faa769a
Signed-off-by: Akash Goel <akash.goel@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-02 17:59:30 +07:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Flags for extended behaviour.
|
|
|
|
*
|
|
|
|
* Added in version 2.
|
|
|
|
*/
|
|
|
|
__u64 flags;
|
|
|
|
#define I915_MMAP_WC 0x1
|
2012-10-05 00:21:50 +07:00
|
|
|
};
|
|
|
|
|
|
|
|
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_set_domain {
|
|
|
|
/** Handle for the object */
|
|
|
|
__u32 handle;
|
|
|
|
|
|
|
|
/** New read domains */
|
|
|
|
__u32 read_domains;
|
|
|
|
|
|
|
|
/** New write 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
|
2017-04-12 18:01:11 +07:00
|
|
|
/** WC domain - uncached access */
|
|
|
|
#define I915_GEM_DOMAIN_WC 0x00000080
|
2012-10-05 00:21:50 +07:00
|
|
|
/** @} */
|
|
|
|
|
|
|
|
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;
|
|
|
|
};
|
|
|
|
|
|
|
|
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;
|
|
|
|
|
|
|
|
/**
|
2015-12-08 18:55:07 +07:00
|
|
|
* 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.
|
2012-10-05 00:21:50 +07:00
|
|
|
*/
|
|
|
|
__u64 offset;
|
|
|
|
|
2016-07-14 20:52:03 +07:00
|
|
|
#define EXEC_OBJECT_NEEDS_FENCE (1<<0)
|
|
|
|
#define EXEC_OBJECT_NEEDS_GTT (1<<1)
|
|
|
|
#define EXEC_OBJECT_WRITE (1<<2)
|
2015-10-01 19:33:57 +07:00
|
|
|
#define EXEC_OBJECT_SUPPORTS_48B_ADDRESS (1<<3)
|
2016-07-14 20:52:03 +07:00
|
|
|
#define EXEC_OBJECT_PINNED (1<<4)
|
2016-08-04 22:32:23 +07:00
|
|
|
#define EXEC_OBJECT_PAD_TO_SIZE (1<<5)
|
2017-01-27 16:40:07 +07:00
|
|
|
/* 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)
|
2017-04-15 16:39:02 +07:00
|
|
|
/* 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)
|
2016-07-14 20:52:03 +07:00
|
|
|
/* All remaining bits are MBZ and RESERVED FOR FUTURE USE */
|
2017-04-15 16:39:02 +07:00
|
|
|
#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_CAPTURE<<1)
|
2012-10-05 00:21:50 +07:00
|
|
|
__u64 flags;
|
2013-01-18 04:23:36 +07:00
|
|
|
|
2016-08-04 22:32:23 +07:00
|
|
|
union {
|
|
|
|
__u64 rsvd1;
|
|
|
|
__u64 pad_to_size;
|
|
|
|
};
|
2012-10-05 00:21:50 +07:00
|
|
|
__u64 rsvd2;
|
|
|
|
};
|
|
|
|
|
2017-08-15 21:57:33 +07:00
|
|
|
struct drm_i915_gem_exec_fence {
|
|
|
|
/**
|
|
|
|
* User's handle for a drm_syncobj to wait on or signal.
|
|
|
|
*/
|
|
|
|
__u32 handle;
|
|
|
|
|
|
|
|
#define I915_EXEC_FENCE_WAIT (1<<0)
|
|
|
|
#define I915_EXEC_FENCE_SIGNAL (1<<1)
|
2017-10-31 17:23:25 +07:00
|
|
|
#define __I915_EXEC_FENCE_UNKNOWN_FLAGS (-(I915_EXEC_FENCE_SIGNAL << 1))
|
2017-08-15 21:57:33 +07:00
|
|
|
__u32 flags;
|
|
|
|
};
|
|
|
|
|
2012-10-05 00:21:50 +07:00
|
|
|
struct drm_i915_gem_execbuffer2 {
|
|
|
|
/**
|
|
|
|
* List of gem_exec_object2 structs
|
|
|
|
*/
|
|
|
|
__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;
|
2017-08-15 21:57:33 +07:00
|
|
|
/**
|
|
|
|
* This is a struct drm_clip_rect *cliprects if I915_EXEC_FENCE_ARRAY
|
|
|
|
* is not set. If I915_EXEC_FENCE_ARRAY is set, then this is a
|
|
|
|
* struct drm_i915_gem_exec_fence *fences.
|
|
|
|
*/
|
2012-10-05 00:21:50 +07:00
|
|
|
__u64 cliprects_ptr;
|
2019-03-01 21:03:47 +07:00
|
|
|
#define I915_EXEC_RING_MASK (0x3f)
|
2012-10-05 00:21:50 +07:00
|
|
|
#define I915_EXEC_DEFAULT (0<<0)
|
|
|
|
#define I915_EXEC_RENDER (1<<0)
|
|
|
|
#define I915_EXEC_BSD (2<<0)
|
|
|
|
#define I915_EXEC_BLT (3<<0)
|
2013-05-29 09:22:33 +07:00
|
|
|
#define I915_EXEC_VEBOX (4<<0)
|
2012-10-05 00:21:50 +07:00
|
|
|
|
|
|
|
/* 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 */
|
|
|
|
__u64 flags;
|
|
|
|
__u64 rsvd1; /* now used for context info */
|
|
|
|
__u64 rsvd2;
|
|
|
|
};
|
|
|
|
|
|
|
|
/** Resets the SO write offset registers for transform feedback on gen7. */
|
|
|
|
#define I915_EXEC_GEN7_SOL_RESET (1<<8)
|
|
|
|
|
2012-10-22 19:34:51 +07:00
|
|
|
/** Request a privileged ("secure") batch buffer. Note only available for
|
|
|
|
* DRM_ROOT_ONLY | DRM_MASTER processes.
|
|
|
|
*/
|
|
|
|
#define I915_EXEC_SECURE (1<<9)
|
|
|
|
|
2012-12-17 22:21:27 +07:00
|
|
|
/** 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)
|
|
|
|
|
2014-01-12 20:08:43 +07:00
|
|
|
/** Provide a hint to the kernel that the command stream and auxiliary
|
2013-01-18 04:23:36 +07:00
|
|
|
* 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)
|
|
|
|
|
2013-01-08 17:53:17 +07:00
|
|
|
/** 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)
|
|
|
|
|
2015-01-13 07:48:24 +07:00
|
|
|
/** Used for switching BSD rings on the platforms with two BSD rings */
|
2016-01-27 20:41:09 +07:00
|
|
|
#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)
|
2015-01-13 07:48:24 +07:00
|
|
|
|
2015-07-01 14:12:23 +07:00
|
|
|
/** Tell the kernel that the batchbuffer is processed by
|
|
|
|
* the resource streamer.
|
|
|
|
*/
|
|
|
|
#define I915_EXEC_RESOURCE_STREAMER (1<<15)
|
|
|
|
|
2017-01-27 16:40:08 +07:00
|
|
|
/* 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)
|
|
|
|
|
2017-06-16 21:05:23 +07:00
|
|
|
/*
|
|
|
|
* 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)
|
2017-08-15 21:57:33 +07:00
|
|
|
|
|
|
|
/* 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)
|
|
|
|
|
2019-05-22 04:11:34 +07:00
|
|
|
/*
|
|
|
|
* 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)
|
|
|
|
|
|
|
|
#define __I915_EXEC_UNKNOWN_FLAGS (-(I915_EXEC_FENCE_SUBMIT << 1))
|
2013-01-18 04:23:36 +07:00
|
|
|
|
2012-10-05 00:21:50 +07:00
|
|
|
#define I915_EXEC_CONTEXT_ID_MASK (0xffffffff)
|
|
|
|
#define i915_execbuffer2_set_context_id(eb2, context) \
|
|
|
|
(eb2).rsvd1 = context & I915_EXEC_CONTEXT_ID_MASK
|
|
|
|
#define i915_execbuffer2_get_context_id(eb2) \
|
|
|
|
((eb2).rsvd1 & I915_EXEC_CONTEXT_ID_MASK)
|
|
|
|
|
|
|
|
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;
|
|
|
|
|
2016-01-15 23:51:46 +07:00
|
|
|
/** 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
|
2016-08-16 15:50:40 +07:00
|
|
|
* 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
|
2019-03-05 23:26:43 +07:00
|
|
|
* 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.
|
2016-01-15 23:51:46 +07:00
|
|
|
*
|
|
|
|
* The returned dword is split into two fields to indicate both
|
2019-03-05 23:26:43 +07:00
|
|
|
* the engine classess on which the object is being read, and the
|
|
|
|
* engine class on which it is currently being written (if any).
|
2016-01-15 23:51:46 +07:00
|
|
|
*
|
|
|
|
* 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
|
2019-03-05 23:26:43 +07:00
|
|
|
* engine class (offset by 1, I915_ENGINE_CLASS_RENDER is reported as
|
|
|
|
* 1 not 0 etc) for the last write is reported.
|
2016-01-15 23:51:46 +07:00
|
|
|
*
|
2019-03-05 23:26:43 +07:00
|
|
|
* The high word (bits 16:31) are a bitmask of which engines classes
|
|
|
|
* are currently reading from the object. Multiple engines may be
|
2016-01-15 23:51:46 +07:00
|
|
|
* reading from the object simultaneously.
|
|
|
|
*
|
2019-03-05 23:26:43 +07:00
|
|
|
* The value of each engine class is the same as specified in the
|
|
|
|
* I915_CONTEXT_SET_ENGINES parameter and via perf, i.e.
|
|
|
|
* I915_ENGINE_CLASS_RENDER, I915_ENGINE_CLASS_COPY, etc.
|
2016-01-15 23:51:46 +07:00
|
|
|
* reported as active itself. Some hardware may have parallel
|
|
|
|
* execution engines, e.g. multiple media engines, which are
|
2019-03-05 23:26:43 +07:00
|
|
|
* mapped to the same class identifier and so are not separately
|
|
|
|
* reported for busyness.
|
2016-08-16 15:50:40 +07:00
|
|
|
*
|
|
|
|
* 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.
|
2012-10-05 00:21:50 +07:00
|
|
|
*/
|
|
|
|
__u32 busy;
|
|
|
|
};
|
|
|
|
|
2013-08-10 19:51:11 +07:00
|
|
|
/**
|
|
|
|
* I915_CACHING_NONE
|
|
|
|
*
|
|
|
|
* GPU access is not coherent with cpu caches. Default for machines without an
|
|
|
|
* LLC.
|
|
|
|
*/
|
2012-10-05 00:21:50 +07:00
|
|
|
#define I915_CACHING_NONE 0
|
2013-08-10 19:51:11 +07:00
|
|
|
/**
|
|
|
|
* 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. Default on
|
|
|
|
* machines with HAS_LLC.
|
|
|
|
*/
|
2012-10-05 00:21:50 +07:00
|
|
|
#define I915_CACHING_CACHED 1
|
2013-08-10 19:51:11 +07:00
|
|
|
/**
|
|
|
|
* 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_DISPLAY 2
|
2012-10-05 00:21:50 +07:00
|
|
|
|
|
|
|
struct drm_i915_gem_caching {
|
|
|
|
/**
|
|
|
|
* Handle of the buffer to set/get the caching level of. */
|
|
|
|
__u32 handle;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Cacheing level to apply or return value
|
|
|
|
*
|
|
|
|
* bits0-15 are for generic caching control (i.e. the above defined
|
|
|
|
* values). bits16-31 are reserved for platform-specific variations
|
|
|
|
* (e.g. l3$ caching on gen7). */
|
|
|
|
__u32 caching;
|
|
|
|
};
|
|
|
|
|
|
|
|
#define I915_TILING_NONE 0
|
|
|
|
#define I915_TILING_X 1
|
|
|
|
#define I915_TILING_Y 2
|
2016-08-05 16:14:22 +07:00
|
|
|
#define I915_TILING_LAST I915_TILING_Y
|
2012-10-05 00:21:50 +07:00
|
|
|
|
|
|
|
#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;
|
2014-10-24 18:11:11 +07:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Returned address bit 6 swizzling required for CPU access through
|
|
|
|
* mmap mapping whilst bound.
|
|
|
|
*/
|
|
|
|
__u32 phys_swizzle_mode;
|
2012-10-05 00:21:50 +07:00
|
|
|
};
|
|
|
|
|
|
|
|
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;
|
|
|
|
|
|
|
|
/** pipe of requested CRTC **/
|
|
|
|
__u32 pipe;
|
|
|
|
};
|
|
|
|
|
|
|
|
#define I915_MADV_WILLNEED 0
|
|
|
|
#define I915_MADV_DONTNEED 1
|
|
|
|
#define __I915_MADV_PURGED 2 /* internal state */
|
|
|
|
|
|
|
|
struct drm_i915_gem_madvise {
|
|
|
|
/** Handle of the buffer to change the backing store advice */
|
|
|
|
__u32 handle;
|
|
|
|
|
|
|
|
/* Advice: either the buffer will be needed again in the near future,
|
|
|
|
* or wont be and could be discarded under memory pressure.
|
|
|
|
*/
|
|
|
|
__u32 madv;
|
|
|
|
|
|
|
|
/** Whether the backing store still exists. */
|
|
|
|
__u32 retained;
|
|
|
|
};
|
|
|
|
|
|
|
|
/* flags */
|
|
|
|
#define I915_OVERLAY_TYPE_MASK 0xff
|
|
|
|
#define I915_OVERLAY_YUV_PLANAR 0x01
|
|
|
|
#define I915_OVERLAY_YUV_PACKED 0x02
|
|
|
|
#define I915_OVERLAY_RGB 0x03
|
|
|
|
|
|
|
|
#define I915_OVERLAY_DEPTH_MASK 0xff00
|
|
|
|
#define I915_OVERLAY_RGB24 0x1000
|
|
|
|
#define I915_OVERLAY_RGB16 0x2000
|
|
|
|
#define I915_OVERLAY_RGB15 0x3000
|
|
|
|
#define I915_OVERLAY_YUV422 0x0100
|
|
|
|
#define I915_OVERLAY_YUV411 0x0200
|
|
|
|
#define I915_OVERLAY_YUV420 0x0300
|
|
|
|
#define I915_OVERLAY_YUV410 0x0400
|
|
|
|
|
|
|
|
#define I915_OVERLAY_SWAP_MASK 0xff0000
|
|
|
|
#define I915_OVERLAY_NO_SWAP 0x000000
|
|
|
|
#define I915_OVERLAY_UV_SWAP 0x010000
|
|
|
|
#define I915_OVERLAY_Y_SWAP 0x020000
|
|
|
|
#define I915_OVERLAY_Y_AND_UV_SWAP 0x030000
|
|
|
|
|
|
|
|
#define I915_OVERLAY_FLAGS_MASK 0xff000000
|
|
|
|
#define I915_OVERLAY_ENABLE 0x01000000
|
|
|
|
|
|
|
|
struct drm_intel_overlay_put_image {
|
|
|
|
/* various flags and src format description */
|
|
|
|
__u32 flags;
|
|
|
|
/* source picture description */
|
|
|
|
__u32 bo_handle;
|
|
|
|
/* stride values and offsets are in bytes, buffer relative */
|
|
|
|
__u16 stride_Y; /* stride for packed formats */
|
|
|
|
__u16 stride_UV;
|
|
|
|
__u32 offset_Y; /* offset for packet formats */
|
|
|
|
__u32 offset_U;
|
|
|
|
__u32 offset_V;
|
|
|
|
/* in pixels */
|
|
|
|
__u16 src_width;
|
|
|
|
__u16 src_height;
|
|
|
|
/* to compensate the scaling factors for partially covered surfaces */
|
|
|
|
__u16 src_scan_width;
|
|
|
|
__u16 src_scan_height;
|
|
|
|
/* output crtc description */
|
|
|
|
__u32 crtc_id;
|
|
|
|
__u16 dst_x;
|
|
|
|
__u16 dst_y;
|
|
|
|
__u16 dst_width;
|
|
|
|
__u16 dst_height;
|
|
|
|
};
|
|
|
|
|
|
|
|
/* flags */
|
|
|
|
#define I915_OVERLAY_UPDATE_ATTRS (1<<0)
|
|
|
|
#define I915_OVERLAY_UPDATE_GAMMA (1<<1)
|
2015-04-02 16:35:08 +07:00
|
|
|
#define I915_OVERLAY_DISABLE_DEST_COLORKEY (1<<2)
|
2012-10-05 00:21:50 +07:00
|
|
|
struct drm_intel_overlay_attrs {
|
|
|
|
__u32 flags;
|
|
|
|
__u32 color_key;
|
|
|
|
__s32 brightness;
|
|
|
|
__u32 contrast;
|
|
|
|
__u32 saturation;
|
|
|
|
__u32 gamma0;
|
|
|
|
__u32 gamma1;
|
|
|
|
__u32 gamma2;
|
|
|
|
__u32 gamma3;
|
|
|
|
__u32 gamma4;
|
|
|
|
__u32 gamma5;
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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.
|
|
|
|
*/
|
|
|
|
|
2018-02-03 03:42:31 +07:00
|
|
|
#define I915_SET_COLORKEY_NONE (1<<0) /* Deprecated. Instead set
|
|
|
|
* flags==0 to disable colorkeying.
|
|
|
|
*/
|
2012-10-05 00:21:50 +07:00
|
|
|
#define I915_SET_COLORKEY_DESTINATION (1<<1)
|
|
|
|
#define I915_SET_COLORKEY_SOURCE (1<<2)
|
|
|
|
struct drm_intel_sprite_colorkey {
|
|
|
|
__u32 plane_id;
|
|
|
|
__u32 min_value;
|
|
|
|
__u32 channel_mask;
|
|
|
|
__u32 max_value;
|
|
|
|
__u32 flags;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct drm_i915_gem_wait {
|
|
|
|
/** Handle of BO we shall wait on */
|
|
|
|
__u32 bo_handle;
|
|
|
|
__u32 flags;
|
|
|
|
/** Number of nanoseconds to wait, Returns time remaining. */
|
|
|
|
__s64 timeout_ns;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct drm_i915_gem_context_create {
|
2019-03-22 16:23:24 +07:00
|
|
|
__u32 ctx_id; /* output: id of new context*/
|
2013-10-30 20:44:16 +07:00
|
|
|
__u32 pad;
|
|
|
|
};
|
|
|
|
|
2019-03-22 16:23:24 +07:00
|
|
|
struct drm_i915_gem_context_create_ext {
|
|
|
|
__u32 ctx_id; /* output: id of new context*/
|
drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl
By exporting the ability to map user address and inserting PTEs
representing their backing pages into the GTT, we can exploit UMA in order
to utilize normal application data as a texture source or even as a
render target (depending upon the capabilities of the chipset). This has
a number of uses, with zero-copy downloads to the GPU and efficient
readback making the intermixed streaming of CPU and GPU operations
fairly efficient. This ability has many widespread implications from
faster rendering of client-side software rasterisers (chromium),
mitigation of stalls due to read back (firefox) and to faster pipelining
of texture data (such as pixel buffer objects in GL or data blobs in CL).
v2: Compile with CONFIG_MMU_NOTIFIER
v3: We can sleep while performing invalidate-range, which we can utilise
to drop our page references prior to the kernel manipulating the vma
(for either discard or cloning) and so protect normal users.
v4: Only run the invalidate notifier if the range intercepts the bo.
v5: Prevent userspace from attempting to GTT mmap non-page aligned buffers
v6: Recheck after reacquire mutex for lost mmu.
v7: Fix implicit padding of ioctl struct by rounding to next 64bit boundary.
v8: Fix rebasing error after forwarding porting the back port.
v9: Limit the userptr to page aligned entries. We now expect userspace
to handle all the offset-in-page adjustments itself.
v10: Prevent vma from being copied across fork to avoid issues with cow.
v11: Drop vma behaviour changes -- locking is nigh on impossible.
Use a worker to load user pages to avoid lock inversions.
v12: Use get_task_mm()/mmput() for correct refcounting of mm.
v13: Use a worker to release the mmu_notifier to avoid lock inversion
v14: Decouple mmu_notifier from struct_mutex using a custom mmu_notifer
with its own locking and tree of objects for each mm/mmu_notifier.
v15: Prevent overlapping userptr objects, and invalidate all objects
within the mmu_notifier range
v16: Fix a typo for iterating over multiple objects in the range and
rearrange error path to destroy the mmu_notifier locklessly.
Also close a race between invalidate_range and the get_pages_worker.
v17: Close a race between get_pages_worker/invalidate_range and fresh
allocations of the same userptr range - and notice that
struct_mutex was presumed to be held when during creation it wasn't.
v18: Sigh. Fix the refactor of st_set_pages() to allocate enough memory
for the struct sg_table and to clear it before reporting an error.
v19: Always error out on read-only userptr requests as we don't have the
hardware infrastructure to support them at the moment.
v20: Refuse to implement read-only support until we have the required
infrastructure - but reserve the bit in flags for future use.
v21: use_mm() is not required for get_user_pages(). It is only meant to
be used to fix up the kernel thread's current->mm for use with
copy_user().
v22: Use sg_alloc_table_from_pages for that chunky feeling
v23: Export a function for sanity checking dma-buf rather than encode
userptr details elsewhere, and clean up comments based on
suggestions by Bradley.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: "Gong, Zhipeng" <zhipeng.gong@intel.com>
Cc: Akash Goel <akash.goel@intel.com>
Cc: "Volkin, Bradley D" <bradley.d.volkin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: Brad Volkin <bradley.d.volkin@intel.com>
[danvet: Frob ioctl allocation to pick the next one - will cause a bit
of fuss with create2 apparently, but such are the rules.]
[danvet2: oops, forgot to git add after manual patch application]
[danvet3: Appease sparse.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-16 20:22:37 +07:00
|
|
|
__u32 flags;
|
2019-03-22 16:23:24 +07:00
|
|
|
#define I915_CONTEXT_CREATE_FLAGS_USE_EXTENSIONS (1u << 0)
|
2019-05-22 04:11:28 +07:00
|
|
|
#define I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE (1u << 1)
|
2019-03-22 16:23:24 +07:00
|
|
|
#define I915_CONTEXT_CREATE_FLAGS_UNKNOWN \
|
2019-05-22 04:11:28 +07:00
|
|
|
(-(I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE << 1))
|
2019-03-22 16:23:24 +07:00
|
|
|
__u64 extensions;
|
drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl
By exporting the ability to map user address and inserting PTEs
representing their backing pages into the GTT, we can exploit UMA in order
to utilize normal application data as a texture source or even as a
render target (depending upon the capabilities of the chipset). This has
a number of uses, with zero-copy downloads to the GPU and efficient
readback making the intermixed streaming of CPU and GPU operations
fairly efficient. This ability has many widespread implications from
faster rendering of client-side software rasterisers (chromium),
mitigation of stalls due to read back (firefox) and to faster pipelining
of texture data (such as pixel buffer objects in GL or data blobs in CL).
v2: Compile with CONFIG_MMU_NOTIFIER
v3: We can sleep while performing invalidate-range, which we can utilise
to drop our page references prior to the kernel manipulating the vma
(for either discard or cloning) and so protect normal users.
v4: Only run the invalidate notifier if the range intercepts the bo.
v5: Prevent userspace from attempting to GTT mmap non-page aligned buffers
v6: Recheck after reacquire mutex for lost mmu.
v7: Fix implicit padding of ioctl struct by rounding to next 64bit boundary.
v8: Fix rebasing error after forwarding porting the back port.
v9: Limit the userptr to page aligned entries. We now expect userspace
to handle all the offset-in-page adjustments itself.
v10: Prevent vma from being copied across fork to avoid issues with cow.
v11: Drop vma behaviour changes -- locking is nigh on impossible.
Use a worker to load user pages to avoid lock inversions.
v12: Use get_task_mm()/mmput() for correct refcounting of mm.
v13: Use a worker to release the mmu_notifier to avoid lock inversion
v14: Decouple mmu_notifier from struct_mutex using a custom mmu_notifer
with its own locking and tree of objects for each mm/mmu_notifier.
v15: Prevent overlapping userptr objects, and invalidate all objects
within the mmu_notifier range
v16: Fix a typo for iterating over multiple objects in the range and
rearrange error path to destroy the mmu_notifier locklessly.
Also close a race between invalidate_range and the get_pages_worker.
v17: Close a race between get_pages_worker/invalidate_range and fresh
allocations of the same userptr range - and notice that
struct_mutex was presumed to be held when during creation it wasn't.
v18: Sigh. Fix the refactor of st_set_pages() to allocate enough memory
for the struct sg_table and to clear it before reporting an error.
v19: Always error out on read-only userptr requests as we don't have the
hardware infrastructure to support them at the moment.
v20: Refuse to implement read-only support until we have the required
infrastructure - but reserve the bit in flags for future use.
v21: use_mm() is not required for get_user_pages(). It is only meant to
be used to fix up the kernel thread's current->mm for use with
copy_user().
v22: Use sg_alloc_table_from_pages for that chunky feeling
v23: Export a function for sanity checking dma-buf rather than encode
userptr details elsewhere, and clean up comments based on
suggestions by Bradley.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: "Gong, Zhipeng" <zhipeng.gong@intel.com>
Cc: Akash Goel <akash.goel@intel.com>
Cc: "Volkin, Bradley D" <bradley.d.volkin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: Brad Volkin <bradley.d.volkin@intel.com>
[danvet: Frob ioctl allocation to pick the next one - will cause a bit
of fuss with create2 apparently, but such are the rules.]
[danvet2: oops, forgot to git add after manual patch application]
[danvet3: Appease sparse.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-16 20:22:37 +07:00
|
|
|
};
|
|
|
|
|
2014-12-24 23:13:40 +07:00
|
|
|
struct drm_i915_gem_context_param {
|
|
|
|
__u32 ctx_id;
|
|
|
|
__u32 size;
|
|
|
|
__u64 param;
|
2015-10-14 20:17:11 +07:00
|
|
|
#define I915_CONTEXT_PARAM_BAN_PERIOD 0x1
|
|
|
|
#define I915_CONTEXT_PARAM_NO_ZEROMAP 0x2
|
|
|
|
#define I915_CONTEXT_PARAM_GTT_SIZE 0x3
|
2016-07-04 14:08:39 +07:00
|
|
|
#define I915_CONTEXT_PARAM_NO_ERROR_CAPTURE 0x4
|
2016-11-16 22:20:32 +07:00
|
|
|
#define I915_CONTEXT_PARAM_BANNABLE 0x5
|
drm/i915/scheduler: Support user-defined priorities
Use a priority stored in the context as the initial value when
submitting a request. This allows us to change the default priority on a
per-context basis, allowing different contexts to be favoured with GPU
time at the expense of lower importance work. The user can adjust the
context's priority via I915_CONTEXT_PARAM_PRIORITY, with more positive
values being higher priority (they will be serviced earlier, after their
dependencies have been resolved). Any prerequisite work for an execbuf
will have its priority raised to match the new request as required.
Normal users can specify any value in the range of -1023 to 0 [default],
i.e. they can reduce the priority of their workloads (and temporarily
boost it back to normal if so desired).
Privileged users can specify any value in the range of -1023 to 1023,
[default is 0], i.e. they can raise their priority above all overs and
so potentially starve the system.
Note that the existing schedulers are not fair, nor load balancing, the
execution is strictly by priority on a first-come, first-served basis,
and the driver may choose to boost some requests above the range
available to users.
This priority was originally based around nice(2), but evolved to allow
clients to adjust their priority within a small range, and allow for a
privileged high priority range.
For example, this can be used to implement EGL_IMG_context_priority
https://www.khronos.org/registry/egl/extensions/IMG/EGL_IMG_context_priority.txt
EGL_CONTEXT_PRIORITY_LEVEL_IMG determines the priority level of
the context to be created. This attribute is a hint, as an
implementation may not support multiple contexts at some
priority levels and system policy may limit access to high
priority contexts to appropriate system privilege level. The
default value for EGL_CONTEXT_PRIORITY_LEVEL_IMG is
EGL_CONTEXT_PRIORITY_MEDIUM_IMG."
so we can map
PRIORITY_HIGH -> 1023 [privileged, will failback to 0]
PRIORITY_MED -> 0 [default]
PRIORITY_LOW -> -1023
They also map onto the priorities used by VkQueue (and a VkQueue is
essentially a timeline, our i915_gem_context under full-ppgtt).
v2: s/CAP_SYS_ADMIN/CAP_SYS_NICE/
v3: Report min/max user priorities as defines in the uapi, and rebase
internal priorities on the exposed values.
Testcase: igt/gem_exec_schedule
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171003203453.15692-9-chris@chris-wilson.co.uk
2017-10-04 03:34:53 +07:00
|
|
|
#define I915_CONTEXT_PARAM_PRIORITY 0x6
|
|
|
|
#define I915_CONTEXT_MAX_USER_PRIORITY 1023 /* inclusive */
|
|
|
|
#define I915_CONTEXT_DEFAULT_PRIORITY 0
|
|
|
|
#define I915_CONTEXT_MIN_USER_PRIORITY -1023 /* inclusive */
|
drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
register stored within the context image (and currently not accessible via
LRI).
If the context is adjusted before first use or whilst idle, the adjustment
is for "free"; otherwise if the context is active we queue a request to do
so (using the kernel context), following all other activity by that
context, which is also marked as barrier for all following submission
against the same context.
Since the overhead of device re-configuration during context switching can
be significant, especially in multi-context workloads, we limit this new
uAPI to only support the Gen11 VME use case. In this use case either the
device is fully enabled, and exactly one slice and half of the subslices
are enabled.
Example usage:
struct drm_i915_gem_context_param_sseu sseu = { };
struct drm_i915_gem_context_param arg = {
.param = I915_CONTEXT_PARAM_SSEU,
.ctx_id = gem_context_create(fd),
.size = sizeof(sseu),
.value = to_user_pointer(&sseu)
};
/* Query device defaults. */
gem_context_get_param(fd, &arg);
/* Set VME configuration on a 1x6x8 part. */
sseu.slice_mask = 0x1;
sseu.subslice_mask = 0xe0;
gem_context_set_param(fd, &arg);
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu()
(Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context
(Chris)
v7: Synchronize the requests following a powergating setting change using
a global dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users
(Lionel/Tvrtko)
v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Don't return EPERM when dynamic sseu is disabled (Tvrtko)
v9: Import context image into kernel context's ppgtt only when
reconfiguring powergated slice/subslices (Chris)
Use aliasing ppgtt when needed (Michel)
Tvrtko Ursulin:
v10:
* Update for upstream changes.
* Request submit needs a RPM reference.
* Reject on !FULL_PPGTT for simplicity.
* Pull out get/set param to helpers for readability and less indent.
* Use i915_request_await_dma_fence in add_global_barrier to skip waits
on the same timeline and avoid GEM_BUG_ON.
* No need to explicitly assign a NULL pointer to engine in legacy mode.
* No need to move gen8_make_rpcs up.
* Factored out global barrier as prep patch.
* Allow to only CAP_SYS_ADMIN if !Gen11.
v11:
* Remove engine vfunc in favour of local helper. (Chris Wilson)
* Stop retiring requests before updates since it is not needed
(Chris Wilson)
* Implement direct CPU update path for idle contexts. (Chris Wilson)
* Left side dependency needs only be on the same context timeline.
(Chris Wilson)
* It is sufficient to order the timeline. (Chris Wilson)
* Reject !RCS configuration attempts with -ENODEV for now.
v12:
* Rebase for make_rpcs.
v13:
* Centralize SSEU normalization to make_rpcs.
* Type width checking (uAPI <-> implementation).
* Gen11 restrictions uAPI checks.
* Gen11 subslice count differences handling.
Chris Wilson:
* args->size handling fixes.
* Update context image from GGTT.
* Postpone context image update to pinning.
* Use i915_gem_active_raw instead of last_request_on_engine.
v14:
* Add activity tracker on intel_context to fix the lifetime issues
and simplify the code. (Chris Wilson)
v15:
* Fix context pin leak if no space in ring by simplifying the
context pinning sequence.
v16:
* Rebase for context get/set param locking changes.
* Just -ENODEV on !Gen11. (Joonas)
v17:
* Fix one Gen11 subslice enablement rule.
* Handle error from i915_sw_fence_await_sw_fence_gfp. (Chris Wilson)
v18:
* Update commit message. (Joonas)
* Restrict uAPI to VME use case. (Joonas)
v19:
* Rebase.
v20:
* Rebase for ce->active_tracker.
v21:
* Rebase for IS_GEN changes.
v22:
* Reserve uAPI for flags straight away. (Chris Wilson)
v23:
* Rebase for RUNTIME_INFO.
v24:
* Added some headline docs for the uapi usage. (Joonas/Chris)
v25:
* Renamed class/instance to engine_class/engine_instance to avoid clash
with C++ keyword. (Tony Ye)
v26:
* Rebased for runtime pm api changes.
v27:
* Rebased for intel_context_init.
* Wrap commit msg to 75.
v28:
(Chris Wilson)
* Use i915_gem_ggtt.
* Use i915_request_await_dma_fence to show a better example.
v29:
* i915_timeline_set_barrier can now fail. (Chris Wilson)
v30:
* Capture some acks.
v31:
* Drop the WARN_ON from use controllable paths. (Chris Wilson)
* Use overflows_type for all checks.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107634
Issue: https://github.com/intel/media-driver/issues/267
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Zhipeng Gong <zhipeng.gong@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tony Ye <tony.ye@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Timo Aaltonen <timo.aaltonen@canonical.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Stéphane Marchesin <marcheu@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190205095032.22673-4-tvrtko.ursulin@linux.intel.com
2019-02-05 16:50:31 +07:00
|
|
|
/*
|
|
|
|
* When using the following param, value should be a pointer to
|
|
|
|
* drm_i915_gem_context_param_sseu.
|
|
|
|
*/
|
|
|
|
#define I915_CONTEXT_PARAM_SSEU 0x7
|
2019-02-18 17:58:21 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Not all clients may want to attempt automatic recover of a context after
|
|
|
|
* a hang (for example, some clients may only submit very small incremental
|
|
|
|
* batches relying on known logical state of previous batches which will never
|
|
|
|
* recover correctly and each attempt will hang), and so would prefer that
|
|
|
|
* the context is forever banned instead.
|
|
|
|
*
|
|
|
|
* If set to false (0), after a reset, subsequent (and in flight) rendering
|
|
|
|
* from this context is discarded, and the client will need to create a new
|
|
|
|
* context to use instead.
|
|
|
|
*
|
|
|
|
* If set to true (1), the kernel will automatically attempt to recover the
|
|
|
|
* context by skipping the hanging batch and executing the next batch starting
|
|
|
|
* from the default context state (discarding the incomplete logical context
|
|
|
|
* state lost due to the reset).
|
|
|
|
*
|
|
|
|
* On creation, all new contexts are marked as recoverable.
|
|
|
|
*/
|
|
|
|
#define I915_CONTEXT_PARAM_RECOVERABLE 0x8
|
2019-05-22 04:11:25 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The id of the associated virtual memory address space (ppGTT) of
|
|
|
|
* this context. Can be retrieved and passed to another context
|
|
|
|
* (on the same fd) for both to use the same ppGTT and so share
|
|
|
|
* address layouts, and avoid reloading the page tables on context
|
|
|
|
* switches between themselves.
|
|
|
|
*
|
|
|
|
* See DRM_I915_GEM_VM_CREATE and DRM_I915_GEM_VM_DESTROY.
|
|
|
|
*/
|
|
|
|
#define I915_CONTEXT_PARAM_VM 0x9
|
drm/i915: Allow a context to define its set of engines
Over the last few years, we have debated how to extend the user API to
support an increase in the number of engines, that may be sparse and
even be heterogeneous within a class (not all video decoders created
equal). We settled on using (class, instance) tuples to identify a
specific engine, with an API for the user to construct a map of engines
to capabilities. Into this picture, we then add a challenge of virtual
engines; one user engine that maps behind the scenes to any number of
physical engines. To keep it general, we want the user to have full
control over that mapping. To that end, we allow the user to constrain a
context to define the set of engines that it can access, order fully
controlled by the user via (class, instance). With such precise control
in context setup, we can continue to use the existing execbuf uABI of
specifying a single index; only now it doesn't automagically map onto
the engines, it uses the user defined engine map from the context.
v2: Fixup freeing of local on success of get_engines()
v3: Allow empty engines[]
v4: s/nengine/num_engines/
v5: Replace 64 limit on num_engines with a note that execbuf is
currently limited to only using the first 64 engines.
v6: Actually use the engines_mutex to guard the ctx->engines.
Testcase: igt/gem_ctx_engines
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190521211134.16117-2-chris@chris-wilson.co.uk
2019-05-22 04:11:26 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* I915_CONTEXT_PARAM_ENGINES:
|
|
|
|
*
|
|
|
|
* Bind this context to operate on this subset of available engines. Henceforth,
|
|
|
|
* the I915_EXEC_RING selector for DRM_IOCTL_I915_GEM_EXECBUFFER2 operates as
|
|
|
|
* an index into this array of engines; I915_EXEC_DEFAULT selecting engine[0]
|
|
|
|
* and upwards. Slots 0...N are filled in using the specified (class, instance).
|
|
|
|
* Use
|
|
|
|
* engine_class: I915_ENGINE_CLASS_INVALID,
|
|
|
|
* engine_instance: I915_ENGINE_CLASS_INVALID_NONE
|
|
|
|
* to specify a gap in the array that can be filled in later, e.g. by a
|
|
|
|
* virtual engine used for load balancing.
|
|
|
|
*
|
|
|
|
* Setting the number of engines bound to the context to 0, by passing a zero
|
|
|
|
* sized argument, will revert back to default settings.
|
|
|
|
*
|
|
|
|
* See struct i915_context_param_engines.
|
2019-05-22 04:11:33 +07:00
|
|
|
*
|
|
|
|
* Extensions:
|
|
|
|
* i915_context_engines_load_balance (I915_CONTEXT_ENGINES_EXT_LOAD_BALANCE)
|
|
|
|
* i915_context_engines_bond (I915_CONTEXT_ENGINES_EXT_BOND)
|
drm/i915: Allow a context to define its set of engines
Over the last few years, we have debated how to extend the user API to
support an increase in the number of engines, that may be sparse and
even be heterogeneous within a class (not all video decoders created
equal). We settled on using (class, instance) tuples to identify a
specific engine, with an API for the user to construct a map of engines
to capabilities. Into this picture, we then add a challenge of virtual
engines; one user engine that maps behind the scenes to any number of
physical engines. To keep it general, we want the user to have full
control over that mapping. To that end, we allow the user to constrain a
context to define the set of engines that it can access, order fully
controlled by the user via (class, instance). With such precise control
in context setup, we can continue to use the existing execbuf uABI of
specifying a single index; only now it doesn't automagically map onto
the engines, it uses the user defined engine map from the context.
v2: Fixup freeing of local on success of get_engines()
v3: Allow empty engines[]
v4: s/nengine/num_engines/
v5: Replace 64 limit on num_engines with a note that execbuf is
currently limited to only using the first 64 engines.
v6: Actually use the engines_mutex to guard the ctx->engines.
Testcase: igt/gem_ctx_engines
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190521211134.16117-2-chris@chris-wilson.co.uk
2019-05-22 04:11:26 +07:00
|
|
|
*/
|
|
|
|
#define I915_CONTEXT_PARAM_ENGINES 0xa
|
2019-02-18 16:46:28 +07:00
|
|
|
/* Must be kept compact -- no holes and well documented */
|
2019-03-22 16:23:23 +07:00
|
|
|
|
2014-12-24 23:13:40 +07:00
|
|
|
__u64 value;
|
|
|
|
};
|
|
|
|
|
drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
register stored within the context image (and currently not accessible via
LRI).
If the context is adjusted before first use or whilst idle, the adjustment
is for "free"; otherwise if the context is active we queue a request to do
so (using the kernel context), following all other activity by that
context, which is also marked as barrier for all following submission
against the same context.
Since the overhead of device re-configuration during context switching can
be significant, especially in multi-context workloads, we limit this new
uAPI to only support the Gen11 VME use case. In this use case either the
device is fully enabled, and exactly one slice and half of the subslices
are enabled.
Example usage:
struct drm_i915_gem_context_param_sseu sseu = { };
struct drm_i915_gem_context_param arg = {
.param = I915_CONTEXT_PARAM_SSEU,
.ctx_id = gem_context_create(fd),
.size = sizeof(sseu),
.value = to_user_pointer(&sseu)
};
/* Query device defaults. */
gem_context_get_param(fd, &arg);
/* Set VME configuration on a 1x6x8 part. */
sseu.slice_mask = 0x1;
sseu.subslice_mask = 0xe0;
gem_context_set_param(fd, &arg);
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu()
(Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context
(Chris)
v7: Synchronize the requests following a powergating setting change using
a global dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users
(Lionel/Tvrtko)
v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Don't return EPERM when dynamic sseu is disabled (Tvrtko)
v9: Import context image into kernel context's ppgtt only when
reconfiguring powergated slice/subslices (Chris)
Use aliasing ppgtt when needed (Michel)
Tvrtko Ursulin:
v10:
* Update for upstream changes.
* Request submit needs a RPM reference.
* Reject on !FULL_PPGTT for simplicity.
* Pull out get/set param to helpers for readability and less indent.
* Use i915_request_await_dma_fence in add_global_barrier to skip waits
on the same timeline and avoid GEM_BUG_ON.
* No need to explicitly assign a NULL pointer to engine in legacy mode.
* No need to move gen8_make_rpcs up.
* Factored out global barrier as prep patch.
* Allow to only CAP_SYS_ADMIN if !Gen11.
v11:
* Remove engine vfunc in favour of local helper. (Chris Wilson)
* Stop retiring requests before updates since it is not needed
(Chris Wilson)
* Implement direct CPU update path for idle contexts. (Chris Wilson)
* Left side dependency needs only be on the same context timeline.
(Chris Wilson)
* It is sufficient to order the timeline. (Chris Wilson)
* Reject !RCS configuration attempts with -ENODEV for now.
v12:
* Rebase for make_rpcs.
v13:
* Centralize SSEU normalization to make_rpcs.
* Type width checking (uAPI <-> implementation).
* Gen11 restrictions uAPI checks.
* Gen11 subslice count differences handling.
Chris Wilson:
* args->size handling fixes.
* Update context image from GGTT.
* Postpone context image update to pinning.
* Use i915_gem_active_raw instead of last_request_on_engine.
v14:
* Add activity tracker on intel_context to fix the lifetime issues
and simplify the code. (Chris Wilson)
v15:
* Fix context pin leak if no space in ring by simplifying the
context pinning sequence.
v16:
* Rebase for context get/set param locking changes.
* Just -ENODEV on !Gen11. (Joonas)
v17:
* Fix one Gen11 subslice enablement rule.
* Handle error from i915_sw_fence_await_sw_fence_gfp. (Chris Wilson)
v18:
* Update commit message. (Joonas)
* Restrict uAPI to VME use case. (Joonas)
v19:
* Rebase.
v20:
* Rebase for ce->active_tracker.
v21:
* Rebase for IS_GEN changes.
v22:
* Reserve uAPI for flags straight away. (Chris Wilson)
v23:
* Rebase for RUNTIME_INFO.
v24:
* Added some headline docs for the uapi usage. (Joonas/Chris)
v25:
* Renamed class/instance to engine_class/engine_instance to avoid clash
with C++ keyword. (Tony Ye)
v26:
* Rebased for runtime pm api changes.
v27:
* Rebased for intel_context_init.
* Wrap commit msg to 75.
v28:
(Chris Wilson)
* Use i915_gem_ggtt.
* Use i915_request_await_dma_fence to show a better example.
v29:
* i915_timeline_set_barrier can now fail. (Chris Wilson)
v30:
* Capture some acks.
v31:
* Drop the WARN_ON from use controllable paths. (Chris Wilson)
* Use overflows_type for all checks.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107634
Issue: https://github.com/intel/media-driver/issues/267
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Zhipeng Gong <zhipeng.gong@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tony Ye <tony.ye@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Timo Aaltonen <timo.aaltonen@canonical.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Stéphane Marchesin <marcheu@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190205095032.22673-4-tvrtko.ursulin@linux.intel.com
2019-02-05 16:50:31 +07:00
|
|
|
/**
|
|
|
|
* 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 {
|
|
|
|
/*
|
|
|
|
* Engine class & instance to be configured or queried.
|
|
|
|
*/
|
2019-04-12 14:14:16 +07:00
|
|
|
struct i915_engine_class_instance engine;
|
drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
register stored within the context image (and currently not accessible via
LRI).
If the context is adjusted before first use or whilst idle, the adjustment
is for "free"; otherwise if the context is active we queue a request to do
so (using the kernel context), following all other activity by that
context, which is also marked as barrier for all following submission
against the same context.
Since the overhead of device re-configuration during context switching can
be significant, especially in multi-context workloads, we limit this new
uAPI to only support the Gen11 VME use case. In this use case either the
device is fully enabled, and exactly one slice and half of the subslices
are enabled.
Example usage:
struct drm_i915_gem_context_param_sseu sseu = { };
struct drm_i915_gem_context_param arg = {
.param = I915_CONTEXT_PARAM_SSEU,
.ctx_id = gem_context_create(fd),
.size = sizeof(sseu),
.value = to_user_pointer(&sseu)
};
/* Query device defaults. */
gem_context_get_param(fd, &arg);
/* Set VME configuration on a 1x6x8 part. */
sseu.slice_mask = 0x1;
sseu.subslice_mask = 0xe0;
gem_context_set_param(fd, &arg);
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu()
(Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context
(Chris)
v7: Synchronize the requests following a powergating setting change using
a global dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users
(Lionel/Tvrtko)
v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Don't return EPERM when dynamic sseu is disabled (Tvrtko)
v9: Import context image into kernel context's ppgtt only when
reconfiguring powergated slice/subslices (Chris)
Use aliasing ppgtt when needed (Michel)
Tvrtko Ursulin:
v10:
* Update for upstream changes.
* Request submit needs a RPM reference.
* Reject on !FULL_PPGTT for simplicity.
* Pull out get/set param to helpers for readability and less indent.
* Use i915_request_await_dma_fence in add_global_barrier to skip waits
on the same timeline and avoid GEM_BUG_ON.
* No need to explicitly assign a NULL pointer to engine in legacy mode.
* No need to move gen8_make_rpcs up.
* Factored out global barrier as prep patch.
* Allow to only CAP_SYS_ADMIN if !Gen11.
v11:
* Remove engine vfunc in favour of local helper. (Chris Wilson)
* Stop retiring requests before updates since it is not needed
(Chris Wilson)
* Implement direct CPU update path for idle contexts. (Chris Wilson)
* Left side dependency needs only be on the same context timeline.
(Chris Wilson)
* It is sufficient to order the timeline. (Chris Wilson)
* Reject !RCS configuration attempts with -ENODEV for now.
v12:
* Rebase for make_rpcs.
v13:
* Centralize SSEU normalization to make_rpcs.
* Type width checking (uAPI <-> implementation).
* Gen11 restrictions uAPI checks.
* Gen11 subslice count differences handling.
Chris Wilson:
* args->size handling fixes.
* Update context image from GGTT.
* Postpone context image update to pinning.
* Use i915_gem_active_raw instead of last_request_on_engine.
v14:
* Add activity tracker on intel_context to fix the lifetime issues
and simplify the code. (Chris Wilson)
v15:
* Fix context pin leak if no space in ring by simplifying the
context pinning sequence.
v16:
* Rebase for context get/set param locking changes.
* Just -ENODEV on !Gen11. (Joonas)
v17:
* Fix one Gen11 subslice enablement rule.
* Handle error from i915_sw_fence_await_sw_fence_gfp. (Chris Wilson)
v18:
* Update commit message. (Joonas)
* Restrict uAPI to VME use case. (Joonas)
v19:
* Rebase.
v20:
* Rebase for ce->active_tracker.
v21:
* Rebase for IS_GEN changes.
v22:
* Reserve uAPI for flags straight away. (Chris Wilson)
v23:
* Rebase for RUNTIME_INFO.
v24:
* Added some headline docs for the uapi usage. (Joonas/Chris)
v25:
* Renamed class/instance to engine_class/engine_instance to avoid clash
with C++ keyword. (Tony Ye)
v26:
* Rebased for runtime pm api changes.
v27:
* Rebased for intel_context_init.
* Wrap commit msg to 75.
v28:
(Chris Wilson)
* Use i915_gem_ggtt.
* Use i915_request_await_dma_fence to show a better example.
v29:
* i915_timeline_set_barrier can now fail. (Chris Wilson)
v30:
* Capture some acks.
v31:
* Drop the WARN_ON from use controllable paths. (Chris Wilson)
* Use overflows_type for all checks.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107634
Issue: https://github.com/intel/media-driver/issues/267
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Zhipeng Gong <zhipeng.gong@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tony Ye <tony.ye@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Timo Aaltonen <timo.aaltonen@canonical.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Stéphane Marchesin <marcheu@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190205095032.22673-4-tvrtko.ursulin@linux.intel.com
2019-02-05 16:50:31 +07:00
|
|
|
|
|
|
|
/*
|
2019-05-22 04:11:27 +07:00
|
|
|
* Unknown flags must be cleared to zero.
|
drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
register stored within the context image (and currently not accessible via
LRI).
If the context is adjusted before first use or whilst idle, the adjustment
is for "free"; otherwise if the context is active we queue a request to do
so (using the kernel context), following all other activity by that
context, which is also marked as barrier for all following submission
against the same context.
Since the overhead of device re-configuration during context switching can
be significant, especially in multi-context workloads, we limit this new
uAPI to only support the Gen11 VME use case. In this use case either the
device is fully enabled, and exactly one slice and half of the subslices
are enabled.
Example usage:
struct drm_i915_gem_context_param_sseu sseu = { };
struct drm_i915_gem_context_param arg = {
.param = I915_CONTEXT_PARAM_SSEU,
.ctx_id = gem_context_create(fd),
.size = sizeof(sseu),
.value = to_user_pointer(&sseu)
};
/* Query device defaults. */
gem_context_get_param(fd, &arg);
/* Set VME configuration on a 1x6x8 part. */
sseu.slice_mask = 0x1;
sseu.subslice_mask = 0xe0;
gem_context_set_param(fd, &arg);
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu()
(Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context
(Chris)
v7: Synchronize the requests following a powergating setting change using
a global dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users
(Lionel/Tvrtko)
v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Don't return EPERM when dynamic sseu is disabled (Tvrtko)
v9: Import context image into kernel context's ppgtt only when
reconfiguring powergated slice/subslices (Chris)
Use aliasing ppgtt when needed (Michel)
Tvrtko Ursulin:
v10:
* Update for upstream changes.
* Request submit needs a RPM reference.
* Reject on !FULL_PPGTT for simplicity.
* Pull out get/set param to helpers for readability and less indent.
* Use i915_request_await_dma_fence in add_global_barrier to skip waits
on the same timeline and avoid GEM_BUG_ON.
* No need to explicitly assign a NULL pointer to engine in legacy mode.
* No need to move gen8_make_rpcs up.
* Factored out global barrier as prep patch.
* Allow to only CAP_SYS_ADMIN if !Gen11.
v11:
* Remove engine vfunc in favour of local helper. (Chris Wilson)
* Stop retiring requests before updates since it is not needed
(Chris Wilson)
* Implement direct CPU update path for idle contexts. (Chris Wilson)
* Left side dependency needs only be on the same context timeline.
(Chris Wilson)
* It is sufficient to order the timeline. (Chris Wilson)
* Reject !RCS configuration attempts with -ENODEV for now.
v12:
* Rebase for make_rpcs.
v13:
* Centralize SSEU normalization to make_rpcs.
* Type width checking (uAPI <-> implementation).
* Gen11 restrictions uAPI checks.
* Gen11 subslice count differences handling.
Chris Wilson:
* args->size handling fixes.
* Update context image from GGTT.
* Postpone context image update to pinning.
* Use i915_gem_active_raw instead of last_request_on_engine.
v14:
* Add activity tracker on intel_context to fix the lifetime issues
and simplify the code. (Chris Wilson)
v15:
* Fix context pin leak if no space in ring by simplifying the
context pinning sequence.
v16:
* Rebase for context get/set param locking changes.
* Just -ENODEV on !Gen11. (Joonas)
v17:
* Fix one Gen11 subslice enablement rule.
* Handle error from i915_sw_fence_await_sw_fence_gfp. (Chris Wilson)
v18:
* Update commit message. (Joonas)
* Restrict uAPI to VME use case. (Joonas)
v19:
* Rebase.
v20:
* Rebase for ce->active_tracker.
v21:
* Rebase for IS_GEN changes.
v22:
* Reserve uAPI for flags straight away. (Chris Wilson)
v23:
* Rebase for RUNTIME_INFO.
v24:
* Added some headline docs for the uapi usage. (Joonas/Chris)
v25:
* Renamed class/instance to engine_class/engine_instance to avoid clash
with C++ keyword. (Tony Ye)
v26:
* Rebased for runtime pm api changes.
v27:
* Rebased for intel_context_init.
* Wrap commit msg to 75.
v28:
(Chris Wilson)
* Use i915_gem_ggtt.
* Use i915_request_await_dma_fence to show a better example.
v29:
* i915_timeline_set_barrier can now fail. (Chris Wilson)
v30:
* Capture some acks.
v31:
* Drop the WARN_ON from use controllable paths. (Chris Wilson)
* Use overflows_type for all checks.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107634
Issue: https://github.com/intel/media-driver/issues/267
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Zhipeng Gong <zhipeng.gong@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tony Ye <tony.ye@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Timo Aaltonen <timo.aaltonen@canonical.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Stéphane Marchesin <marcheu@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190205095032.22673-4-tvrtko.ursulin@linux.intel.com
2019-02-05 16:50:31 +07:00
|
|
|
*/
|
|
|
|
__u32 flags;
|
2019-05-22 04:11:27 +07:00
|
|
|
#define I915_CONTEXT_SSEU_FLAG_ENGINE_INDEX (1u << 0)
|
drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
register stored within the context image (and currently not accessible via
LRI).
If the context is adjusted before first use or whilst idle, the adjustment
is for "free"; otherwise if the context is active we queue a request to do
so (using the kernel context), following all other activity by that
context, which is also marked as barrier for all following submission
against the same context.
Since the overhead of device re-configuration during context switching can
be significant, especially in multi-context workloads, we limit this new
uAPI to only support the Gen11 VME use case. In this use case either the
device is fully enabled, and exactly one slice and half of the subslices
are enabled.
Example usage:
struct drm_i915_gem_context_param_sseu sseu = { };
struct drm_i915_gem_context_param arg = {
.param = I915_CONTEXT_PARAM_SSEU,
.ctx_id = gem_context_create(fd),
.size = sizeof(sseu),
.value = to_user_pointer(&sseu)
};
/* Query device defaults. */
gem_context_get_param(fd, &arg);
/* Set VME configuration on a 1x6x8 part. */
sseu.slice_mask = 0x1;
sseu.subslice_mask = 0xe0;
gem_context_set_param(fd, &arg);
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu()
(Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context
(Chris)
v7: Synchronize the requests following a powergating setting change using
a global dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users
(Lionel/Tvrtko)
v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Don't return EPERM when dynamic sseu is disabled (Tvrtko)
v9: Import context image into kernel context's ppgtt only when
reconfiguring powergated slice/subslices (Chris)
Use aliasing ppgtt when needed (Michel)
Tvrtko Ursulin:
v10:
* Update for upstream changes.
* Request submit needs a RPM reference.
* Reject on !FULL_PPGTT for simplicity.
* Pull out get/set param to helpers for readability and less indent.
* Use i915_request_await_dma_fence in add_global_barrier to skip waits
on the same timeline and avoid GEM_BUG_ON.
* No need to explicitly assign a NULL pointer to engine in legacy mode.
* No need to move gen8_make_rpcs up.
* Factored out global barrier as prep patch.
* Allow to only CAP_SYS_ADMIN if !Gen11.
v11:
* Remove engine vfunc in favour of local helper. (Chris Wilson)
* Stop retiring requests before updates since it is not needed
(Chris Wilson)
* Implement direct CPU update path for idle contexts. (Chris Wilson)
* Left side dependency needs only be on the same context timeline.
(Chris Wilson)
* It is sufficient to order the timeline. (Chris Wilson)
* Reject !RCS configuration attempts with -ENODEV for now.
v12:
* Rebase for make_rpcs.
v13:
* Centralize SSEU normalization to make_rpcs.
* Type width checking (uAPI <-> implementation).
* Gen11 restrictions uAPI checks.
* Gen11 subslice count differences handling.
Chris Wilson:
* args->size handling fixes.
* Update context image from GGTT.
* Postpone context image update to pinning.
* Use i915_gem_active_raw instead of last_request_on_engine.
v14:
* Add activity tracker on intel_context to fix the lifetime issues
and simplify the code. (Chris Wilson)
v15:
* Fix context pin leak if no space in ring by simplifying the
context pinning sequence.
v16:
* Rebase for context get/set param locking changes.
* Just -ENODEV on !Gen11. (Joonas)
v17:
* Fix one Gen11 subslice enablement rule.
* Handle error from i915_sw_fence_await_sw_fence_gfp. (Chris Wilson)
v18:
* Update commit message. (Joonas)
* Restrict uAPI to VME use case. (Joonas)
v19:
* Rebase.
v20:
* Rebase for ce->active_tracker.
v21:
* Rebase for IS_GEN changes.
v22:
* Reserve uAPI for flags straight away. (Chris Wilson)
v23:
* Rebase for RUNTIME_INFO.
v24:
* Added some headline docs for the uapi usage. (Joonas/Chris)
v25:
* Renamed class/instance to engine_class/engine_instance to avoid clash
with C++ keyword. (Tony Ye)
v26:
* Rebased for runtime pm api changes.
v27:
* Rebased for intel_context_init.
* Wrap commit msg to 75.
v28:
(Chris Wilson)
* Use i915_gem_ggtt.
* Use i915_request_await_dma_fence to show a better example.
v29:
* i915_timeline_set_barrier can now fail. (Chris Wilson)
v30:
* Capture some acks.
v31:
* Drop the WARN_ON from use controllable paths. (Chris Wilson)
* Use overflows_type for all checks.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107634
Issue: https://github.com/intel/media-driver/issues/267
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Zhipeng Gong <zhipeng.gong@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tony Ye <tony.ye@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Timo Aaltonen <timo.aaltonen@canonical.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Stéphane Marchesin <marcheu@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190205095032.22673-4-tvrtko.ursulin@linux.intel.com
2019-02-05 16:50:31 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Mask of slices to enable for the context. Valid values are a subset
|
|
|
|
* of the bitmask value returned for I915_PARAM_SLICE_MASK.
|
|
|
|
*/
|
|
|
|
__u64 slice_mask;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Mask of subslices to enable for the context. Valid values are a
|
|
|
|
* subset of the bitmask value return by I915_PARAM_SUBSLICE_MASK.
|
|
|
|
*/
|
|
|
|
__u64 subslice_mask;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Minimum/Maximum number of EUs to enable per subslice for the
|
|
|
|
* context. min_eus_per_subslice must be inferior or equal to
|
|
|
|
* max_eus_per_subslice.
|
|
|
|
*/
|
|
|
|
__u16 min_eus_per_subslice;
|
|
|
|
__u16 max_eus_per_subslice;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Unused for now. Must be cleared to zero.
|
|
|
|
*/
|
|
|
|
__u32 rsvd;
|
|
|
|
};
|
|
|
|
|
drm/i915: Load balancing across a virtual engine
Having allowed the user to define a set of engines that they will want
to only use, we go one step further and allow them to bind those engines
into a single virtual instance. Submitting a batch to the virtual engine
will then forward it to any one of the set in a manner as best to
distribute load. The virtual engine has a single timeline across all
engines (it operates as a single queue), so it is not able to concurrently
run batches across multiple engines by itself; that is left up to the user
to submit multiple concurrent batches to multiple queues. Multiple users
will be load balanced across the system.
The mechanism used for load balancing in this patch is a late greedy
balancer. When a request is ready for execution, it is added to each
engine's queue, and when an engine is ready for its next request it
claims it from the virtual engine. The first engine to do so, wins, i.e.
the request is executed at the earliest opportunity (idle moment) in the
system.
As not all HW is created equal, the user is still able to skip the
virtual engine and execute the batch on a specific engine, all within the
same queue. It will then be executed in order on the correct engine,
with execution on other virtual engines being moved away due to the load
detection.
A couple of areas for potential improvement left!
- The virtual engine always take priority over equal-priority tasks.
Mostly broken up by applying FQ_CODEL rules for prioritising new clients,
and hopefully the virtual and real engines are not then congested (i.e.
all work is via virtual engines, or all work is to the real engine).
- We require the breadcrumb irq around every virtual engine request. For
normal engines, we eliminate the need for the slow round trip via
interrupt by using the submit fence and queueing in order. For virtual
engines, we have to allow any job to transfer to a new ring, and cannot
coalesce the submissions, so require the completion fence instead,
forcing the persistent use of interrupts.
- We only drip feed single requests through each virtual engine and onto
the physical engines, even if there was enough work to fill all ELSP,
leaving small stalls with an idle CS event at the end of every request.
Could we be greedy and fill both slots? Being lazy is virtuous for load
distribution on less-than-full workloads though.
Other areas of improvement are more general, such as reducing lock
contention, reducing dispatch overhead, looking at direct submission
rather than bouncing around tasklets etc.
sseu: Lift the restriction to allow sseu to be reconfigured on virtual
engines composed of RENDER_CLASS (rcs).
v2: macroize check_user_mbz()
v3: Cancel virtual engines on wedging
v4: Commence commenting
v5: Replace 64b sibling_mask with a list of class:instance
v6: Drop the one-element array in the uabi
v7: Assert it is an virtual engine in to_virtual_engine()
v8: Skip over holes in [class][inst] so we can selftest with (vcs0, vcs2)
Link: https://github.com/intel/media-driver/pull/283
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190521211134.16117-6-chris@chris-wilson.co.uk
2019-05-22 04:11:30 +07:00
|
|
|
/*
|
|
|
|
* 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 {
|
|
|
|
struct i915_user_extension base;
|
|
|
|
|
|
|
|
__u16 engine_index;
|
|
|
|
__u16 num_siblings;
|
|
|
|
__u32 flags; /* all undefined flags must be zero */
|
|
|
|
|
|
|
|
__u64 mbz64; /* reserved for future use; must be zero */
|
|
|
|
|
|
|
|
struct i915_engine_class_instance engines[0];
|
|
|
|
} __attribute__((packed));
|
|
|
|
|
|
|
|
#define I915_DEFINE_CONTEXT_ENGINES_LOAD_BALANCE(name__, N__) struct { \
|
|
|
|
struct i915_user_extension base; \
|
|
|
|
__u16 engine_index; \
|
|
|
|
__u16 num_siblings; \
|
|
|
|
__u32 flags; \
|
|
|
|
__u64 mbz64; \
|
|
|
|
struct i915_engine_class_instance engines[N__]; \
|
|
|
|
} __attribute__((packed)) name__
|
|
|
|
|
2019-05-22 04:11:33 +07:00
|
|
|
/*
|
|
|
|
* 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 {
|
|
|
|
struct i915_user_extension base;
|
|
|
|
|
|
|
|
struct i915_engine_class_instance master;
|
|
|
|
|
|
|
|
__u16 virtual_index; /* index of virtual engine in ctx->engines[] */
|
|
|
|
__u16 num_bonds;
|
|
|
|
|
|
|
|
__u64 flags; /* all undefined flags must be zero */
|
|
|
|
__u64 mbz64[4]; /* reserved for future use; must be zero */
|
|
|
|
|
|
|
|
struct i915_engine_class_instance engines[0];
|
|
|
|
} __attribute__((packed));
|
|
|
|
|
|
|
|
#define I915_DEFINE_CONTEXT_ENGINES_BOND(name__, N__) struct { \
|
|
|
|
struct i915_user_extension base; \
|
|
|
|
struct i915_engine_class_instance master; \
|
|
|
|
__u16 virtual_index; \
|
|
|
|
__u16 num_bonds; \
|
|
|
|
__u64 flags; \
|
|
|
|
__u64 mbz64[4]; \
|
|
|
|
struct i915_engine_class_instance engines[N__]; \
|
|
|
|
} __attribute__((packed)) name__
|
|
|
|
|
drm/i915: Allow a context to define its set of engines
Over the last few years, we have debated how to extend the user API to
support an increase in the number of engines, that may be sparse and
even be heterogeneous within a class (not all video decoders created
equal). We settled on using (class, instance) tuples to identify a
specific engine, with an API for the user to construct a map of engines
to capabilities. Into this picture, we then add a challenge of virtual
engines; one user engine that maps behind the scenes to any number of
physical engines. To keep it general, we want the user to have full
control over that mapping. To that end, we allow the user to constrain a
context to define the set of engines that it can access, order fully
controlled by the user via (class, instance). With such precise control
in context setup, we can continue to use the existing execbuf uABI of
specifying a single index; only now it doesn't automagically map onto
the engines, it uses the user defined engine map from the context.
v2: Fixup freeing of local on success of get_engines()
v3: Allow empty engines[]
v4: s/nengine/num_engines/
v5: Replace 64 limit on num_engines with a note that execbuf is
currently limited to only using the first 64 engines.
v6: Actually use the engines_mutex to guard the ctx->engines.
Testcase: igt/gem_ctx_engines
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190521211134.16117-2-chris@chris-wilson.co.uk
2019-05-22 04:11:26 +07:00
|
|
|
struct i915_context_param_engines {
|
|
|
|
__u64 extensions; /* linked chain of extension blocks, 0 terminates */
|
drm/i915: Load balancing across a virtual engine
Having allowed the user to define a set of engines that they will want
to only use, we go one step further and allow them to bind those engines
into a single virtual instance. Submitting a batch to the virtual engine
will then forward it to any one of the set in a manner as best to
distribute load. The virtual engine has a single timeline across all
engines (it operates as a single queue), so it is not able to concurrently
run batches across multiple engines by itself; that is left up to the user
to submit multiple concurrent batches to multiple queues. Multiple users
will be load balanced across the system.
The mechanism used for load balancing in this patch is a late greedy
balancer. When a request is ready for execution, it is added to each
engine's queue, and when an engine is ready for its next request it
claims it from the virtual engine. The first engine to do so, wins, i.e.
the request is executed at the earliest opportunity (idle moment) in the
system.
As not all HW is created equal, the user is still able to skip the
virtual engine and execute the batch on a specific engine, all within the
same queue. It will then be executed in order on the correct engine,
with execution on other virtual engines being moved away due to the load
detection.
A couple of areas for potential improvement left!
- The virtual engine always take priority over equal-priority tasks.
Mostly broken up by applying FQ_CODEL rules for prioritising new clients,
and hopefully the virtual and real engines are not then congested (i.e.
all work is via virtual engines, or all work is to the real engine).
- We require the breadcrumb irq around every virtual engine request. For
normal engines, we eliminate the need for the slow round trip via
interrupt by using the submit fence and queueing in order. For virtual
engines, we have to allow any job to transfer to a new ring, and cannot
coalesce the submissions, so require the completion fence instead,
forcing the persistent use of interrupts.
- We only drip feed single requests through each virtual engine and onto
the physical engines, even if there was enough work to fill all ELSP,
leaving small stalls with an idle CS event at the end of every request.
Could we be greedy and fill both slots? Being lazy is virtuous for load
distribution on less-than-full workloads though.
Other areas of improvement are more general, such as reducing lock
contention, reducing dispatch overhead, looking at direct submission
rather than bouncing around tasklets etc.
sseu: Lift the restriction to allow sseu to be reconfigured on virtual
engines composed of RENDER_CLASS (rcs).
v2: macroize check_user_mbz()
v3: Cancel virtual engines on wedging
v4: Commence commenting
v5: Replace 64b sibling_mask with a list of class:instance
v6: Drop the one-element array in the uabi
v7: Assert it is an virtual engine in to_virtual_engine()
v8: Skip over holes in [class][inst] so we can selftest with (vcs0, vcs2)
Link: https://github.com/intel/media-driver/pull/283
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190521211134.16117-6-chris@chris-wilson.co.uk
2019-05-22 04:11:30 +07:00
|
|
|
#define I915_CONTEXT_ENGINES_EXT_LOAD_BALANCE 0 /* see i915_context_engines_load_balance */
|
2019-05-22 04:11:33 +07:00
|
|
|
#define I915_CONTEXT_ENGINES_EXT_BOND 1 /* see i915_context_engines_bond */
|
drm/i915: Allow a context to define its set of engines
Over the last few years, we have debated how to extend the user API to
support an increase in the number of engines, that may be sparse and
even be heterogeneous within a class (not all video decoders created
equal). We settled on using (class, instance) tuples to identify a
specific engine, with an API for the user to construct a map of engines
to capabilities. Into this picture, we then add a challenge of virtual
engines; one user engine that maps behind the scenes to any number of
physical engines. To keep it general, we want the user to have full
control over that mapping. To that end, we allow the user to constrain a
context to define the set of engines that it can access, order fully
controlled by the user via (class, instance). With such precise control
in context setup, we can continue to use the existing execbuf uABI of
specifying a single index; only now it doesn't automagically map onto
the engines, it uses the user defined engine map from the context.
v2: Fixup freeing of local on success of get_engines()
v3: Allow empty engines[]
v4: s/nengine/num_engines/
v5: Replace 64 limit on num_engines with a note that execbuf is
currently limited to only using the first 64 engines.
v6: Actually use the engines_mutex to guard the ctx->engines.
Testcase: igt/gem_ctx_engines
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190521211134.16117-2-chris@chris-wilson.co.uk
2019-05-22 04:11:26 +07:00
|
|
|
struct i915_engine_class_instance engines[0];
|
|
|
|
} __attribute__((packed));
|
|
|
|
|
|
|
|
#define I915_DEFINE_CONTEXT_PARAM_ENGINES(name__, N__) struct { \
|
|
|
|
__u64 extensions; \
|
|
|
|
struct i915_engine_class_instance engines[N__]; \
|
|
|
|
} __attribute__((packed)) name__
|
|
|
|
|
2019-03-22 16:23:24 +07:00
|
|
|
struct drm_i915_gem_context_create_ext_setparam {
|
|
|
|
#define I915_CONTEXT_CREATE_EXT_SETPARAM 0
|
|
|
|
struct i915_user_extension base;
|
|
|
|
struct drm_i915_gem_context_param param;
|
|
|
|
};
|
|
|
|
|
2019-05-22 04:11:29 +07:00
|
|
|
struct drm_i915_gem_context_create_ext_clone {
|
|
|
|
#define I915_CONTEXT_CREATE_EXT_CLONE 1
|
|
|
|
struct i915_user_extension base;
|
|
|
|
__u32 clone_id;
|
|
|
|
__u32 flags;
|
|
|
|
#define I915_CONTEXT_CLONE_ENGINES (1u << 0)
|
|
|
|
#define I915_CONTEXT_CLONE_FLAGS (1u << 1)
|
|
|
|
#define I915_CONTEXT_CLONE_SCHEDATTR (1u << 2)
|
|
|
|
#define I915_CONTEXT_CLONE_SSEU (1u << 3)
|
|
|
|
#define I915_CONTEXT_CLONE_TIMELINE (1u << 4)
|
|
|
|
#define I915_CONTEXT_CLONE_VM (1u << 5)
|
|
|
|
#define I915_CONTEXT_CLONE_UNKNOWN -(I915_CONTEXT_CLONE_VM << 1)
|
|
|
|
__u64 rsvd;
|
|
|
|
};
|
|
|
|
|
2019-03-22 16:23:24 +07:00
|
|
|
struct drm_i915_gem_context_destroy {
|
|
|
|
__u32 ctx_id;
|
|
|
|
__u32 pad;
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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.
|
|
|
|
*
|
|
|
|
* No flags are defined, with all bits reserved and must be zero.
|
|
|
|
*
|
|
|
|
* 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 @id.
|
|
|
|
*
|
|
|
|
* No extensions or flags are allowed currently, and so must be zero.
|
|
|
|
*/
|
|
|
|
struct drm_i915_gem_vm_control {
|
|
|
|
__u64 extensions;
|
|
|
|
__u32 flags;
|
|
|
|
__u32 vm_id;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct drm_i915_reg_read {
|
|
|
|
/*
|
|
|
|
* Register offset.
|
|
|
|
* For 64bit wide registers where the upper 32bits don't immediately
|
|
|
|
* follow the lower 32bits, the offset of the lower 32bits must
|
|
|
|
* be specified
|
|
|
|
*/
|
|
|
|
__u64 offset;
|
|
|
|
#define I915_REG_READ_8B_WA (1ul << 0)
|
|
|
|
|
|
|
|
__u64 val; /* Return value */
|
|
|
|
};
|
|
|
|
|
|
|
|
/* 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 {
|
|
|
|
__u32 ctx_id;
|
|
|
|
__u32 flags;
|
|
|
|
|
|
|
|
/* All resets since boot/module reload, for all contexts */
|
|
|
|
__u32 reset_count;
|
|
|
|
|
|
|
|
/* Number of batches lost when active in GPU, for this context */
|
|
|
|
__u32 batch_active;
|
|
|
|
|
|
|
|
/* Number of batches lost pending for execution, for this context */
|
|
|
|
__u32 batch_pending;
|
|
|
|
|
|
|
|
__u32 pad;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct drm_i915_gem_userptr {
|
|
|
|
__u64 user_ptr;
|
|
|
|
__u64 user_size;
|
|
|
|
__u32 flags;
|
|
|
|
#define I915_USERPTR_READ_ONLY 0x1
|
|
|
|
#define I915_USERPTR_UNSYNCHRONIZED 0x80000000
|
|
|
|
/**
|
|
|
|
* Returned handle for the object.
|
|
|
|
*
|
|
|
|
* Object handles are nonzero.
|
|
|
|
*/
|
|
|
|
__u32 handle;
|
|
|
|
};
|
|
|
|
|
2016-11-08 02:49:52 +07:00
|
|
|
enum drm_i915_oa_format {
|
2017-06-13 18:23:03 +07:00
|
|
|
I915_OA_FORMAT_A13 = 1, /* HSW only */
|
|
|
|
I915_OA_FORMAT_A29, /* HSW only */
|
|
|
|
I915_OA_FORMAT_A13_B8_C8, /* HSW only */
|
|
|
|
I915_OA_FORMAT_B4_C8, /* HSW only */
|
|
|
|
I915_OA_FORMAT_A45_B8_C8, /* HSW only */
|
|
|
|
I915_OA_FORMAT_B4_C8_A16, /* HSW only */
|
|
|
|
I915_OA_FORMAT_C4_B8, /* HSW+ */
|
|
|
|
|
|
|
|
/* Gen8+ */
|
|
|
|
I915_OA_FORMAT_A12,
|
|
|
|
I915_OA_FORMAT_A12_B8_C8,
|
|
|
|
I915_OA_FORMAT_A32u40_A4u32_B8_C8,
|
2016-11-08 02:49:52 +07:00
|
|
|
|
|
|
|
I915_OA_FORMAT_MAX /* non-ABI */
|
|
|
|
};
|
|
|
|
|
drm/i915: Add i915 perf infrastructure
Adds base i915 perf infrastructure for Gen performance metrics.
This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
properties to configure a stream of metrics and returns a new fd usable
with standard VFS system calls including read() to read typed and sized
records; ioctl() to enable or disable capture and poll() to wait for
data.
A stream is opened something like:
uint64_t properties[] = {
/* Single context sampling */
DRM_I915_PERF_PROP_CTX_HANDLE, ctx_handle,
/* Include OA reports in samples */
DRM_I915_PERF_PROP_SAMPLE_OA, true,
/* OA unit configuration */
DRM_I915_PERF_PROP_OA_METRICS_SET, metrics_set_id,
DRM_I915_PERF_PROP_OA_FORMAT, report_format,
DRM_I915_PERF_PROP_OA_EXPONENT, period_exponent,
};
struct drm_i915_perf_open_param parm = {
.flags = I915_PERF_FLAG_FD_CLOEXEC |
I915_PERF_FLAG_FD_NONBLOCK |
I915_PERF_FLAG_DISABLED,
.properties_ptr = (uint64_t)properties,
.num_properties = sizeof(properties) / 16,
};
int fd = drmIoctl(drm_fd, DRM_IOCTL_I915_PERF_OPEN, ¶m);
Records read all start with a common { type, size } header with
DRM_I915_PERF_RECORD_SAMPLE being of most interest. Sample records
contain an extensible number of fields and it's the
DRM_I915_PERF_PROP_SAMPLE_xyz properties given when opening that
determine what's included in every sample.
No specific streams are supported yet so any attempt to open a stream
will return an error.
v2:
use i915_gem_context_get() - Chris Wilson
v3:
update read() interface to avoid passing state struct - Chris Wilson
fix some rebase fallout, with i915-perf init/deinit
v4:
s/DRM_IORW/DRM_IOW/ - Emil Velikov
Signed-off-by: Robert Bragg <robert@sixbynine.org>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Sourab Gupta <sourab.gupta@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161107194957.3385-2-robert@sixbynine.org
2016-11-08 02:49:47 +07:00
|
|
|
enum drm_i915_perf_property_id {
|
|
|
|
/**
|
|
|
|
* Open the stream for a specific context handle (as used with
|
|
|
|
* execbuffer2). A stream opened for a specific context this way
|
|
|
|
* won't typically require root privileges.
|
|
|
|
*/
|
|
|
|
DRM_I915_PERF_PROP_CTX_HANDLE = 1,
|
|
|
|
|
2016-11-08 02:49:52 +07:00
|
|
|
/**
|
|
|
|
* A value of 1 requests the inclusion of raw OA unit reports as
|
|
|
|
* part of stream samples.
|
|
|
|
*/
|
|
|
|
DRM_I915_PERF_PROP_SAMPLE_OA,
|
|
|
|
|
|
|
|
/**
|
|
|
|
* The value specifies which set of OA unit metrics should be
|
|
|
|
* be configured, defining the contents of any OA unit reports.
|
|
|
|
*/
|
|
|
|
DRM_I915_PERF_PROP_OA_METRICS_SET,
|
|
|
|
|
|
|
|
/**
|
|
|
|
* The value specifies the size and layout of OA unit reports.
|
|
|
|
*/
|
|
|
|
DRM_I915_PERF_PROP_OA_FORMAT,
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Specifying this property implicitly requests periodic OA unit
|
|
|
|
* sampling and (at least on Haswell) the sampling frequency is derived
|
|
|
|
* from this exponent as follows:
|
|
|
|
*
|
|
|
|
* 80ns * 2^(period_exponent + 1)
|
|
|
|
*/
|
|
|
|
DRM_I915_PERF_PROP_OA_EXPONENT,
|
|
|
|
|
drm/i915: Add i915 perf infrastructure
Adds base i915 perf infrastructure for Gen performance metrics.
This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
properties to configure a stream of metrics and returns a new fd usable
with standard VFS system calls including read() to read typed and sized
records; ioctl() to enable or disable capture and poll() to wait for
data.
A stream is opened something like:
uint64_t properties[] = {
/* Single context sampling */
DRM_I915_PERF_PROP_CTX_HANDLE, ctx_handle,
/* Include OA reports in samples */
DRM_I915_PERF_PROP_SAMPLE_OA, true,
/* OA unit configuration */
DRM_I915_PERF_PROP_OA_METRICS_SET, metrics_set_id,
DRM_I915_PERF_PROP_OA_FORMAT, report_format,
DRM_I915_PERF_PROP_OA_EXPONENT, period_exponent,
};
struct drm_i915_perf_open_param parm = {
.flags = I915_PERF_FLAG_FD_CLOEXEC |
I915_PERF_FLAG_FD_NONBLOCK |
I915_PERF_FLAG_DISABLED,
.properties_ptr = (uint64_t)properties,
.num_properties = sizeof(properties) / 16,
};
int fd = drmIoctl(drm_fd, DRM_IOCTL_I915_PERF_OPEN, ¶m);
Records read all start with a common { type, size } header with
DRM_I915_PERF_RECORD_SAMPLE being of most interest. Sample records
contain an extensible number of fields and it's the
DRM_I915_PERF_PROP_SAMPLE_xyz properties given when opening that
determine what's included in every sample.
No specific streams are supported yet so any attempt to open a stream
will return an error.
v2:
use i915_gem_context_get() - Chris Wilson
v3:
update read() interface to avoid passing state struct - Chris Wilson
fix some rebase fallout, with i915-perf init/deinit
v4:
s/DRM_IORW/DRM_IOW/ - Emil Velikov
Signed-off-by: Robert Bragg <robert@sixbynine.org>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Sourab Gupta <sourab.gupta@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161107194957.3385-2-robert@sixbynine.org
2016-11-08 02:49:47 +07:00
|
|
|
DRM_I915_PERF_PROP_MAX /* non-ABI */
|
|
|
|
};
|
|
|
|
|
|
|
|
struct drm_i915_perf_open_param {
|
|
|
|
__u32 flags;
|
|
|
|
#define I915_PERF_FLAG_FD_CLOEXEC (1<<0)
|
|
|
|
#define I915_PERF_FLAG_FD_NONBLOCK (1<<1)
|
|
|
|
#define I915_PERF_FLAG_DISABLED (1<<2)
|
|
|
|
|
|
|
|
/** The number of u64 (id, value) pairs */
|
|
|
|
__u32 num_properties;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Pointer to array of u64 (id, value) pairs configuring the stream
|
|
|
|
* to open.
|
|
|
|
*/
|
2016-11-30 23:46:49 +07:00
|
|
|
__u64 properties_ptr;
|
drm/i915: Add i915 perf infrastructure
Adds base i915 perf infrastructure for Gen performance metrics.
This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
properties to configure a stream of metrics and returns a new fd usable
with standard VFS system calls including read() to read typed and sized
records; ioctl() to enable or disable capture and poll() to wait for
data.
A stream is opened something like:
uint64_t properties[] = {
/* Single context sampling */
DRM_I915_PERF_PROP_CTX_HANDLE, ctx_handle,
/* Include OA reports in samples */
DRM_I915_PERF_PROP_SAMPLE_OA, true,
/* OA unit configuration */
DRM_I915_PERF_PROP_OA_METRICS_SET, metrics_set_id,
DRM_I915_PERF_PROP_OA_FORMAT, report_format,
DRM_I915_PERF_PROP_OA_EXPONENT, period_exponent,
};
struct drm_i915_perf_open_param parm = {
.flags = I915_PERF_FLAG_FD_CLOEXEC |
I915_PERF_FLAG_FD_NONBLOCK |
I915_PERF_FLAG_DISABLED,
.properties_ptr = (uint64_t)properties,
.num_properties = sizeof(properties) / 16,
};
int fd = drmIoctl(drm_fd, DRM_IOCTL_I915_PERF_OPEN, ¶m);
Records read all start with a common { type, size } header with
DRM_I915_PERF_RECORD_SAMPLE being of most interest. Sample records
contain an extensible number of fields and it's the
DRM_I915_PERF_PROP_SAMPLE_xyz properties given when opening that
determine what's included in every sample.
No specific streams are supported yet so any attempt to open a stream
will return an error.
v2:
use i915_gem_context_get() - Chris Wilson
v3:
update read() interface to avoid passing state struct - Chris Wilson
fix some rebase fallout, with i915-perf init/deinit
v4:
s/DRM_IORW/DRM_IOW/ - Emil Velikov
Signed-off-by: Robert Bragg <robert@sixbynine.org>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Sourab Gupta <sourab.gupta@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161107194957.3385-2-robert@sixbynine.org
2016-11-08 02:49:47 +07:00
|
|
|
};
|
|
|
|
|
2016-11-08 02:49:52 +07:00
|
|
|
/**
|
|
|
|
* 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.
|
|
|
|
*/
|
drm/i915: Add i915 perf infrastructure
Adds base i915 perf infrastructure for Gen performance metrics.
This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
properties to configure a stream of metrics and returns a new fd usable
with standard VFS system calls including read() to read typed and sized
records; ioctl() to enable or disable capture and poll() to wait for
data.
A stream is opened something like:
uint64_t properties[] = {
/* Single context sampling */
DRM_I915_PERF_PROP_CTX_HANDLE, ctx_handle,
/* Include OA reports in samples */
DRM_I915_PERF_PROP_SAMPLE_OA, true,
/* OA unit configuration */
DRM_I915_PERF_PROP_OA_METRICS_SET, metrics_set_id,
DRM_I915_PERF_PROP_OA_FORMAT, report_format,
DRM_I915_PERF_PROP_OA_EXPONENT, period_exponent,
};
struct drm_i915_perf_open_param parm = {
.flags = I915_PERF_FLAG_FD_CLOEXEC |
I915_PERF_FLAG_FD_NONBLOCK |
I915_PERF_FLAG_DISABLED,
.properties_ptr = (uint64_t)properties,
.num_properties = sizeof(properties) / 16,
};
int fd = drmIoctl(drm_fd, DRM_IOCTL_I915_PERF_OPEN, ¶m);
Records read all start with a common { type, size } header with
DRM_I915_PERF_RECORD_SAMPLE being of most interest. Sample records
contain an extensible number of fields and it's the
DRM_I915_PERF_PROP_SAMPLE_xyz properties given when opening that
determine what's included in every sample.
No specific streams are supported yet so any attempt to open a stream
will return an error.
v2:
use i915_gem_context_get() - Chris Wilson
v3:
update read() interface to avoid passing state struct - Chris Wilson
fix some rebase fallout, with i915-perf init/deinit
v4:
s/DRM_IORW/DRM_IOW/ - Emil Velikov
Signed-off-by: Robert Bragg <robert@sixbynine.org>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Sourab Gupta <sourab.gupta@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161107194957.3385-2-robert@sixbynine.org
2016-11-08 02:49:47 +07:00
|
|
|
#define I915_PERF_IOCTL_ENABLE _IO('i', 0x0)
|
2016-11-08 02:49:52 +07:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Disable data capture for a stream.
|
|
|
|
*
|
|
|
|
* It is an error to try and read a stream that is disabled.
|
|
|
|
*/
|
drm/i915: Add i915 perf infrastructure
Adds base i915 perf infrastructure for Gen performance metrics.
This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
properties to configure a stream of metrics and returns a new fd usable
with standard VFS system calls including read() to read typed and sized
records; ioctl() to enable or disable capture and poll() to wait for
data.
A stream is opened something like:
uint64_t properties[] = {
/* Single context sampling */
DRM_I915_PERF_PROP_CTX_HANDLE, ctx_handle,
/* Include OA reports in samples */
DRM_I915_PERF_PROP_SAMPLE_OA, true,
/* OA unit configuration */
DRM_I915_PERF_PROP_OA_METRICS_SET, metrics_set_id,
DRM_I915_PERF_PROP_OA_FORMAT, report_format,
DRM_I915_PERF_PROP_OA_EXPONENT, period_exponent,
};
struct drm_i915_perf_open_param parm = {
.flags = I915_PERF_FLAG_FD_CLOEXEC |
I915_PERF_FLAG_FD_NONBLOCK |
I915_PERF_FLAG_DISABLED,
.properties_ptr = (uint64_t)properties,
.num_properties = sizeof(properties) / 16,
};
int fd = drmIoctl(drm_fd, DRM_IOCTL_I915_PERF_OPEN, ¶m);
Records read all start with a common { type, size } header with
DRM_I915_PERF_RECORD_SAMPLE being of most interest. Sample records
contain an extensible number of fields and it's the
DRM_I915_PERF_PROP_SAMPLE_xyz properties given when opening that
determine what's included in every sample.
No specific streams are supported yet so any attempt to open a stream
will return an error.
v2:
use i915_gem_context_get() - Chris Wilson
v3:
update read() interface to avoid passing state struct - Chris Wilson
fix some rebase fallout, with i915-perf init/deinit
v4:
s/DRM_IORW/DRM_IOW/ - Emil Velikov
Signed-off-by: Robert Bragg <robert@sixbynine.org>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Sourab Gupta <sourab.gupta@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161107194957.3385-2-robert@sixbynine.org
2016-11-08 02:49:47 +07:00
|
|
|
#define I915_PERF_IOCTL_DISABLE _IO('i', 0x1)
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Common to all i915 perf records
|
|
|
|
*/
|
|
|
|
struct drm_i915_perf_record_header {
|
|
|
|
__u32 type;
|
|
|
|
__u16 pad;
|
|
|
|
__u16 size;
|
|
|
|
};
|
|
|
|
|
|
|
|
enum drm_i915_perf_record_type {
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Samples are the work horse record type whose contents are extensible
|
|
|
|
* and defined when opening an i915 perf stream based on the given
|
|
|
|
* properties.
|
|
|
|
*
|
|
|
|
* Boolean properties following the naming convention
|
|
|
|
* DRM_I915_PERF_SAMPLE_xyz_PROP request the inclusion of 'xyz' data in
|
|
|
|
* every sample.
|
|
|
|
*
|
|
|
|
* The order of these sample properties given by userspace has no
|
2016-11-08 02:49:52 +07:00
|
|
|
* affect on the ordering of data within a sample. The order is
|
drm/i915: Add i915 perf infrastructure
Adds base i915 perf infrastructure for Gen performance metrics.
This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
properties to configure a stream of metrics and returns a new fd usable
with standard VFS system calls including read() to read typed and sized
records; ioctl() to enable or disable capture and poll() to wait for
data.
A stream is opened something like:
uint64_t properties[] = {
/* Single context sampling */
DRM_I915_PERF_PROP_CTX_HANDLE, ctx_handle,
/* Include OA reports in samples */
DRM_I915_PERF_PROP_SAMPLE_OA, true,
/* OA unit configuration */
DRM_I915_PERF_PROP_OA_METRICS_SET, metrics_set_id,
DRM_I915_PERF_PROP_OA_FORMAT, report_format,
DRM_I915_PERF_PROP_OA_EXPONENT, period_exponent,
};
struct drm_i915_perf_open_param parm = {
.flags = I915_PERF_FLAG_FD_CLOEXEC |
I915_PERF_FLAG_FD_NONBLOCK |
I915_PERF_FLAG_DISABLED,
.properties_ptr = (uint64_t)properties,
.num_properties = sizeof(properties) / 16,
};
int fd = drmIoctl(drm_fd, DRM_IOCTL_I915_PERF_OPEN, ¶m);
Records read all start with a common { type, size } header with
DRM_I915_PERF_RECORD_SAMPLE being of most interest. Sample records
contain an extensible number of fields and it's the
DRM_I915_PERF_PROP_SAMPLE_xyz properties given when opening that
determine what's included in every sample.
No specific streams are supported yet so any attempt to open a stream
will return an error.
v2:
use i915_gem_context_get() - Chris Wilson
v3:
update read() interface to avoid passing state struct - Chris Wilson
fix some rebase fallout, with i915-perf init/deinit
v4:
s/DRM_IORW/DRM_IOW/ - Emil Velikov
Signed-off-by: Robert Bragg <robert@sixbynine.org>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Sourab Gupta <sourab.gupta@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161107194957.3385-2-robert@sixbynine.org
2016-11-08 02:49:47 +07:00
|
|
|
* documented here.
|
|
|
|
*
|
|
|
|
* struct {
|
|
|
|
* struct drm_i915_perf_record_header header;
|
|
|
|
*
|
2016-11-08 02:49:52 +07:00
|
|
|
* { u32 oa_report[]; } && DRM_I915_PERF_PROP_SAMPLE_OA
|
drm/i915: Add i915 perf infrastructure
Adds base i915 perf infrastructure for Gen performance metrics.
This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
properties to configure a stream of metrics and returns a new fd usable
with standard VFS system calls including read() to read typed and sized
records; ioctl() to enable or disable capture and poll() to wait for
data.
A stream is opened something like:
uint64_t properties[] = {
/* Single context sampling */
DRM_I915_PERF_PROP_CTX_HANDLE, ctx_handle,
/* Include OA reports in samples */
DRM_I915_PERF_PROP_SAMPLE_OA, true,
/* OA unit configuration */
DRM_I915_PERF_PROP_OA_METRICS_SET, metrics_set_id,
DRM_I915_PERF_PROP_OA_FORMAT, report_format,
DRM_I915_PERF_PROP_OA_EXPONENT, period_exponent,
};
struct drm_i915_perf_open_param parm = {
.flags = I915_PERF_FLAG_FD_CLOEXEC |
I915_PERF_FLAG_FD_NONBLOCK |
I915_PERF_FLAG_DISABLED,
.properties_ptr = (uint64_t)properties,
.num_properties = sizeof(properties) / 16,
};
int fd = drmIoctl(drm_fd, DRM_IOCTL_I915_PERF_OPEN, ¶m);
Records read all start with a common { type, size } header with
DRM_I915_PERF_RECORD_SAMPLE being of most interest. Sample records
contain an extensible number of fields and it's the
DRM_I915_PERF_PROP_SAMPLE_xyz properties given when opening that
determine what's included in every sample.
No specific streams are supported yet so any attempt to open a stream
will return an error.
v2:
use i915_gem_context_get() - Chris Wilson
v3:
update read() interface to avoid passing state struct - Chris Wilson
fix some rebase fallout, with i915-perf init/deinit
v4:
s/DRM_IORW/DRM_IOW/ - Emil Velikov
Signed-off-by: Robert Bragg <robert@sixbynine.org>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Sourab Gupta <sourab.gupta@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161107194957.3385-2-robert@sixbynine.org
2016-11-08 02:49:47 +07:00
|
|
|
* };
|
|
|
|
*/
|
|
|
|
DRM_I915_PERF_RECORD_SAMPLE = 1,
|
|
|
|
|
2016-11-08 02:49:52 +07:00
|
|
|
/*
|
|
|
|
* Indicates that one or more OA reports were not written by the
|
|
|
|
* hardware. This can happen for example if an MI_REPORT_PERF_COUNT
|
|
|
|
* command collides with periodic sampling - which would be more likely
|
|
|
|
* at higher sampling frequencies.
|
|
|
|
*/
|
|
|
|
DRM_I915_PERF_RECORD_OA_REPORT_LOST = 2,
|
|
|
|
|
|
|
|
/**
|
|
|
|
* An error occurred that resulted in all pending OA reports being lost.
|
|
|
|
*/
|
|
|
|
DRM_I915_PERF_RECORD_OA_BUFFER_LOST = 3,
|
|
|
|
|
drm/i915: Add i915 perf infrastructure
Adds base i915 perf infrastructure for Gen performance metrics.
This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
properties to configure a stream of metrics and returns a new fd usable
with standard VFS system calls including read() to read typed and sized
records; ioctl() to enable or disable capture and poll() to wait for
data.
A stream is opened something like:
uint64_t properties[] = {
/* Single context sampling */
DRM_I915_PERF_PROP_CTX_HANDLE, ctx_handle,
/* Include OA reports in samples */
DRM_I915_PERF_PROP_SAMPLE_OA, true,
/* OA unit configuration */
DRM_I915_PERF_PROP_OA_METRICS_SET, metrics_set_id,
DRM_I915_PERF_PROP_OA_FORMAT, report_format,
DRM_I915_PERF_PROP_OA_EXPONENT, period_exponent,
};
struct drm_i915_perf_open_param parm = {
.flags = I915_PERF_FLAG_FD_CLOEXEC |
I915_PERF_FLAG_FD_NONBLOCK |
I915_PERF_FLAG_DISABLED,
.properties_ptr = (uint64_t)properties,
.num_properties = sizeof(properties) / 16,
};
int fd = drmIoctl(drm_fd, DRM_IOCTL_I915_PERF_OPEN, ¶m);
Records read all start with a common { type, size } header with
DRM_I915_PERF_RECORD_SAMPLE being of most interest. Sample records
contain an extensible number of fields and it's the
DRM_I915_PERF_PROP_SAMPLE_xyz properties given when opening that
determine what's included in every sample.
No specific streams are supported yet so any attempt to open a stream
will return an error.
v2:
use i915_gem_context_get() - Chris Wilson
v3:
update read() interface to avoid passing state struct - Chris Wilson
fix some rebase fallout, with i915-perf init/deinit
v4:
s/DRM_IORW/DRM_IOW/ - Emil Velikov
Signed-off-by: Robert Bragg <robert@sixbynine.org>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Sourab Gupta <sourab.gupta@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161107194957.3385-2-robert@sixbynine.org
2016-11-08 02:49:47 +07:00
|
|
|
DRM_I915_PERF_RECORD_MAX /* non-ABI */
|
|
|
|
};
|
|
|
|
|
2017-08-04 00:05:50 +07:00
|
|
|
/**
|
|
|
|
* Structure to upload perf dynamic configuration into the kernel.
|
|
|
|
*/
|
|
|
|
struct drm_i915_perf_oa_config {
|
|
|
|
/** String formatted like "%08x-%04x-%04x-%04x-%012x" */
|
|
|
|
char uuid[36];
|
|
|
|
|
|
|
|
__u32 n_mux_regs;
|
|
|
|
__u32 n_boolean_regs;
|
|
|
|
__u32 n_flex_regs;
|
|
|
|
|
2017-09-18 18:42:41 +07:00
|
|
|
/*
|
2018-03-06 19:28:56 +07:00
|
|
|
* These fields are pointers to tuples of u32 values (register address,
|
|
|
|
* value). For example the expected length of the buffer pointed by
|
|
|
|
* mux_regs_ptr is (2 * sizeof(u32) * n_mux_regs).
|
2017-09-18 18:42:41 +07:00
|
|
|
*/
|
2017-09-01 21:57:29 +07:00
|
|
|
__u64 mux_regs_ptr;
|
|
|
|
__u64 boolean_regs_ptr;
|
|
|
|
__u64 flex_regs_ptr;
|
2017-08-04 00:05:50 +07:00
|
|
|
};
|
|
|
|
|
2018-03-06 19:28:56 +07:00
|
|
|
struct drm_i915_query_item {
|
|
|
|
__u64 query_id;
|
2018-03-06 19:28:57 +07:00
|
|
|
#define DRM_I915_QUERY_TOPOLOGY_INFO 1
|
2019-05-22 16:00:54 +07:00
|
|
|
#define DRM_I915_QUERY_ENGINE_INFO 2
|
2019-02-18 16:46:28 +07:00
|
|
|
/* Must be kept compact -- no holes and well documented */
|
2018-03-06 19:28:56 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* When set to zero by userspace, this is filled with the size of the
|
|
|
|
* data to be written at the data_ptr pointer. The kernel sets this
|
|
|
|
* value to a negative value to signal an error on a particular query
|
|
|
|
* item.
|
|
|
|
*/
|
|
|
|
__s32 length;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Unused for now. Must be cleared to zero.
|
|
|
|
*/
|
|
|
|
__u32 flags;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Data will be written at the location pointed by data_ptr when the
|
|
|
|
* value of length matches the length of the data to be written by the
|
|
|
|
* kernel.
|
|
|
|
*/
|
|
|
|
__u64 data_ptr;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct drm_i915_query {
|
|
|
|
__u32 num_items;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Unused for now. Must be cleared to zero.
|
|
|
|
*/
|
|
|
|
__u32 flags;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This points to an array of num_items drm_i915_query_item structures.
|
|
|
|
*/
|
|
|
|
__u64 items_ptr;
|
|
|
|
};
|
|
|
|
|
2018-03-06 19:28:57 +07:00
|
|
|
/*
|
|
|
|
* Data written by the kernel with query DRM_I915_QUERY_TOPOLOGY_INFO :
|
|
|
|
*
|
|
|
|
* data: contains the 3 pieces of information :
|
|
|
|
*
|
|
|
|
* - the slice mask with one bit per slice telling whether a slice is
|
|
|
|
* available. The availability of slice X can be queried with the following
|
|
|
|
* formula :
|
|
|
|
*
|
|
|
|
* (data[X / 8] >> (X % 8)) & 1
|
|
|
|
*
|
|
|
|
* - the subslice mask for each slice with one bit per subslice telling
|
|
|
|
* whether a subslice is available. The availability of subslice Y in slice
|
|
|
|
* X can be queried with the following formula :
|
|
|
|
*
|
|
|
|
* (data[subslice_offset +
|
|
|
|
* X * subslice_stride +
|
|
|
|
* Y / 8] >> (Y % 8)) & 1
|
|
|
|
*
|
|
|
|
* - the EU mask for each subslice in each slice with one bit per EU telling
|
|
|
|
* whether an EU is available. The availability of EU Z in subslice Y in
|
|
|
|
* slice X can be queried with the following formula :
|
|
|
|
*
|
|
|
|
* (data[eu_offset +
|
|
|
|
* (X * max_subslices + Y) * eu_stride +
|
|
|
|
* Z / 8] >> (Z % 8)) & 1
|
|
|
|
*/
|
|
|
|
struct drm_i915_query_topology_info {
|
|
|
|
/*
|
|
|
|
* Unused for now. Must be cleared to zero.
|
|
|
|
*/
|
|
|
|
__u16 flags;
|
|
|
|
|
|
|
|
__u16 max_slices;
|
|
|
|
__u16 max_subslices;
|
|
|
|
__u16 max_eus_per_subslice;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Offset in data[] at which the subslice masks are stored.
|
|
|
|
*/
|
|
|
|
__u16 subslice_offset;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Stride at which each of the subslice masks for each slice are
|
|
|
|
* stored.
|
|
|
|
*/
|
|
|
|
__u16 subslice_stride;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Offset in data[] at which the EU masks are stored.
|
|
|
|
*/
|
|
|
|
__u16 eu_offset;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Stride at which each of the EU masks for each subslice are stored.
|
|
|
|
*/
|
|
|
|
__u16 eu_stride;
|
|
|
|
|
|
|
|
__u8 data[];
|
|
|
|
};
|
|
|
|
|
2019-05-22 16:00:54 +07:00
|
|
|
/**
|
|
|
|
* struct drm_i915_engine_info
|
|
|
|
*
|
|
|
|
* Describes one engine and it's capabilities as known to the driver.
|
|
|
|
*/
|
|
|
|
struct drm_i915_engine_info {
|
|
|
|
/** Engine class and instance. */
|
|
|
|
struct i915_engine_class_instance engine;
|
|
|
|
|
|
|
|
/** Reserved field. */
|
|
|
|
__u32 rsvd0;
|
|
|
|
|
|
|
|
/** Engine flags. */
|
|
|
|
__u64 flags;
|
|
|
|
|
|
|
|
/** Capabilities of this engine. */
|
|
|
|
__u64 capabilities;
|
|
|
|
#define I915_VIDEO_CLASS_CAPABILITY_HEVC (1 << 0)
|
|
|
|
#define I915_VIDEO_AND_ENHANCE_CLASS_CAPABILITY_SFC (1 << 1)
|
|
|
|
|
|
|
|
/** Reserved fields. */
|
|
|
|
__u64 rsvd1[4];
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* 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 {
|
|
|
|
/** Number of struct drm_i915_engine_info structs following. */
|
|
|
|
__u32 num_engines;
|
|
|
|
|
|
|
|
/** MBZ */
|
|
|
|
__u32 rsvd[3];
|
|
|
|
|
|
|
|
/** Marker for drm_i915_engine_info structures. */
|
|
|
|
struct drm_i915_engine_info engines[];
|
|
|
|
};
|
|
|
|
|
2016-04-08 01:00:35 +07:00
|
|
|
#if defined(__cplusplus)
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2012-10-05 00:21:50 +07:00
|
|
|
#endif /* _UAPI_I915_DRM_H_ */
|