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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx