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
