Hi all, On Wed, 15 Jul 2020 at 12:57, Daniel Vetter <daniel@xxxxxxxx> wrote: > On Wed, Jul 15, 2020 at 1:47 PM Daniel Stone <daniel@xxxxxxxxxxxxx> wrote: > > On Wed, 15 Jul 2020 at 12:05, Bas Nieuwenhuizen <bas@xxxxxxxxxxxxxxxxxxx> wrote: > > > Yes, this is used as part of the Android stack on Chrome OS (need to > > > see if ChromeOS specific, but > > > https://source.android.com/devices/graphics/sync#sync_timeline > > > suggests not) > > > > Android used to mandate it for their earlier iteration of release > > fences, which was an empty/future fence having no guarantee of > > eventual forward progress until someone committed work later on. For > > example, when you committed a buffer to SF, it would give you an empty > > 'release fence' for that buffer which would only be tied to work to > > signal it when you committed your _next_ buffer, which might never > > happen. They removed that because a) future fences were a bad idea, > > and b) it was only ever useful if you assumed strictly > > FIFO/round-robin return order which wasn't always true. > > > > So now it's been watered down to 'use this if you don't have a > > hardware timeline', but why don't we work with Android people to get > > that removed entirely? > > I think there's some testcases still using these, but most real fence > testcases use vgem nowadays. So from an upstream pov there's indeed > not much if anything holding us back from just deleting this all. And > would probably be a good idea. It looks like this is just a docs hangover which can be fixed; sw_sync is no longer part of the unified Android kernel image, so it can no longer be relied on post-Treble. So let's just continue on the assumption that sw_sync is not anything anyone can rely on. Cheers, Daniel _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
