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).
> But maybe we're decrementing it incorrectly in the buffer exec path or
> allowing rendering to continue too soon?
> --
> Jesse Barnes, Intel Open Source Technology Center
>
--
o...@lunarg.com
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
