[Intel-gfx] [PATCH 3/3] glamor: Route fillspans and polyfillrects to glamor.

Chris Wilson chris at chris-wilson.co.uk
Fri Nov 11 14:54:36 CET 2011

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: [Intel-gfx] [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.

Chris Wilson, Intel Open Source Technology Centre

More information about the Intel-gfx mailing list