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

[chris]

I think page_flip ioctl need to realize a synchronous mechanism to control fresh rate...!!!
At 2011-10-25 20:30:39,"Ben Skeggs" <skeggsb at gmail.com> wrote:
>On Tue, 2011-10-25 at 14:15 +0200, Francisco Jerez wrote:
>> 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.
>+1 I deliberately didn't flip 1 bit in the NV50/NVC0 page flipping code
>for this as well.  The interface IMO is flawed.  Though, that said, we
>really should look at doing something properly for this, a lot of people
>do want tear-free goodness.
>
>Ben.
>> 
>> >>
>> >> 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.
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>_______________________________________________
>dri-devel mailing list
>dri-devel at lists.freedesktop.org
>http://lists.freedesktop.org/mailman/listinfo/dri-devel