| Message ID | 20211004220637.14746-1-matthew.brost@intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Parallel submission aka multi-bb execbuf | expand |
On 10/4/2021 15:21, Patchwork wrote: > == Series Details == > > Series: Parallel submission aka multi-bb execbuf (rev4) > URL : https://patchwork.freedesktop.org/series/92789/ > State : warning > > == Summary == > > $ dim checkpatch origin/drm-tip > e2a47a99bf9d drm/i915/guc: Move GuC guc_id allocation under submission state sub-struct > f83d8f1539fa drm/i915/guc: Take GT PM ref when deregistering context > -:79: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'gt' - possible side-effects? > #79: FILE: drivers/gpu/drm/i915/gt/intel_gt_pm.h:44: > +#define with_intel_gt_pm(gt, tmp) \ > + for (tmp = 1, intel_gt_pm_get(gt); tmp; \ > + intel_gt_pm_put(gt), tmp = 0) > > -:79: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'tmp' - possible side-effects? > #79: FILE: drivers/gpu/drm/i915/gt/intel_gt_pm.h:44: > +#define with_intel_gt_pm(gt, tmp) \ > + for (tmp = 1, intel_gt_pm_get(gt); tmp; \ > + intel_gt_pm_put(gt), tmp = 0) Not sure what these two are complaining about? But 'gt' and 'tmp' should be wrapped with parentheses when used? > > total: 0 errors, 0 warnings, 2 checks, 290 lines checked > 93e5284929b3 drm/i915/guc: Take engine PM when a context is pinned with GuC submission > 4dd6554d994d drm/i915/guc: Don't call switch_to_kernel_context with GuC submission > 8629b55f536c drm/i915: Add logical engine mapping > 8117ec0a1ca7 drm/i915: Expose logical engine instance to user > aa8e1eb4dd4e drm/i915/guc: Introduce context parent-child relationship > aaf50eacc2fd drm/i915/guc: Add multi-lrc context registration > e5f6f50e66d1 drm/i915/guc: Ensure GuC schedule operations do not operate on child contexts > adf21ba138f3 drm/i915/guc: Assign contexts in parent-child relationship consecutive guc_ids > 40ef33318b81 drm/i915/guc: Implement parallel context pin / unpin functions > 1ad560c70346 drm/i915/guc: Implement multi-lrc submission > -:364: CHECK:SPACING: spaces preferred around that '*' (ctx:ExV) > #364: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:771: > + *wqi++ = child->ring->tail / sizeof(u64); > ^ This seems like a bogus warning. > > total: 0 errors, 0 warnings, 1 checks, 570 lines checked > 466c01457dec drm/i915/guc: Insert submit fences between requests in parent-child relationship > 2ece815c1f18 drm/i915/guc: Implement multi-lrc reset > 7add5784199f drm/i915/guc: Update debugfs for GuC multi-lrc > -:23: CHECK:LINE_SPACING: Please don't use multiple blank lines > #23: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:3707: > > + This should be fixed. > > total: 0 errors, 0 warnings, 1 checks, 67 lines checked > 966991d7bbed drm/i915: Fix bug in user proto-context creation that leaked contexts > 0eb3d3bf0c84 drm/i915/guc: Connect UAPI to GuC multi-lrc interface > 68c6596b649a drm/i915/doc: Update parallel submit doc to point to i915_drm.h > -:13: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? > #13: > deleted file mode 100644 > > total: 0 errors, 1 warnings, 0 checks, 10 lines checked > 8290f5d15ca2 drm/i915/guc: Add basic GuC multi-lrc selftest > -:22: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? > #22: > new file mode 100644 These two can be ignored. > total: 0 errors, 1 warnings, 0 checks, 190 lines checked > ade3768c42d5 drm/i915/guc: Implement no mid batch preemption for multi-lrc > 57882939d788 drm/i915: Multi-BB execbuf > -:369: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_i' - possible side-effects? > #369: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1854: > +#define for_each_batch_create_order(_eb, _i) \ > + for (_i = 0; _i < (_eb)->num_batches; ++_i) Again, not sure the 'reuse' comment means but should also use '(_i)'? > > -:371: ERROR:MULTISTATEMENT_MACRO_USE_DO_WHILE: Macros with multiple statements should be enclosed in a do - while loop > #371: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1856: > +#define for_each_batch_add_order(_eb, _i) \ > + BUILD_BUG_ON(!typecheck(int, _i)); \ > + for (_i = (_eb)->num_batches - 1; _i >= 0; --_i) This seems bogus. Wrapping it in a do/while will break the purpose! > > -:371: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_i' - possible side-effects? > #371: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1856: > +#define for_each_batch_add_order(_eb, _i) \ > + BUILD_BUG_ON(!typecheck(int, _i)); \ > + for (_i = (_eb)->num_batches - 1; _i >= 0; --_i) As above. > > total: 1 errors, 0 warnings, 2 checks, 1298 lines checked > 28b699ece289 drm/i915/guc: Handle errors in multi-lrc requests > 962e6b3dce59 drm/i915: Make request conflict tracking understand parallel submits > 368ab12f5205 drm/i915: Update I915_GEM_BUSY IOCTL to understand composite fences > b52570f01859 drm/i915: Enable multi-bb execbuf > 8766155832d7 drm/i915/execlists: Weak parallel submission support for execlists > >
On 10/4/2021 15:26, Patchwork wrote: > == Series Details == > > Series: Parallel submission aka multi-bb execbuf (rev4) > URL : https://patchwork.freedesktop.org/series/92789/ > State : warning > > == Summary == > > $ make htmldocs 2>&1 > /dev/null | grep i915 > ./drivers/gpu/drm/i915/gt/uc/intel_guc.h:166: warning: Function parameter or member 'submission_stall_reason' not described in 'intel_guc' > ./drivers/gpu/drm/i915/gt/uc/intel_guc.h:166: warning: Function parameter or member 'submission_state' not described in 'intel_guc' > > These seem like valid things that need to be fixed. John.
On Tue, Oct 12, 2021 at 03:15:37PM -0700, John Harrison wrote: > On 10/4/2021 15:26, Patchwork wrote: > > == Series Details == > > > > Series: Parallel submission aka multi-bb execbuf (rev4) > > URL : https://patchwork.freedesktop.org/series/92789/ > > State : warning > > > > == Summary == > > > > $ make htmldocs 2>&1 > /dev/null | grep i915 > > ./drivers/gpu/drm/i915/gt/uc/intel_guc.h:166: warning: Function parameter or member 'submission_stall_reason' not described in 'intel_guc' > > ./drivers/gpu/drm/i915/gt/uc/intel_guc.h:166: warning: Function parameter or member 'submission_state' not described in 'intel_guc' > > > > > These seem like valid things that need to be fixed. > Yep, already done. Matt > John. >
On Tue, Oct 12, 2021 at 03:15:00PM -0700, John Harrison wrote: > On 10/4/2021 15:21, Patchwork wrote: > > == Series Details == > > > > Series: Parallel submission aka multi-bb execbuf (rev4) > > URL : https://patchwork.freedesktop.org/series/92789/ > > State : warning > > > > == Summary == > > > > $ dim checkpatch origin/drm-tip > > e2a47a99bf9d drm/i915/guc: Move GuC guc_id allocation under submission state sub-struct > > f83d8f1539fa drm/i915/guc: Take GT PM ref when deregistering context > > -:79: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'gt' - possible side-effects? > > #79: FILE: drivers/gpu/drm/i915/gt/intel_gt_pm.h:44: > > +#define with_intel_gt_pm(gt, tmp) \ > > + for (tmp = 1, intel_gt_pm_get(gt); tmp; \ > > + intel_gt_pm_put(gt), tmp = 0) > > > > -:79: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'tmp' - possible side-effects? > > #79: FILE: drivers/gpu/drm/i915/gt/intel_gt_pm.h:44: > > +#define with_intel_gt_pm(gt, tmp) \ > > + for (tmp = 1, intel_gt_pm_get(gt); tmp; \ > > + intel_gt_pm_put(gt), tmp = 0) > Not sure what these two are complaining about? But 'gt' and 'tmp' should be > wrapped with parentheses when used? > Not, sure but I think this one is fine. > > > > total: 0 errors, 0 warnings, 2 checks, 290 lines checked > > 93e5284929b3 drm/i915/guc: Take engine PM when a context is pinned with GuC submission > > 4dd6554d994d drm/i915/guc: Don't call switch_to_kernel_context with GuC submission > > 8629b55f536c drm/i915: Add logical engine mapping > > 8117ec0a1ca7 drm/i915: Expose logical engine instance to user > > aa8e1eb4dd4e drm/i915/guc: Introduce context parent-child relationship > > aaf50eacc2fd drm/i915/guc: Add multi-lrc context registration > > e5f6f50e66d1 drm/i915/guc: Ensure GuC schedule operations do not operate on child contexts > > adf21ba138f3 drm/i915/guc: Assign contexts in parent-child relationship consecutive guc_ids > > 40ef33318b81 drm/i915/guc: Implement parallel context pin / unpin functions > > 1ad560c70346 drm/i915/guc: Implement multi-lrc submission > > -:364: CHECK:SPACING: spaces preferred around that '*' (ctx:ExV) > > #364: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:771: > > + *wqi++ = child->ring->tail / sizeof(u64); > > ^ > This seems like a bogus warning. > Agree. > > > > total: 0 errors, 0 warnings, 1 checks, 570 lines checked > > 466c01457dec drm/i915/guc: Insert submit fences between requests in parent-child relationship > > 2ece815c1f18 drm/i915/guc: Implement multi-lrc reset > > 7add5784199f drm/i915/guc: Update debugfs for GuC multi-lrc > > -:23: CHECK:LINE_SPACING: Please don't use multiple blank lines > > #23: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:3707: > > + > This should be fixed. > Done. > > > > total: 0 errors, 0 warnings, 1 checks, 67 lines checked > > 966991d7bbed drm/i915: Fix bug in user proto-context creation that leaked contexts > > 0eb3d3bf0c84 drm/i915/guc: Connect UAPI to GuC multi-lrc interface > > 68c6596b649a drm/i915/doc: Update parallel submit doc to point to i915_drm.h > > -:13: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? > > #13: > > deleted file mode 100644 > > > > total: 0 errors, 1 warnings, 0 checks, 10 lines checked > > 8290f5d15ca2 drm/i915/guc: Add basic GuC multi-lrc selftest > > -:22: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? > > #22: > > new file mode 100644 > These two can be ignored. Agree. > > > total: 0 errors, 1 warnings, 0 checks, 190 lines checked > > ade3768c42d5 drm/i915/guc: Implement no mid batch preemption for multi-lrc > > 57882939d788 drm/i915: Multi-BB execbuf > > -:369: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_i' - possible side-effects? > > #369: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1854: > > +#define for_each_batch_create_order(_eb, _i) \ > > + for (_i = 0; _i < (_eb)->num_batches; ++_i) > Again, not sure the 'reuse' comment means but should also use '(_i)'? > I haven't been able to figure out how to fix these ones. I think you only need () if you dref the variable. > > > > -:371: ERROR:MULTISTATEMENT_MACRO_USE_DO_WHILE: Macros with multiple statements should be enclosed in a do - while loop > > #371: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1856: > > +#define for_each_batch_add_order(_eb, _i) \ > > + BUILD_BUG_ON(!typecheck(int, _i)); \ > > + for (_i = (_eb)->num_batches - 1; _i >= 0; --_i) > This seems bogus. Wrapping it in a do/while will break the purpose! > Right. Added the BUILD_BUG_ON here because I did have a bug where I used an unsigned with this macro and that breaks the macro. Matt > > > > -:371: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_i' - possible side-effects? > > #371: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1856: > > +#define for_each_batch_add_order(_eb, _i) \ > > + BUILD_BUG_ON(!typecheck(int, _i)); \ > > + for (_i = (_eb)->num_batches - 1; _i >= 0; --_i) > As above. > > > > > total: 1 errors, 0 warnings, 2 checks, 1298 lines checked > > 28b699ece289 drm/i915/guc: Handle errors in multi-lrc requests > > 962e6b3dce59 drm/i915: Make request conflict tracking understand parallel submits > > 368ab12f5205 drm/i915: Update I915_GEM_BUSY IOCTL to understand composite fences > > b52570f01859 drm/i915: Enable multi-bb execbuf > > 8766155832d7 drm/i915/execlists: Weak parallel submission support for execlists > > > > >
On 10/12/2021 17:15, Matthew Brost wrote: > On Tue, Oct 12, 2021 at 03:15:00PM -0700, John Harrison wrote: >> On 10/4/2021 15:21, Patchwork wrote: >>> == Series Details == >>> >>> Series: Parallel submission aka multi-bb execbuf (rev4) >>> URL : https://patchwork.freedesktop.org/series/92789/ >>> State : warning >>> >>> == Summary == >>> >>> $ dim checkpatch origin/drm-tip >>> e2a47a99bf9d drm/i915/guc: Move GuC guc_id allocation under submission state sub-struct >>> f83d8f1539fa drm/i915/guc: Take GT PM ref when deregistering context >>> -:79: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'gt' - possible side-effects? >>> #79: FILE: drivers/gpu/drm/i915/gt/intel_gt_pm.h:44: >>> +#define with_intel_gt_pm(gt, tmp) \ >>> + for (tmp = 1, intel_gt_pm_get(gt); tmp; \ >>> + intel_gt_pm_put(gt), tmp = 0) >>> >>> -:79: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'tmp' - possible side-effects? >>> #79: FILE: drivers/gpu/drm/i915/gt/intel_gt_pm.h:44: >>> +#define with_intel_gt_pm(gt, tmp) \ >>> + for (tmp = 1, intel_gt_pm_get(gt); tmp; \ >>> + intel_gt_pm_put(gt), tmp = 0) >> Not sure what these two are complaining about? But 'gt' and 'tmp' should be >> wrapped with parentheses when used? >> > Not, sure but I think this one is fine. > >>> total: 0 errors, 0 warnings, 2 checks, 290 lines checked >>> 93e5284929b3 drm/i915/guc: Take engine PM when a context is pinned with GuC submission >>> 4dd6554d994d drm/i915/guc: Don't call switch_to_kernel_context with GuC submission >>> 8629b55f536c drm/i915: Add logical engine mapping >>> 8117ec0a1ca7 drm/i915: Expose logical engine instance to user >>> aa8e1eb4dd4e drm/i915/guc: Introduce context parent-child relationship >>> aaf50eacc2fd drm/i915/guc: Add multi-lrc context registration >>> e5f6f50e66d1 drm/i915/guc: Ensure GuC schedule operations do not operate on child contexts >>> adf21ba138f3 drm/i915/guc: Assign contexts in parent-child relationship consecutive guc_ids >>> 40ef33318b81 drm/i915/guc: Implement parallel context pin / unpin functions >>> 1ad560c70346 drm/i915/guc: Implement multi-lrc submission >>> -:364: CHECK:SPACING: spaces preferred around that '*' (ctx:ExV) >>> #364: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:771: >>> + *wqi++ = child->ring->tail / sizeof(u64); >>> ^ >> This seems like a bogus warning. >> > Agree. > >>> total: 0 errors, 0 warnings, 1 checks, 570 lines checked >>> 466c01457dec drm/i915/guc: Insert submit fences between requests in parent-child relationship >>> 2ece815c1f18 drm/i915/guc: Implement multi-lrc reset >>> 7add5784199f drm/i915/guc: Update debugfs for GuC multi-lrc >>> -:23: CHECK:LINE_SPACING: Please don't use multiple blank lines >>> #23: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:3707: >>> + >> This should be fixed. >> > Done. > >>> total: 0 errors, 0 warnings, 1 checks, 67 lines checked >>> 966991d7bbed drm/i915: Fix bug in user proto-context creation that leaked contexts >>> 0eb3d3bf0c84 drm/i915/guc: Connect UAPI to GuC multi-lrc interface >>> 68c6596b649a drm/i915/doc: Update parallel submit doc to point to i915_drm.h >>> -:13: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? >>> #13: >>> deleted file mode 100644 >>> >>> total: 0 errors, 1 warnings, 0 checks, 10 lines checked >>> 8290f5d15ca2 drm/i915/guc: Add basic GuC multi-lrc selftest >>> -:22: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? >>> #22: >>> new file mode 100644 >> These two can be ignored. > Agree. > >>> total: 0 errors, 1 warnings, 0 checks, 190 lines checked >>> ade3768c42d5 drm/i915/guc: Implement no mid batch preemption for multi-lrc >>> 57882939d788 drm/i915: Multi-BB execbuf >>> -:369: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_i' - possible side-effects? >>> #369: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1854: >>> +#define for_each_batch_create_order(_eb, _i) \ >>> + for (_i = 0; _i < (_eb)->num_batches; ++_i) >> Again, not sure the 'reuse' comment means but should also use '(_i)'? >> > I haven't been able to figure out how to fix these ones. I think you > only need () if you dref the variable. The () is to prevent any kind of operator precedence confusion when passing in something more exciting than a simple variable. Doesn't have to be a deref, it could be any operator. Granted, extremely unlikely for this particular macro but generally good practice just in case. E.g. someone passes in weird things like 'a, func()' as '_i'. John. > >>> -:371: ERROR:MULTISTATEMENT_MACRO_USE_DO_WHILE: Macros with multiple statements should be enclosed in a do - while loop >>> #371: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1856: >>> +#define for_each_batch_add_order(_eb, _i) \ >>> + BUILD_BUG_ON(!typecheck(int, _i)); \ >>> + for (_i = (_eb)->num_batches - 1; _i >= 0; --_i) >> This seems bogus. Wrapping it in a do/while will break the purpose! >> > Right. Added the BUILD_BUG_ON here because I did have a bug where I used > an unsigned with this macro and that breaks the macro. > > Matt > >>> -:371: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_i' - possible side-effects? >>> #371: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1856: >>> +#define for_each_batch_add_order(_eb, _i) \ >>> + BUILD_BUG_ON(!typecheck(int, _i)); \ >>> + for (_i = (_eb)->num_batches - 1; _i >= 0; --_i) >> As above. >> >>> total: 1 errors, 0 warnings, 2 checks, 1298 lines checked >>> 28b699ece289 drm/i915/guc: Handle errors in multi-lrc requests >>> 962e6b3dce59 drm/i915: Make request conflict tracking understand parallel submits >>> 368ab12f5205 drm/i915: Update I915_GEM_BUSY IOCTL to understand composite fences >>> b52570f01859 drm/i915: Enable multi-bb execbuf >>> 8766155832d7 drm/i915/execlists: Weak parallel submission support for execlists >>> >>>
As discussed in [1] we are introducing a new parallel submission uAPI for the i915 which allows more than 1 BB to be submitted in an execbuf IOCTL. This is the implemenation for both GuC and execlists. In addition to selftests in the series, an IGT is available implemented in the first 4 patches [2]. The execbuf IOCTL changes have been done in a single large patch (#21) as all the changes flow together and I believe a single patch will be better if some one has to lookup this change in the future. Can split in a series of smaller patches if desired. This code is available in a public [3] repo for UMD teams to test there code on. v2: Drop complicated state machine to block in kernel if no guc_ids available, perma-pin parallel contexts, reworker execbuf IOCTL to be a series of loops inside the IOCTL rather than 1 large one on the outside, address Daniel Vetter's comments v3: Address John Harrison's comments, add a couple of patches which fix bugs found internally Signed-off-by: Matthew Brost <matthew.brost@intel.com> [1] https://patchwork.freedesktop.org/series/92028/ [2] https://patchwork.freedesktop.org/series/93071/ [3] https://gitlab.freedesktop.org/mbrost/mbrost-drm-intel/-/tree/drm-intel-parallel Matthew Brost (26): drm/i915/guc: Move GuC guc_id allocation under submission state sub-struct drm/i915/guc: Take GT PM ref when deregistering context drm/i915/guc: Take engine PM when a context is pinned with GuC submission drm/i915/guc: Don't call switch_to_kernel_context with GuC submission drm/i915: Add logical engine mapping drm/i915: Expose logical engine instance to user drm/i915/guc: Introduce context parent-child relationship drm/i915/guc: Add multi-lrc context registration drm/i915/guc: Ensure GuC schedule operations do not operate on child contexts drm/i915/guc: Assign contexts in parent-child relationship consecutive guc_ids drm/i915/guc: Implement parallel context pin / unpin functions drm/i915/guc: Implement multi-lrc submission drm/i915/guc: Insert submit fences between requests in parent-child relationship drm/i915/guc: Implement multi-lrc reset drm/i915/guc: Update debugfs for GuC multi-lrc drm/i915: Fix bug in user proto-context creation that leaked contexts drm/i915/guc: Connect UAPI to GuC multi-lrc interface drm/i915/doc: Update parallel submit doc to point to i915_drm.h drm/i915/guc: Add basic GuC multi-lrc selftest drm/i915/guc: Implement no mid batch preemption for multi-lrc drm/i915: Multi-BB execbuf drm/i915/guc: Handle errors in multi-lrc requests drm/i915: Make request conflict tracking understand parallel submits drm/i915: Update I915_GEM_BUSY IOCTL to understand composite fences drm/i915: Enable multi-bb execbuf drm/i915/execlists: Weak parallel submission support for execlists Documentation/gpu/rfc/i915_parallel_execbuf.h | 122 -- Documentation/gpu/rfc/i915_scheduler.rst | 4 +- drivers/gpu/drm/i915/gem/i915_gem_busy.c | 60 +- drivers/gpu/drm/i915/gem/i915_gem_context.c | 225 ++- .../gpu/drm/i915/gem/i915_gem_context_types.h | 6 + .../gpu/drm/i915/gem/i915_gem_execbuffer.c | 796 ++++++--- drivers/gpu/drm/i915/gt/intel_context.c | 50 +- drivers/gpu/drm/i915/gt/intel_context.h | 54 +- drivers/gpu/drm/i915/gt/intel_context_types.h | 73 +- drivers/gpu/drm/i915/gt/intel_engine.h | 12 +- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 66 +- drivers/gpu/drm/i915/gt/intel_engine_pm.c | 13 + drivers/gpu/drm/i915/gt/intel_engine_pm.h | 37 + drivers/gpu/drm/i915/gt/intel_engine_types.h | 7 + .../drm/i915/gt/intel_execlists_submission.c | 63 +- drivers/gpu/drm/i915/gt/intel_gt_pm.h | 14 + drivers/gpu/drm/i915/gt/intel_lrc.c | 7 + drivers/gpu/drm/i915/gt/selftest_execlists.c | 12 +- .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 1 + drivers/gpu/drm/i915/gt/uc/intel_guc.c | 26 + drivers/gpu/drm/i915/gt/uc/intel_guc.h | 49 +- drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 2 +- drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 24 +- drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 27 +- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 1456 ++++++++++++++--- .../drm/i915/gt/uc/selftest_guc_multi_lrc.c | 179 ++ drivers/gpu/drm/i915/i915_query.c | 2 + drivers/gpu/drm/i915/i915_request.c | 143 +- drivers/gpu/drm/i915/i915_request.h | 23 + drivers/gpu/drm/i915/i915_vma.c | 21 +- drivers/gpu/drm/i915/i915_vma.h | 13 +- drivers/gpu/drm/i915/intel_wakeref.h | 12 + .../drm/i915/selftests/i915_live_selftests.h | 1 + include/uapi/drm/i915_drm.h | 139 +- 34 files changed, 3038 insertions(+), 701 deletions(-) delete mode 100644 Documentation/gpu/rfc/i915_parallel_execbuf.h create mode 100644 drivers/gpu/drm/i915/gt/uc/selftest_guc_multi_lrc.c