On 10/27/2011 12:49 PM, Francisco Jerez wrote: > Thomas Hellstrom<thomas at shipmail.org> writes: > > >> 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. >> >> > That's the case of the nouveau driver, and it's the reason that we don't > respect the API returning -EBUSY when there's an already scheduled flip > request. IMHO that should be up to the driver, or even better, the IOCTL > could be specified to block in case userspace is requesting more > simultaneous page-flips than the kernel driver can handle, in order to > make the resulting behavior consistent for userspace no matter which > implementation is being used. > > >> 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. >> >> > Yeah, it would be good to relax this restriction -- the nouveau driver > has never respected it because we'd end up lock-stepping the GPU (we > wouldn't be sending the next batch of commands until the one sent before > the flip had been completely processed), and it's just not necessary > because we take additional measures to make sure that flips and commands > sent to other hardware queues are properly ordered with respect to one > another. > >
I don't think you need to care about this restriction, since the next batch doesn't arrive for execution until the flip has happened. Waiting to submit in this case was never intended when there is GPU support to order the flip and the next batch of commands, and the waiting is only to protect against rendering errors. >> 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. >> >> > Yes, so the fact that the nouveau pageflip implementation doesn't sync > to vblank before flipping isn't even a bug as it stands. > No it isn't. vmwgfx is doing (or going to do ) the same, since we can't sync to vblank currently. Also we are not holding rendering commands up, since the virtual GPU orders the flips and the next batch of commands. /Thomas
