Drop the global lock around most of the Vulkan API commands#2192
Drop the global lock around most of the Vulkan API commands#2192qining merged 2 commits intogoogle:masterfrom
Conversation
ben-clayton
left a comment
There was a problem hiding this comment.
I strongly suspect this will break many things.
There are assumptions throughout the .api files and likely gapii that assumes there are no external changes to the state or encoders for the duration of a call.
We have considered adding an annotation to very specific commands in the API files which may unlock at the fence, but we need to spend a lot of time thoroughly checking these commands are unlock-safe, as well as the all the existing gapii code.
|
We have looked at this on the Vulkan side at least, and I think? everything is probably in good shape, but I agree just making the change across every call may be dangerous. Qining, what about changing the annotation from @Blocking to @threadsafe (or something). |
Unlock before calling some of the underlying API command calls, and lock again after return from the underlying API command calls. This improves the tracing performance, especially when the application builds Vulkan pipelines in multiple threads.
c3309dd to
c974f65
Compare
|
Annotation: "threadsafe" has been added to some of the Vulkan commands. Now we use "threadsafe" instead of "blocking" to control the unlock and relock behavior. |
|
shrug if you folks are sure that the rest of gapii is safe with this, then let's give it a try. I'm sure random crashes will alert us to any issues :) |
…ication crashing GPAID
d352fc4 to
cb075bf
Compare
Unlock before calling the underlying API command calls, and lock again after
return from the underlying API command calls.
This improves the tracing performance, especially when the application
builds Vulkan pipelines in multiple threads.