• Chris Wilson's avatar
    drm/i915: Allow a context to define its set of engines · 976b55f0
    Chris Wilson authored
    Over the last few years, we have debated how to extend the user API to
    support an increase in the number of engines, that may be sparse and
    even be heterogeneous within a class (not all video decoders created
    equal). We settled on using (class, instance) tuples to identify a
    specific engine, with an API for the user to construct a map of engines
    to capabilities. Into this picture, we then add a challenge of virtual
    engines; one user engine that maps behind the scenes to any number of
    physical engines. To keep it general, we want the user to have full
    control over that mapping. To that end, we allow the user to constrain a
    context to define the set of engines that it can access, order fully
    controlled by the user via (class, instance). With such precise control
    in context setup, we can continue to use the existing execbuf uABI of
    specifying a single index; only now it doesn't automagically map onto
    the engines, it uses the user defined engine map from the context.
    
    v2: Fixup freeing of local on success of get_engines()
    v3: Allow empty engines[]
    v4: s/nengine/num_engines/
    v5: Replace 64 limit on num_engines with a note that execbuf is
    currently limited to only using the first 64 engines.
    v6: Actually use the engines_mutex to guard the ctx->engines.
    
    Testcase: igt/gem_ctx_engines
    Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
    Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
    Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190521211134.16117-2-chris@chris-wilson.co.uk
    976b55f0
i915_gem_context.c 50 KB