anv: fix multiple wait/signal on same binary semaphore
We need to guarantee that when vkQueueSubmit() returns the application can actually wait on a signaled semaphore/syncobj. When using a thread to do the submission to i915, this gets a bit tricky in the following case : A syncobj is used both as a wait & signal semaphore and has been signaled once already. It contains a fence before entering vkQueueSubmit(). This means we need to reset the syncobj to ensure when we return from vkQueueSubmit(), the syncobj contains no stale fence. Currently in the Anv, the submission thread is in charge of putting the new fence in the syncobj and also picks up the wait fence directly from the syncobj. This means we can't reset the syncobj from vkQueueSubmit(). The solution to this has been pointed by Bas & Jason : In vkQueueSubmit(), clone the wait syncobj fence into a new temporary syncobj that will be destroy after submission and use this temporary syncobj as a wait fence for i915. This allows us to reset the original syncobj in vkQueueSubmit(). For this to work with wait_before_signal behavior, we also need to do a wait-on-materialize on binary semaphores from vkQueueSubmit(). Otherwise the application thread calling vkQueueSubmit() could race the submission thread and pick up the wrong fence when cloing. v2: Use copy semantic for clone_syncobj_dma_fence() (Jason) Do the cloning prior to adding the syncobj to anv_queue_submit so that if the cloning fails don't have an invalid syncobj in anv_queue_submit (Jason) v3: Fix another syncobj leak (Jason) v4: Fix invalid argument order (Lionel) Signed-off-by:Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: mesa-stable Closes: mesa/mesa#4945 Part-of: <mesa/mesa!11474>