From: "Zhigang Gong" <zhigang.gong@linux.intel.com>
To: 'Chris Wilson' <chris@chris-wilson.co.uk>,
intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 3/3] glamor: Route fillspans and polyfillrects to glamor.
Date: Fri, 11 Nov 2011 18:48:57 +0800 [thread overview]
Message-ID: <056b01cca05f$8478fa80$8d6aef80$@linux.intel.com> (raw)
In-Reply-To: <aefc95$26incm@orsmga001.jf.intel.com>
> -----Original Message-----
> From: Chris Wilson [mailto:chris@chris-wilson.co.uk]
> Sent: Friday, November 11, 2011 5:08 PM
> To: Zhigang Gong; intel-gfx@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@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.
Any comments?
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
next prev parent reply other threads:[~2011-11-11 10:49 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-11 8:31 [PATCH 1/3] glamor: Initial commit to introduce glamor acceleration Zhigang Gong
2011-11-11 8:31 ` [PATCH 2/3] glamor: turn on glamor Zhigang Gong
2011-11-11 9:11 ` Chris Wilson
2011-11-11 10:52 ` Zhigang Gong
2011-11-11 13:12 ` Chris Wilson
2011-11-14 5:01 ` Zhigang Gong
2011-11-14 9:07 ` Chris Wilson
2011-11-14 12:02 ` Zhigang Gong
2011-11-11 12:58 ` Eugeni Dodonov
2011-11-14 5:05 ` Zhigang Gong
2011-11-11 8:31 ` [PATCH 3/3] glamor: Route fillspans and polyfillrects to glamor Zhigang Gong
2011-11-11 9:07 ` Chris Wilson
2011-11-11 10:48 ` Zhigang Gong [this message]
2011-11-11 13:54 ` Chris Wilson
2011-11-14 3:32 ` Zhigang Gong
2011-11-11 12:56 ` [PATCH 1/3] glamor: Initial commit to introduce glamor acceleration Eugeni Dodonov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='056b01cca05f$8478fa80$8d6aef80$@linux.intel.com' \
--to=zhigang.gong@linux.intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox