Commit a85607e3 authored by Matthew Brost's avatar Matthew Brost Committed by Rodrigo Vivi

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: default avatarMatthew Brost <matthew.brost@intel.com>
Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231201042158.80009-2-rodrigo.vivi@intel.comAcked-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
parent 76385d49
...@@ -132,21 +132,6 @@ the time comes. ...@@ -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 ...@@ -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
------------ ------------
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment