AuroraMiddleware/skia2
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Fix up some comments in regards to gpu flush and submitting.

Browse Source 
Change-Id: I54273609e17a0151c2c91d2775ccae3c5aadbc5d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/292568
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
This commit is contained in:
Greg Daniel 2020-05-28 12:25:09 -04:00 committed by Skia Commit-Bot
parent 226b689471
commit 895a2ad46c
2 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
include/gpu/GrContext.h
View File

@ -329,8 +329,7 @@ public:
* If the return is GrSemaphoresSubmitted::kYes, only initialized GrBackendSemaphores will be
* submitted to the gpu during the next submit call (it is possible Skia failed to create a
* subset of the semaphores). The client should not wait on these semaphores until after submit
* has been called, but must keep them alive until then. If a submit flag was passed in with the
* flush these valid semaphores can we waited on immediately. If this call returns
* has been called, and must keep them alive until then. If this call returns
* GrSemaphoresSubmitted::kNo, the GPU backend will not submit any semaphores to be signaled on
* the GPU. Thus the client should not have the GPU wait on any of the semaphores passed in with
* the GrFlushInfo. Regardless of whether semaphores were submitted to the GPU or not, the
@ -360,7 +359,7 @@ public:
* If the return is GrSemaphoresSubmitted::kYes, only initialized GrBackendSemaphores will be
* submitted to the gpu during the next submit call (it is possible Skia failed to create a
* subset of the semaphores). The client should not wait on these semaphores until after submit
* has been called, but must keep them alive until then. If this call returns
* has been called, and must keep them alive until then. If this call returns
* GrSemaphoresSubmitted::kNo, the GPU backend will not submit any semaphores to be signaled on
* the GPU. Thus the client should not have the GPU wait on any of the semaphores passed in with
* the GrFlushInfo. The client is always responsible for deleting any initialized semaphores.

7
include/gpu/GrTypes.h
View File

@ -244,7 +244,8 @@ typedef void (*GrGpuSubmittedProc)(GrGpuSubmittedContext submittedContext, bool
* passes in an array of fNumSemaphores GrBackendSemaphores. In general these GrBackendSemaphore's
* can be either initialized or not. If they are initialized, the backend uses the passed in
* semaphore. If it is not initialized, a new semaphore is created and the GrBackendSemaphore
* object is initialized with that semaphore.
* object is initialized with that semaphore. The semaphores are not sent to the GPU until the next
* GrContext::submit call is made. See the GrContext::submit for more information.
*
* The client will own and be responsible for deleting the underlying semaphores that are stored
* and returned in initialized GrBackendSemaphore objects. The GrBackendSemaphore objects
@ -282,8 +283,8 @@ struct GrFlushInfo {
};
/**
* Enum used as return value when flush with semaphores so the client knows whether the semaphores
* were submitted to GPU or not.
* Enum used as return value when flush with semaphores so the client knows whether the valid
semaphores will be submitted on the next GrContext::submit call.
*/
enum class GrSemaphoresSubmitted : bool {
kNo = false,