On Mon, Jun 23, 2014 at 02:13:55PM +0100, Chris Wilson wrote: > On Mon, Jun 23, 2014 at 01:09:37PM +0000, Mateo Lozano, Oscar wrote: > > So far, yes, but that´s only because I artificially made intel_lrc.c > > self-contained, as Daniel requested. What if we need to execute commands > > from somewhere else, like in intel_gen7_queue_flip()? > > > > And this takes me to another discussion: this logical ring vs legacy ring > > split is probably a good idea (time will tell), but we should provide a way > > of sending commands for execution without knowing if Execlists are enabled > > or not. In the early series that was easy because we reused the ring_begin, > > ring_emit & ring_advance functions, but this is not the case anymore. And > > without this, sooner or later somebody will break legacy or execlists (this > > already happened last week, when somebody here was implementing native sync > > without knowing about Execlists). > > > > So, the questions is: how do you feel about a dev_priv.gt vfunc that takes > > a context, a ring, an array of DWORDS and a BB length and does the > > intel_(logical)_ring_begin/emit/advance based on i915.enable_execlists? > > I'm still baffled by the design. intel_ring_begin() and friends should > be able to find their context (logical or legacy) from the ring and > dtrt.
Well I'm opting for a the different approach of presuming that the callers knows whether we're running with execlists or legacy rings and so will have a clean (and full) split. If we really need to submit massive amounts of cs commands from the kernel we should launch that as a batch, which should be fairly unform for both legacy ring and execlists mode. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
