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

Tvrtko Ursulin tvrtko.ursulin at linux.intel.com
Mon Mar 25 10:52:07 UTC 2019


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.

Regards,

Tvrtko


More information about the Intel-gfx mailing list