On 10/27/2011 12:49 PM, Francisco Jerez wrote:
Thomas Hellstrom<thomas@xxxxxxxxxxxx> 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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
