FWIW, there was a quite long discussion / argument when the page flip ioctl was designed, and at that time I pointed out that there are hardware capable of pageflipping using the fifo/pipe with optional VSYNC barriers, and that it is actually possible to queue up a number of pageflips in the fifo. Not just one.
The interface description in drm_mode.h is somewhat different to what was agreed upon, namely: 1) The command submission mechanism should block if a user tries to render to a not yet flipped frontbuffer, and that would cause rendering problems. For hardware that flips using a fifo / pipe, that's not really a problem. Thus, any rendering errors due to rendering to a not-yet-flipped frontbuffer is a kernel driver error. The user-space app can avoid being blocked waiting using events. 2) The interface in itself doesn't require flips to be synced to vblanks, as I understand it. However, it should be possible to add a new flag DRM_MODE_PAGE_FLIP_SYNC that tries to sync if at all possible. /Thomas On 10/27/2011 10:00 AM, chris wrote: > 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 >> > _______________________________________________ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >