Vulkan: Remove mMutex -> mQueueSubmitMutex relay This is the preparation before the next CL: Vulkan: Improve CommandQueue concurrency crrev.com/c/angle/angle/+/6067346 This change address following problems: Problem 1: - Thread 1: performs long command flush -> `mCmdPoolMutex` locked. - Thread 2: performs submit 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". Note: "Thread 2" may still lock `mMutex` and then block on `mCmdPoolMutex` from the possible `releaseFinishedCommandsLocked()` call. This will be addressed in the follow up. Problem 2: - Thread 1: performs submit -> `mQueueSubmitMutex` locked. - Thread 2: also wants to submit -> `mMutex` locked while blocking on `mQueueSubmitMutex`. - Thread 3: calls some command -> blocks on `mMutex`, essentially waiting for the command submission in "Thread 1". Since `mMutex` is no longer locked in the beginning of the `queueSubmit()` method and there is no lock relay, the `mQueueSubmitMutex` is locked at the beginning of the method instead. This way "Thread 2" will not block the `mMutex`, allowing "Thread 3" to execute any command (except submission) without blocking. Change also fixes race condition in `CommandQueue::waitIdle()`. Call to `mInFlightCommands.back()` must be protected by the `mQueueSubmitMutex` because it accesses `mEndIndex` which is updated in `push()`. Bug: b/267682377 Bug: b/362604439 Change-Id: If0b82f3e35aacf080327531b22d832dd12160448 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6078263 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com>