From: Matthew Brost <matthew.brost@intel.com>
To: <intel-gfx@lists.freedesktop.org>, <dri-devel@lists.freedesktop.org>
Cc: carl.zhang@intel.com, jason.ekstrand@intel.com, daniel.vetter@intel.com
Subject: [Intel-gfx] [RFC PATCH 2/5] drm/doc/rfc: i915 new parallel submission uAPI plan
Date: Thu, 6 May 2021 10:30:46 -0700 [thread overview]
Message-ID: <20210506173049.72503-3-matthew.brost@intel.com> (raw)
In-Reply-To: <20210506173049.72503-1-matthew.brost@intel.com>
Add entry fpr i915 new parallel submission uAPI plan.
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Tony Ye <tony.ye@intel.com>
CC: Carl Zhang <carl.zhang@intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
---
Documentation/gpu/rfc/i915_scheduler.rst | 56 +++++++++++++++++++++++-
1 file changed, 54 insertions(+), 2 deletions(-)
diff --git a/Documentation/gpu/rfc/i915_scheduler.rst b/Documentation/gpu/rfc/i915_scheduler.rst
index fa6780a11c86..e3455b33edfe 100644
--- a/Documentation/gpu/rfc/i915_scheduler.rst
+++ b/Documentation/gpu/rfc/i915_scheduler.rst
@@ -13,7 +13,8 @@ i915 with the DRM scheduler is:
modparam enable_guc
* Lots of rework will need to be done to integrate with DRM scheduler so
no need to nit pick everything in the code, it just should be
- functional and not regress execlists
+ functional, no major coding style / layering errors, and not regress
+ execlists
* Update IGTs / selftests as needed to work with GuC submission
* Enable CI on supported platforms for a baseline
* Rework / get CI heathly for GuC submission in place as needed
@@ -67,4 +68,55 @@ levels too.
New parallel submission uAPI
============================
-Details to come in a following patch.
+The existing bonding uAPI is completely broken with GuC submission because
+whether a submission is a single context submit or parallel submit isn't known
+until execbuf time activated via the I915_SUBMIT_FENCE. To submit multiple
+contexts in parallel with the GuC the context must be explictly registered with
+N contexts and all N contexts must be submitted in a single command to the GuC.
+This interfaces doesn't support dynamically changing between N contexts as the
+bonding uAPI does. Hence the need for a new parallel submission interface. Also
+the legacy bonding uAPI is quite confusing and not intuitive at all.
+
+The new parallel submission uAPI consists of 3 parts:
+
+* Export engines logical mapping
+* A 'set_parallel' extension to configure contexts for parallel
+ submission
+* Extend execbuf2 IOCTL to support submitting N BBs in a single IOCTL
+
+Export engines logical mapping
+------------------------------
+Certain use cases require BBs to be placed on engine instances in logical order
+(e.g. split-frame on gen11+). The logical mapping of engine instances can change
+based on fusing. Rather than making UMDs be aware of fusing, simply expose the
+logical mapping with the existing query engine info IOCTL. Also the GuC
+submission interface currently only supports submitting multiple contexts to
+engines in logical order.
+
+A single bit will be added to drm_i915_engine_info.flags indicating that the
+logical instance has been returned and a new field,
+drm_i915_engine_info.logical_instance, returns the logical instance.
+
+A 'set_parallel' extension to configure contexts for parallel submission
+------------------------------------------------------------------------
+The 'set_parallel' extension configures N contexts for parallel submission. It
+is setup step that should be called before using any of the contexts. See
+I915_CONTEXT_ENGINES_EXT_LOAD_BALANCE or I915_CONTEXT_ENGINES_EXT_BOND for
+similar existing examples. Once the N contexts are configured for parallel
+submission the execbuf2 IOCTL can be called submiting 1-N BBs in a single IOCTL.
+Although submitting less than N BBs is allowed it is not recommended as that
+will likely leave parts of the hardware reserved and idle. Initially only
+support GuC submission. Execlist support can be added later if needed.
+
+Add I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT and
+i915_context_engines_parallel_submit to the uAPI to implement this extension.
+
+Extend execbuf2 IOCTL to support submitting N BBs in a single IOCTL
+-------------------------------------------------------------------
+Contexts that have been configured with the 'set_parallel' extension are allowed
+to submit 1-N BBs in a single execbuf2 IOCTL. The BBs are either the last N
+objects in the drm_i915_gem_exec_object2 list or the first N if
+I915_EXEC_BATCH_FIRST is set.
+
+Add field 6 bit wide field to drm_i915_gem_exec_object2.flags which indicates
+the number of BBs - 1 included in the IOCTL.
--
2.28.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2021-05-06 17:13 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-06 17:30 [Intel-gfx] [RFC PATCH 0/5] GuC submission / DRM scheduler integration plan + new uAPI Matthew Brost
2021-05-06 17:27 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for " Patchwork
2021-05-06 17:30 ` [Intel-gfx] [RFC PATCH 1/5] drm/doc/rfc: i915 GuC submission / DRM scheduler integration plan Matthew Brost
2021-05-11 14:34 ` Daniel Vetter
2021-05-11 14:58 ` Daniel Stone
2021-05-11 15:12 ` Daniel Vetter
2021-05-06 17:30 ` Matthew Brost [this message]
2021-05-11 14:49 ` [Intel-gfx] [RFC PATCH 2/5] drm/doc/rfc: i915 new parallel submission uAPI plan Daniel Vetter
2021-05-11 17:51 ` Matthew Brost
2021-05-06 17:30 ` [Intel-gfx] [RFC PATCH 3/5] drm/i915: Expose logical engine instance to user Matthew Brost
2021-05-11 14:53 ` Daniel Vetter
2021-05-06 17:30 ` [Intel-gfx] [RFC PATCH 4/5] drm/i915: Introduce 'set parallel submit' extension Matthew Brost
2021-05-11 15:11 ` Daniel Vetter
2021-05-11 18:44 ` Matthew Brost
2021-05-12 8:34 ` Daniel Vetter
2021-05-14 20:05 ` Matthew Brost
2021-05-17 13:55 ` Daniel Vetter
2021-05-17 17:46 ` Matthew Brost
2021-05-06 17:30 ` [Intel-gfx] [RFC PATCH 5/5] drm/i915: Update execbuf IOCTL to accept N BBs Matthew Brost
2021-05-11 15:13 ` Daniel Vetter
2021-05-11 18:01 ` Matthew Brost
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=20210506173049.72503-3-matthew.brost@intel.com \
--to=matthew.brost@intel.com \
--cc=carl.zhang@intel.com \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jason.ekstrand@intel.com \
/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