On Fri, 22 Oct 2010 01:49:17 +0800 Chia-I Wu <olva...@gmail.com> wrote:
> On Fri, Oct 22, 2010 at 12:18 AM, Jesse Barnes <jbar...@virtuousgeek.org> > wrote: > > On Thu, 21 Oct 2010 17:55:13 +0800 > > Chia-I Wu <olva...@gmail.com> wrote: > > > >> Hi list, > >> > >> According to the doc for page_flip, intel_crtc_page_flip should > >> > >> ... block all rendering to the current fb until the flip has > >> completed. > >> > >> I am not entirely sure, but it seems that it is > >> work->old_fb_obj->pending_flip that needs to be incremented instead of > >> work->pending_flip_obj->pending_flip. This patch does fix the > >> rendering artifacts with my Android on i915 project. Any thought? > > In intel_crtc_page_flip()? It *looks* like incrementing the flip count > > for the fb passed into the routine is the right thing to do; we want to > > make sure the fb passed in isn't used again until its flip is complete. > If one flips a buffer and immediately renders to it, the caller should > know that the buffer is the front buffer and there will be artifacts. > Waiting for the flip here makes less sense. > > A common use of page flip looks like > > [X being the front buffer] > 1) render to Y > 2) flip Y > 3) render to X > 4) flip X > 5) render to Y > > A caller expects 3) to be back buffer rendering. It is reasonable to > insert a wait between 2) and 3). That is, have pending_flip of X, > instead of Y, set at 2). You're right, I had it backwards; I think your fix is correct. -- Jesse Barnes, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
