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