mirror of
https://mirrors.bfsu.edu.cn/git/linux.git
synced 2025-01-23 06:14:42 +08:00
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:
parent
76385d493c
commit
a85607e3cf
@ -132,21 +132,6 @@ the time comes.
|
||||
The DRM GPUVM helpers do not yet include the userptr parts, but discussions
|
||||
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
|
||||
-----------------------------
|
||||
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
|
||||
================================
|
||||
|
||||
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
|
||||
------------
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user