nouveau page_flip function implement not wait vblank, which cause screen garbage

Francisco Jerez currojerez at riseup.net
Tue Oct 25 05:15:18 PDT 2011


Maarten Maathuis <madman2003 at gmail.com> writes:

> 2011/10/25 chris <wwzbwwzb at 163.com>:
>> Can anyone give a suggestion, is wait-vblank fully implemented in
>> page_flip() for nouveau drm driver?
>>

It's intentionally not implemented.  The reason is that I wanted to
support non-vsync'ed vblank as well, and for vsync'ed blits we had to
think about a different mechanism for vblank synchronization anyway, so
I figured it didn't make that much sense to force vblank synchronization
directly from the pageflip ioctl.

>>
>> At 2011-10-24 14:30:55,chris <wwzbwwzb at 163.com> wrote:
>>
>> Dear,
>>
>> I use NVidia Geforce 7300GT graphics card in my PC, and Linux 3.1rc4 kernel
>> code, git drm 2.4.36.
>>   When I run the vbltest program, it prints  "60HZ"  which indicated the
>> implementation of drmWaitVBlank() and drm_vblank_wait()  is correct.
>>   But when I run modetest with option " -v -s 12:1280x1024" , it prints high
>> fresh rate up to "150 HZ" .  I examing the code , and found that no waiting
>> vblank operation is processed in nouveau_crtc_ page_flip() function. The
>> screen  produced lots of garbage and blink very much.

That's fine if by "garbage" you just mean it's tearing like crazy.

>>[...]
>
> It seems to be, the actual page flipping is done by software method
> (see nv04_graph_mthd_page_flip). There is one thing i'm unsure about
> and that is that we wait for the rendering to be done to the current
> frontbuffer and not the current backbuffer (this is only done if the
> page flip channel is different than the rendering channel). Maybe
> someone else can comment on that.

There's no need to wait for the backbuffer rendering to end because the
pageflip is always pushed through the last channel that has queued
rendering to it, so, the "waiting" is actually done by the GPU. The
waiting to the current frontbuffer (which in most cases is going to be a
cross-channel barrier instead of actual CPU waiting) is necessary for
the (rare) case where you have several channels trying to render to the
same pageflipped drawable, to make sure that the flips are properly
synchronized with respect each other.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 229 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20111025/a694d095/attachment.pgp>


More information about the dri-devel mailing list