kc3-lang/angle

2024-12-06T23:47:36

Vulkan: Improve CommandQueue concurrency This is a follow up for: Add a new mutex in CommandQueue to protect Vulkan Command Pool crrev.com/c/angle/angle/+/6020895 There is still scenario, when thread that checks or waits for commands may also wait for other thread to flush its commands: - Thread 1: performs long command flush -> `mCmdPoolMutex` locked. - Thread 2: releases commands -> `mMutex` locked while blocking on `mCmdPoolMutex`. - Thread 3: checks for completed commands -> blocks on `mMutex`, essentially waiting for the command flush from "Thread 1". To fix the above, `mMutex` is split into `mCmdCompleteMutex` and `mCmdReleaseMutex`. This will solve blocking of "Thread 3" in case if "Thread 2" releases commands. With this change, `mCmdCompleteMutex` is only used to check and wait for commands, while not blocking other mutexes (except in `init()`, `destroy()`, and `handleDeviceLost()`), eliminating possibility of blocking. `mCmdReleaseMutex` is only used to release finished batches, while also temporarily locking the `mCmdPoolMutex` to release the commands, therefore this operation may wait for commands flush in other threads (this is OK - Vulkan limitation). `mQueueSubmitMutex` is used for submission and performance counters. During the submission all mutexes may be temporarily locked: `mCmdPoolMutex` to get commands, `mCmdCompleteMutex` to finish batch, and `mCmdReleaseMutex` to release batches. Bug: b/362604439 Change-Id: Ibb7f3a733722a2e202475023742af5e1eaa06826 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6067346 Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>