From: Tvrtko Ursulin <tursulin@ursulin.net>
To: Intel-gfx@lists.freedesktop.org
Subject: [RFC 09/10] drm/i915: Trivial virtual engine implementation
Date: Thu, 25 Jan 2018 13:33:32 +0000 [thread overview]
Message-ID: <20180125133333.13425-10-tvrtko.ursulin@linux.intel.com> (raw)
In-Reply-To: <20180125133333.13425-1-tvrtko.ursulin@linux.intel.com>
From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Contexts marked as virtual can be load balanced between available engine
instaces. In this trivial implementation there are two important points to
kepp in mind:
1. Best engine is chosen by round-robin on every submission.
Every time context is transferred between engines an implicit
synchronization point is created, where the execution on the new engine
can only continue once the execution on the current engine has stopped
(for each context).
The round-robin on every submission is also far from ideal. If desired it
could later be improved with an engine busyness or queu-depth based
approaches which were demonstrated to work well when used for userspace
based balancing.
2. The engine is selected at the execbuf level which may be quite distant
in time from when the GPU actually becomes available to run things.
IMPORTANT CAVEAT:
This prototype implementation does not guarantee context state.
To provide context state in this prototype a much more "real" virtual
engine would have to be created which would include involved refactoring.
Userspace which uses specific engine features, not present on all engine
instances, needs to signal this fact via the engines capabilities uAPI.
i915 will then make sure only compatible engines are used for executing
the submission.
v2:
* Fix GT2 configs and no VCS engine.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 46 +++++++++++++++++++++++++++---
1 file changed, 42 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index fa1806ed9be6..f89a7be68133 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -204,6 +204,8 @@ struct i915_execbuffer {
struct drm_i915_gem_request *request; /** our request to build */
struct i915_vma *batch; /** identity of the batch obj/vma */
+ struct drm_i915_gem_request *prev_request; /** request to depend on */
+
/** actual size of execobj[] as we may extend it for the cmdparser */
unsigned int buffer_count;
@@ -2018,23 +2020,51 @@ gen8_dispatch_bsd_engine(struct drm_i915_private *dev_priv,
static int eb_select_engine_class_instance(struct i915_execbuffer *eb)
{
+ struct drm_i915_private *i915 = eb->i915;
u64 eb_flags = eb->args->flags;
u8 class = eb_flags & I915_EXEC_RING_MASK;
u8 instance = (eb_flags & I915_EXEC_INSTANCE_MASK) >>
I915_EXEC_INSTANCE_SHIFT;
u8 caps = (eb_flags & I915_EXEC_ENGINE_CAP_MASK) >>
I915_EXEC_ENGINE_CAP_SHIFT;
+ struct drm_i915_gem_request *prev_req = NULL;
struct intel_engine_cs *engine;
- if (instance && eb->ctx->virtual)
+ if (eb->ctx->virtual && instance) {
return -EINVAL;
+ } else if ((HAS_BSD(i915) && HAS_BSD2(i915)) && eb->ctx->virtual &&
+ class == I915_ENGINE_CLASS_VIDEO) {
+ unsigned int vcs_instances = 2;
+ struct intel_timeline *timeline;
- engine = intel_engine_lookup_user(eb->i915, class, instance);
+ instance = atomic_fetch_xor(1,
+ &i915->mm.bsd_engine_dispatch_index);
- if (engine && ((caps & engine->caps) != caps))
- return -EINVAL;
+ do {
+ engine = i915->engine[_VCS(instance)];
+ instance ^= 1;
+ vcs_instances--;
+ } while ((caps & engine->caps) != caps && vcs_instances > 0);
+
+ if ((caps & engine->caps) != caps)
+ return -EINVAL;
+
+ timeline = i915_gem_context_lookup_timeline_class(eb->ctx,
+ VIDEO_DECODE_CLASS);
+ spin_lock_irq(&timeline->lock);
+ prev_req = list_first_entry_or_null(&timeline->requests,
+ struct drm_i915_gem_request,
+ ctx_link);
+ spin_unlock_irq(&timeline->lock);
+ } else {
+ engine = intel_engine_lookup_user(i915, class, instance);
+
+ if (engine && ((caps & engine->caps) != caps))
+ return -EINVAL;
+ }
eb->engine = engine;
+ eb->prev_request = prev_req;
return 0;
}
@@ -2100,6 +2130,7 @@ static int eb_select_engine(struct i915_execbuffer *eb, struct drm_file *file)
}
eb->engine = engine;
+ eb->prev_request = NULL;
return 0;
}
@@ -2427,6 +2458,13 @@ i915_gem_do_execbuffer(struct drm_device *dev,
goto err_batch_unpin;
}
+ if (eb.prev_request) {
+ err = i915_gem_request_await_dma_fence(eb.request,
+ &eb.prev_request->fence);
+ if (err)
+ goto err_request;
+ }
+
if (in_fence) {
err = i915_gem_request_await_dma_fence(eb.request, in_fence);
if (err < 0)
--
2.14.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2018-01-25 13:33 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-25 13:33 [RFC 00/10] Virtual queue/engine uAPI prototype Tvrtko Ursulin
2018-01-25 13:33 ` [RFC 01/10] move-timeline-to-ctx Tvrtko Ursulin
2018-01-25 13:33 ` [RFC 02/10] drm/i915: Extend CREATE_CONTEXT to allow inheritance ala clone() Tvrtko Ursulin
2018-01-25 13:33 ` [RFC 03/10] drm/i915: Select engines via class and instance in execbuffer2 Tvrtko Ursulin
2018-01-25 13:33 ` [RFC 04/10] drm/i915: Engine capabilities uAPI Tvrtko Ursulin
2018-01-25 13:33 ` [RFC 05/10] drm/i915: Re-arrange execbuf so context is known before engine Tvrtko Ursulin
2018-01-25 13:33 ` [RFC 06/10] drm/i915: Refactor eb_select_engine to take eb Tvrtko Ursulin
2018-01-25 13:33 ` [RFC 07/10] drm/i915: Track latest request per engine class Tvrtko Ursulin
2018-01-25 13:33 ` [RFC 08/10] drm/i915: Allow creating virtual contexts Tvrtko Ursulin
2018-01-25 13:33 ` Tvrtko Ursulin [this message]
2018-01-25 13:57 ` [RFC 09/10] drm/i915: Trivial virtual engine implementation Chris Wilson
2018-01-25 14:26 ` Tvrtko Ursulin
2018-01-25 14:32 ` Chris Wilson
2018-01-25 14:36 ` Tvrtko Ursulin
2018-01-25 13:33 ` [RFC 10/10] drm/i915: Naive engine busyness based load balancing Tvrtko Ursulin
2018-01-25 14:12 ` ✗ Fi.CI.BAT: failure for Virtual queue/engine uAPI prototype Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180125133333.13425-10-tvrtko.ursulin@linux.intel.com \
--to=tursulin@ursulin.net \
--cc=Intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox