On Tue, May 27, 2014 at 07:32:46PM -0400, Rob Clark wrote: > On Tue, May 27, 2014 at 6:09 PM, Daniel Vetter <daniel@xxxxxxxx> wrote: > > On Tue, May 27, 2014 at 04:06:28PM -0400, Rob Clark wrote: > >> On Tue, May 27, 2014 at 3:26 PM, Daniel Vetter <daniel@xxxxxxxx> wrote: > > > > [snip] > > > >> Well, there was the NONBLOCK atomic flag.. I'm not entirely sure if we > >> should hang so much off of that one flag. > > > > Yeah, a separate VBLANK_SYNCED might be useful. Apparently people also > > want non-blocking modesets. > > random-diverging-from-original-topic-thought.. seems like userspace > just wants a deadline/timeout (hopefully in units of vblanks).. at > least to the level of "I want this to happen on the next vblank (after > rendering completes), or give me an error" vs "I want this to complete > atomically even if it takes a few extra vblanks for things to sort > out".. > > I guess that amounts to what you mean by VBLANK_SYNCED flag, but > VBLANKED_SYNCED might not be a good name.. at least for some hw all > you can do is vblank sync'd.. Hm, we might as well go full monty and allow userspace to request a specific vblank counter. Would be useful for e.g. queuing up a bunch of video frames, which some hw can do. But that would then require cancelling of existing flips, so I guess for now a simple VBLANK_SYNCED flag which emulates pageflip behaviour should be good enough. That would also be useful if userspace attempts an atomic update on drivers which only support atomic modeset (through the crtc helpers), but can't do vblank synced updates. Then they could easily reject those. After all current drivers also often lack a pageflip implementation ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
