On Tue, Aug 23, 2016 at 12:26:44PM +0100, Chris Wilson wrote: > On Tue, Aug 23, 2016 at 11:48:34AM +0100, Chris Wilson wrote: > > Legacy cursor updates are entirely asynchronous with respect to all > > other users of the atomic pipeline. They neither wait for any > > outstanding flips, nor do they cause subsequent flips to be delayed. The > > only ordering we do require is given by making the legacy cursor update > > nonblocking (so the sequence of userspace calls from a process is > > ordered from the pov of the client). > > Hmm, it is also not entirely true. A modeset (reconfiguration of the > pipe size) would require all cursor updates to be flushed, or else we > may make the cursor out-of-bounds which can cause GPU hangs. At the > moment, I think that is governed by the crtc lock and the blocking > nature of the modeset + cursor update. But in the future we want far > more fine grained control over (mostly) asynchronous updates. Yup, that's why I chickened out of fixing this properly ;-) What we could do is set a flag that it's a modeset in drm_crtc_commit, and hand a flag to stall_check to only look for modeset updates. Entirely elliding isn't a good idea. The other issue is how to order cursor updates through the legacy update ioctl against atomic updates on the plane. Not that userspace should mix those, but it could, and we need to make sure they're ordered properly. This is especially painful when watermarks have changed, which is entirely driver-dependent. At that point it's probably time to ragequit. Aside: i915 atomic commit is atm stalling way too much, it signals hw_done too late. Iirc I've sprinkled a fixme into either the commit or code about what needs to be done for that. Legacy cursor updates with hw_done signalled early enough (i.e. when we wrote the register, before the hw has committed the update) should fix this stalling issue too. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
