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@xxxxxxxxx> wrote: >On Tue, 2011-10-25 at 14:15 +0200, Francisco Jerez wrote: >> Maarten Maathuis <madman2003@xxxxxxxxx> writes: >> >> > 2011/10/25 chris <wwzbwwzb@xxxxxxx>: >> >> 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@xxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx >> http://lists.freedesktop.org/mailman/listinfo/dri-devel > > >_______________________________________________ >dri-devel mailing list >dri-devel@xxxxxxxxxxxxxxxxxxxxx >http://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
