On Wed, Jul 15, 2020 at 1:47 PM Daniel Stone daniel@fooishbar.org wrote:
Hi,
On Wed, 15 Jul 2020 at 12:05, Bas Nieuwenhuizen bas@basnieuwenhuizen.nl wrote:
On Wed, Jul 15, 2020 at 12:34 PM Chris Wilson chris@chris-wilson.co.uk wrote:
Maybe now is the time to ask: are you using sw_sync outside of validation?
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.
Adding Rob and John for more of the android pov. -Daniel