On Fri, Apr 18, 2014 at 10:51:46AM +0100, Chris Wilson wrote: > On Fri, Dec 06, 2013 at 02:11:02PM -0800, Ben Widawsky wrote: > > From: Ben Widawsky <ben@xxxxxxxxxxxx> > > > > Previously we dropped the association of a context to a ring. It is > > however very important to know which ring a context ran on (we could > > have reused the other member, but I was nitpicky). > > > > This is very important when we switch address spaces, which unlike > > context objects, do change per ring. > > > > As an example, if we have: > > > > RCS BCS > > ctx A > > ctx A > > ctx B > > ctx B > > > > Without tracking the last ring B ran on, we wouldn't know to switch the > > address space on BCS in the last row. > > > > As a result, we no longer need to track which ring a context "belongs" > > to, as it never really made much sense anyway. > > What about ring->last_context != to? That would force the update on BCS > from A to B. Yeah ctx->last_ring isn't really what we want, I'll add another JIRA for switching all the ctx->last_ring checks to instead check ring->last_context != to. Since that's what matters I think this doesn't have the possibility to have broken anything yet since we don't allow the same context on multiple rings. Except the default one, but mesa creates new contexts anyway afaik. Or am I wrong? It's a definite blocker for execlists and full ppgtt though. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
