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
