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

[Francisco Jerez <currojerez@riseup.net>]

[-- Attachment #1.1.1: Type: text/plain, Size: 2187 bytes --]

Maarten Maathuis <madman2003@gmail.com> writes:

> 2011/10/25 chris <wwzbwwzb@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@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.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 229 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel