[Intel-gfx] [PATCH] drm/i915: Fix current fb blocking for page flip.
olvaffe at gmail.com
Thu Oct 21 10:49:17 PDT 2010
On Fri, Oct 22, 2010 at 12:18 AM, Jesse Barnes <jbarnes at virtuousgeek.org> wrote:
> On Thu, 21 Oct 2010 17:55:13 +0800
> Chia-I Wu <olvaffe at 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
>> 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
olv at LunarG.com
More information about the Intel-gfx