All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Zhigang Gong" <zhigang.gong@linux.intel.com>
To: 'Chris Wilson' <chris@chris-wilson.co.uk>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 2/2] glamor: Address GLAMOR/UXA flushing problem.
Date: Tue, 15 Nov 2011 20:54:13 +0800	[thread overview]
Message-ID: <06fb01cca395$adad6ba0$090842e0$@linux.intel.com> (raw)
In-Reply-To: <c55c5d$13gmbf@AZSMGA002.ch.intel.com>

> -----Original Message-----
> From: Chris Wilson [mailto:chris@chris-wilson.co.uk]
> Sent: Tuesday, November 15, 2011 8:25 PM
> To: Zhigang Gong; intel-gfx@lists.freedesktop.org
> Cc: zhigang.gong@linux.intel.com
> Subject: Re: [PATCH 2/2] glamor: Address GLAMOR/UXA flushing problem.
> 
> On Tue, 15 Nov 2011 19:36:14 +0800, Zhigang Gong
> <zhigang.gong@linux.intel.com> wrote:
> > This commit introduces a new function in UXA layer need_flush which is
> > used to let the UXA layer to notify the lower layer that some pixmap
> > get modified by GLAMOR. And then the intel driver could know it need
> > to flush front buffer latter.
> >
> > This commit also adds some necessary flushing pointis for UXA layer
> > and glamor layer. Basicly, there are three scenarios:
> >
> > 1. Before calling into glamor layer, it needs to flush all the
> > corresponding UXA batch comand buffer.
> >
> > 2. After calling the glamor rendering functions, it needs to flush the
> > pending GL operations.
> >
> > 3. Before we map a pixmap's BO, we also need to flush all the pending
> > GL operations.
> >
> > The scenario 2 could be eliminated when we fully change to glamor
> > path.
> 
> I much prefer the one-sided uxa_prepare_access() you have implemented
> here for the glamor side. For completeness, you still probably want the
> uxa_finish_access() though. 

I was thinking about that, but current uxa_finish_access doesn't have a
parameter
to indicate the access type. I prefer to change the uxa_finish_access's
prototype
to the same as uxa_prepare_access(). And then will do glamor flush there if
the
access type is GLAMOR_WRITE. I'm just not very sure whether it is the best
way.

Will work out a new patch to implement that soon.

BTW, May I have your review tag in the commits which get reviewed by you.
Thanks.

> Alternatively you need to mark up all
> operations with uxa_prepare_access(GLAMOR | NATIVE | SW, READ |
> WRITE) which then perform the implicit uxa_finish_access() when the
> mode changes, and would also allow you to only flush the glamor
> operations as required.
This looks much complicate than the first solution. I prefer the first
solution.

-- Zhigang
> 
> Aside from that, this looks like the right approach to handling the
flushing.
> -Chris
> 
> --
> Chris Wilson, Intel Open Source Technology Centre

  reply	other threads:[~2011-11-15 12:54 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-15 11:36 [PATCH 1/2] glamor: Move flags check to intel_glamor Zhigang Gong
2011-11-15 11:36 ` [PATCH 2/2] glamor: Address GLAMOR/UXA flushing problem Zhigang Gong
2011-11-15 12:24   ` Chris Wilson
2011-11-15 12:54     ` Zhigang Gong [this message]
2011-11-15 12:57       ` Chris Wilson
2011-11-15 12:10 ` [PATCH 1/2] glamor: Move flags check to intel_glamor Chris Wilson

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='06fb01cca395$adad6ba0$090842e0$@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.