Hi all,
On Wed, 15 Jul 2020 at 12:57, Daniel Vetter daniel@ffwll.ch wrote:
On Wed, Jul 15, 2020 at 1:47 PM Daniel Stone daniel@fooishbar.org wrote:
On Wed, 15 Jul 2020 at 12:05, Bas Nieuwenhuizen bas@basnieuwenhuizen.nl 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