[Intel-gfx] [PATCH 23/27] drm/i915/guc: Implement no mid batch preemption for multi-lrc
Tvrtko Ursulin
tvrtko.ursulin at linux.intel.com
Mon Sep 13 10:52:22 UTC 2021
On 10/09/2021 21:49, Matthew Brost wrote:
> On Fri, Sep 10, 2021 at 12:25:43PM +0100, Tvrtko Ursulin wrote:
>>
>> On 20/08/2021 23:44, Matthew Brost wrote:
>>> For some users of multi-lrc, e.g. split frame, it isn't safe to preempt
>>> mid BB. To safely enable preemption at the BB boundary, a handshake
>>> between to parent and child is needed. This is implemented via custom
>>> emit_bb_start & emit_fini_breadcrumb functions and enabled via by
>>> default if a context is configured by set parallel extension.
>>
>> FWIW I think it's wrong to hardcode the requirements of a particular
>> hardware generation fixed media pipeline into the uapi. IMO better solution
>> was when concept of parallel submission was decoupled from the no preemption
>> mid batch preambles. Otherwise might as well call the extension
>> I915_CONTEXT_ENGINES_EXT_MEDIA_SPLIT_FRAME_SUBMIT or something.
>>
>
> I don't disagree but this where we landed per Daniel Vetter's feedback -
> default to what our current hardware supports and extend it later to
> newer hardware / requirements as needed.
I think this only re-affirms my argument - no point giving the extension
a generic name if it is so tightly coupled to a specific use case. But I
wrote FWIW so whatever.
It will be mighty awkward if compute multi-lrc will need to specify a
flag to allow preemption, when turning off preemption is otherwise not
something we allow unprivileged clients to do. So it will be kind of
opt-out from unfriendly/dangerous default behaviour instead of explicit
requesting it.
Regards,
Tvrtko
More information about the Intel-gfx
mailing list