GrProgramElement Class Reference

Base class for GrProcessor. More...

#include <GrProgramElement.h>

Inheritance diagram for GrProgramElement:

Public Member Functions
void	ref () const
void	unref () const
uint32_t	getUniqueID () const
	Gets an id that is unique for this GrProgramElement object. More...
void	validate () const

Protected Member Functions
void	addGpuResource (const GrGpuResourceRef *res)
	Subclasses registers their resources using this function. More...
void	addPendingExecution () const
void	completedExecution () const

Private Types
typedef SkNoncopyable	INHERITED

Private Member Functions
virtual void	notifyRefCntIsZero () const =0
	This will be called when the ref cnt is zero. More...
void	removeRefs () const
void	addPendingIOs () const
void	pendingIOComplete () const

Static Private Member Functions
static uint32_t	CreateUniqueID ()

Private Attributes
int32_t	fRefCnt
int32_t	fPendingExecutions
uint32_t	fUniqueID
SkSTArray< 4, const GrGpuResourceRef *, true >	fGpuResources

Friends
template<typename T >
class	GrPendingProgramElement

Detailed Description

Base class for GrProcessor.

This exists to manage transitioning a GrProcessor from being owned by a client to being scheduled for execution. While a GrProcessor is ref'ed by drawing code its GrGpu resources must also be ref'ed to prevent incorrectly recycling them through the cache. However, once the GrProcessor is baked into a GrPipeline and the drawing code has stopped ref'ing it, it's internal resources can be recycled in some cases.

We track this using two types of refs on GrProgramElement. A regular ref is owned by any client that may continue to issue draws that use the GrProgramElement. The GrPipeline owns "pending executions" instead of refs. A pending execution is cleared by ~GrPipeline().

While a GrProgramElement is ref'ed any resources it owns are also ref'ed. However, once it gets into the state where it has pending executions AND no refs then it converts its ownership of its GrGpuResources from refs to pending IOs. The pending IOs allow the cache to track when it is safe to recycle a resource even though we still have buffered GrBatches that read or write to the the resource.

To make this work all GrGpuResource objects owned by a GrProgramElement or derived classes (either directly or indirectly) must be wrapped in a GrGpuResourceRef and registered with the GrProgramElement using addGpuResource(). This allows the regular refs to be converted to pending IO events when the program element is scheduled for deferred execution.

Moreover, a GrProgramElement that in turn owns other GrProgramElements must convert its ownership of its children to pending executions when its ref count reaches zero so that the GrGpuResources owned by the children GrProgramElements are correctly converted from ownership by ref to ownership by pending IO. Any GrProgramElement hierarchy is managed by subclasses which must implement notifyRefCntIsZero() in order to convert refs of children to pending executions.

Member Function Documentation

void GrProgramElement::addGpuResource ( const GrGpuResourceRef *  res )

inlineprotected

Subclasses registers their resources using this function.

It is assumed the GrProgramResouce is and will remain owned by the subclass and this function will retain a raw ptr. Once a GrGpuResourceRef is registered its setResource must not be called.

uint32_t GrProgramElement::getUniqueID ( ) const

inline

Gets an id that is unique for this GrProgramElement object.

This will never return 0.

virtual void GrProgramElement::notifyRefCntIsZero ( ) const

privatepure virtual

This will be called when the ref cnt is zero.

The object may or may not have pending executions.

Implemented in GrXferProcessor, and GrFragmentProcessor.

---

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

• include/gpu/GrProgramElement.h