[Intel-gfx] ctx->engines[rcs0, rcs0]

[Chris Wilson]

Quoting Tvrtko Ursulin (2019-03-25 10:52:07)
> 
> On 25/03/2019 09:03, Chris Wilson wrote:
> > The headline change is the wholehearted decision to allow the user to
> > establish an ctx->engines mapping of [rcs0, rcs0] to mean two logically
> > distinct pipelines to the same engine. An example of this use case is in
> > iris which constructs two GEM contexts in order to have two distinct
> > logical ccontexts to create both a render pipeline and a compute pipeline
> > within the same GL context. As it it the same GL context, it should be
> > a singular timeline and benefits from a shared ppgtt; a natural way of
> > constructing a GEM counterpart to this composite GL context is with an
> > engine map of [rcs0, rcs0] and single timeline.
> > 
> > One corollary to this is that given an ctx->engines[], we cannot assume
> > that (engine_class, engine_instance) is enough to adequately identify a
> > unique logical context. I propose that given user ctx->engines[], we
> > force all subsequent user engine lookups to use indices. Thoughts?
> 
> I guess we need to hear from Mesa - is one GEM context a big win there, 
> as opposed to two contexts with shared PPGTT? If single timeline is 
> desired between the two it might be, but I don't know.
> 
> Having seen the amount of new patches I am naturally averse towards 
> having to review them just to get back to Virtual Engine.
> 
> Is there a way to decouple the new feature request to after Media 
> Scalability? It sounds that there should be - we could start with 
> disallowing [rcs0, rcs0] and then allow it later.

It's not strictly a feature either; but an artifact of the virtual
engine implementation is that it doesn't work with a single engine at
present. So the single engine instance is the virtual engine... That
replacing the degenerate veng with just a pointer to the physical had
relevancy after all ;)
-Chris