> -----Original Message----- > From: Chris Wilson [mailto:chris at chris-wilson.co.uk] > Sent: Friday, November 11, 2011 9:55 PM > To: Zhigang Gong; intel-gfx at lists.freedesktop.org > Subject: RE: [PATCH 3/3] glamor: Route fillspans and polyfillrects > to glamor. > > On Fri, 11 Nov 2011 18:48:57 +0800, "Zhigang Gong" > <zhigang.gong at linux.intel.com> wrote: > > > -----Original Message----- > > > From: Chris Wilson [mailto:chris at chris-wilson.co.uk] > > > Sent: Friday, November 11, 2011 5:08 PM > > > To: Zhigang Gong; intel-gfx at lists.freedesktop.org > > > Subject: Re: [PATCH 3/3] glamor: Route fillspans and > > polyfillrects > > > to glamor. > > > > > > On Fri, 11 Nov 2011 16:31:21 +0800, Zhigang Gong > > > <zhigang.gong at linux.intel.com> wrote: > > > > If GLAMOR is enabled, we route UXA's fillspans and polyfillrects > > > > to glamor by default. And if glamor fail to accelerate it, UXA > > > > continue to handle it. > > > > > > How is serialisation handled between the UXA and glamor acceleration > > > routines? Don't you need to flush the UXA batch (if the pixmap is > > > active) before handing over to glamor and similarly flush the glamor > > > pixmap after failure? > > Thanks for pointing this issue out. This is something I want to be > > discussed here. > > > > There are three types of access to the pixmap: > > 1. UXA batch command buffer. > > 2. Glamor through OpenGL > > 3. CPU access mapped BO buffer. > > > > My understanding is that the leading two types has the queue > mechanism > > and need to be handled carefully. In general, we can treat glamor 's > > access as another batch buffer. Then in the place where current intel > > driver need to flush UXA batch buffer, we also need to flush the GL > > operations there. Right? > > > > And besides above places we need to flush glamor, we also need to > > flush UXA batch buffer before call into glamor and also need to flush > > glamor after the glamor rendering function really touch the pixmap. > > Right, we want to consider it as another form of pixmap migration, just > instead of between different regions of memory we are migrating > between different queues. We could envision using fences to coordinate > rendering between the different batches, but that is likely to be overkill > and not possible with most Intel hardware. Understand, so we can't expect to solve this overhead problem that way. IMO, as eventually, glamor will take over all the rendering functions, if glamor is enabled. This heavy flushing may be get eliminated then. Anyway, currently, I still need to work out another patch to handle all the needed flushing OPs. Will submit it to review soon. - Zhigang > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre
