2D Graphics Library
GrFlushInfo Struct Reference

Struct to supply options to flush calls. More...

#include <GrTypes.h>

Public Attributes

size_t fNumSemaphores = 0
GrBackendSemaphorefSignalSemaphores = nullptr
GrGpuFinishedProc fFinishedProc = nullptr
GrGpuFinishedContext fFinishedContext = nullptr
GrGpuSubmittedProc fSubmittedProc = nullptr
GrGpuSubmittedContext fSubmittedContext = nullptr

Detailed Description

Struct to supply options to flush calls.

After issuing all commands, fNumSemaphore semaphores will be signaled by the gpu. The client 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. 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 themselves can be deleted as soon as this function returns.

If a finishedProc is provided, the finishedProc will be called when all work submitted to the gpu from this flush call and all previous flush calls has finished on the GPU. If the flush call fails due to an error and nothing ends up getting sent to the GPU, the finished proc is called immediately.

If a submittedProc is provided, the submittedProc will be called when all work from this flush call is submitted to the GPU. If the flush call fails due to an error and nothing will get sent to the GPU, the submitted proc is called immediately. It is possibly that when work is finally submitted, that the submission actual fails. In this case we will not reattempt to do the submission. Skia notifies the client of these via the success bool passed into the submittedProc. The submittedProc is useful to the client to know when semaphores that were sent with the flush have actually been submitted to the GPU so that they can be waited on (or deleted if the submit fails). Note about GL: In GL work gets sent to the driver immediately during the flush call, but we don't really know when the driver sends the work to the GPU. Therefore, we treat the submitted proc as we do in other backends. It will be called when the next GrContext::submit is called after the flush (or possibly during the flush if there is no work to be done for the flush). The main use case for the submittedProc is to know when semaphores have been sent to the GPU and even in GL it is required to call GrContext::submit to flush them. So a client should be able to treat all backend APIs the same in terms of how the submitted procs are treated.

Member Data Documentation

◆ fFinishedContext

GrGpuFinishedContext GrFlushInfo::fFinishedContext = nullptr

◆ fFinishedProc

GrGpuFinishedProc GrFlushInfo::fFinishedProc = nullptr

◆ fNumSemaphores

size_t GrFlushInfo::fNumSemaphores = 0

◆ fSignalSemaphores

GrBackendSemaphore* GrFlushInfo::fSignalSemaphores = nullptr

◆ fSubmittedContext

GrGpuSubmittedContext GrFlushInfo::fSubmittedContext = nullptr

◆ fSubmittedProc

GrGpuSubmittedProc GrFlushInfo::fSubmittedProc = nullptr

The documentation for this struct was generated from the following file: