drm/doc/rfc: Mark long running workload as complete.

No DRM scheduler changes required, drivers just return NULL in run_job
vfunc.

The rough consensus is that no helper or extra scaffolding is needed
around long-running jobs and no further changes to drm-scheduler.

At least for now. Other drivers that currently do long-running workloads
have no plat to use drm-scheduler. Besides, the current consensus is
that this solution of simply returning NULL to the run_job function should
work without extra code duplication or complication.

On top of that, this item was already a non-blocking one for upstreaming Xe,
so let's move that to the 'Completed' section and revisit the long-running
solution as a community after Xe is integrated in DRM.

Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231201042158.80009-2-rodrigo.vivi@intel.com
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This commit is contained in:
Matthew Brost 2023-11-30 23:21:51 -05:00 committed by Rodrigo Vivi
parent 76385d493c
commit a85607e3cf

View file

@ -132,21 +132,6 @@ the time comes.
The DRM GPUVM helpers do not yet include the userptr parts, but discussions The DRM GPUVM helpers do not yet include the userptr parts, but discussions
about implementing them are ongoing. about implementing them are ongoing.
Long running compute: minimal data structure/scaffolding
--------------------------------------------------------
The generic scheduler code needs to include the handling of endless compute
contexts, with the minimal scaffolding for preempt-ctx fences (probably on the
drm_sched_entity) and making sure drm_scheduler can cope with the lack of job
completion fence.
The goal is to achieve a consensus ahead of Xe initial pull-request, ideally with
this minimal drm/scheduler work, if needed, merged to drm-misc in a way that any
drm driver, including Xe, could re-use and add their own individual needs on top
in a next stage. However, this should not block the initial merge.
This is a non-blocker item since the driver without the support for the long
running compute enabled is not a showstopper.
Display integration with i915 Display integration with i915
----------------------------- -----------------------------
In order to share the display code with the i915 driver so that there is maximum In order to share the display code with the i915 driver so that there is maximum
@ -184,6 +169,18 @@ Xe uAPI high level overview
Xe Pre-Merge Goals - Completed Xe Pre-Merge Goals - Completed
================================ ================================
Long running compute: minimal data structure/scaffolding
--------------------------------------------------------
The generic scheduler code needs to include the handling of endless compute
contexts, with the minimal scaffolding for preempt-ctx fences (probably on the
drm_sched_entity) and making sure drm_scheduler can cope with the lack of job
completion fence.
The goal is to achieve a consensus ahead of Xe initial pull-request, ideally with
this minimal drm/scheduler work, if needed, merged to drm-misc in a way that any
drm driver, including Xe, could re-use and add their own individual needs on top
in a next stage. However, this should not block the initial merge.
Dev_coredump Dev_coredump
------------ ------------