On Fri, Apr 21, 2017 at 03:41:10PM -0300, Gustavo Padovan wrote: > 2017-04-11 Daniel Vetter <daniel@xxxxxxxx>: > > > On Mon, Apr 10, 2017 at 12:55:33PM -0700, Eric Anholt wrote: > > > Gustavo Padovan <gustavo@xxxxxxxxxxx> writes: > > > > > > > From: Gustavo Padovan <gustavo.padovan@xxxxxxxxxxxxx> > > Some async cursor updates are not 100% async, as in the hw might still > > scan out the old buffer until the next vblank. Could/should we handle this > > in core? Or are we going to shrug this off with "meh, you asked for > > tearing, you got tearing"? > > Do you know which hw would that be? I don't know. Maybe we should just > don't care for now and see how drivers will solve this to then extract > helpers like we did for atomic nonblocking commits. i915 is one. The only way to do true async updates is throught the CS flip command with a special bit set, and that one only works for the primary plane. All other updates are synced to vblank, i.e. the hw will keep scanning out the old address. But I checked the current code, it's no better than what you've done. More special is iirc rockchip (or some other arm-soc display ip), which on top also has an iommu which falls over if the mapping disappears right away. Easy solution is to not allow fb changes (but that kinda sucks), more involved is delaying the fb cleanup into a worker (but since we don't rate-limit this is tricky too ...). Maybe just go with a FIXME comment here? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
