On Fri, May 16, 2014 at 11:11:38AM +0000, Mateo Lozano, Oscar wrote: > > -----Original Message----- > > From: Chris Wilson [mailto:chris@xxxxxxxxxxxxxxxxxx] > > Sent: Friday, May 16, 2014 12:05 PM > > To: Mateo Lozano, Oscar > > Cc: intel-gfx@xxxxxxxxxxxxxxxxxxxxx > > Subject: Re: [PATCH 09/50] drm/i915: Plumb the context everywhere > > in the execbuffer path > > > > On Fri, May 09, 2014 at 01:08:39PM +0100, oscar.mateo@xxxxxxxxx wrote: > > > From: Oscar Mateo <oscar.mateo@xxxxxxxxx> > > > > > > The context are going to become very important pretty soon, and we > > > need to be able to access them in a number of places inside the > > > command submission path. The idea is that, when we need to place > > > commands inside a ringbuffer or update the tail register, we know > > > which context we are working with. > > > > > > We left intel_ring_begin() as a function macro to quickly adapt legacy > > > code, an introduce intel_ringbuffer_begin() as the first of a set of > > > new functions for ringbuffer manipulation (the rest will come in > > > subsequent patches). > > > > > > No functional changes. > > > > > > v2: Do not set the context to NULL. In legacy code, set it to the > > > default ring context (even if it doesn't get used later on). > > > > Won't rings be stored within the context? So the context should be derivable > > from which ring the operation is being issued on. > > -Chris > > Rings (as in "engine command streamer") still remain in dev_priv and there are only four/five of them. What we store in the context is the new ringbuffer structure (which stores the head, tail, etc...) and the ringbuffer backing object. Knowing only the ring is not enough to derive the context. Ugh, I thought an earlier restructuring request was that the logical ring interface was context specific. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
