Early Visibility Resolution for Removing Ineffectual Computationsin the Graphics Pipeline

Martı Anglada1 Enrique de Lucas2 Joan-Manuel Parcerisa1 Juan L Aragon3 Antonio Gonzalez1

1Universitat Politecnica de Catalunya 2Semidynamics Technology Services Barcelona 3Universidad de Murciamanglada jmanel antonioacupcedu

enriquedelucassemidynamicscom jlaragonumes

AbstractmdashGPUsrsquo main workload is real-time image render-ing These applications take a description of a (animated)scene and produce the corresponding image(s) An image isrendered by computing the colors of all its pixels It is normalthat multiple objects overlap at each pixel Consequently asignificant amount of processing is devoted to objects that willnot be visible in the final image in spite of the widespread useof the Early Depth Test in modern GPUs which attempts todiscard computations related to occluded objects

Since animations are created by a sequence of similar im-ages visibility usually does not change much across consecutiveframes Based on this observation we present Early VisibilityResolution (EVR) a mechanism that leverages the visibilityinformation obtained in a frame to predict the visibility in thefollowing one Our proposal speculatively determines visibilitymuch earlier in the pipeline than the Early Depth Test Weleverage this early visibility estimation to remove ineffectualcomputations at two different granularities pixel-level andtile-level Results show that such optimizations lead to 39performance improvement and 43 energy savings for a setof commercial Android graphics applications running on state-of-the-art mobile GPUs

Keywords-Graphics Pipeline Tile-Based Rendering EnergyEfficiency Visibility

I INTRODUCTION

Graphics-rich applications are overwhelmingly commonin mobile platforms However achieving an acceptableframe rate in such applications often requires a significantamount of energy a very constrained resource in battery-operated devices

Frames are rendered by processing data through the graph-ics pipeline vertices are transformed lighted and groupedinto primitives which are usually triangles Triangles arethen rasterized into fragments pixel-sized regions of prim-itives upon which a final color is computed and writtento the framebuffer in main memory to be displayed Themain cause of energy consumption in the described pipelineis communication with main memory a great fraction ofwhich is devoted to fragment operations colors are typicallycomputed after accessing stored images named textures andthe resulting color has to be stored in the framebuffer Tile-Based Rendering (TBR) is a rendering paradigm widely usedin mobile devices to reduce memory accesses because it

divides the screen into rectangular sections or tiles that areindependently rendered over small on-chip buffers

This paper presents Early Visibility Resolution (EVR) anovel hardware mechanism implemented on a TBR architec-ture that improves the energy efficiency of GPUs by enablingoptimizations on existing techniques such as Early-Z Testand Rendering Elimination

Improving the Early-Z test Visibility of overlappingfragments is typically handled employing the Z Buffera memory region which stores the depth of the closestfragment to the camera for every pixel in the frame Newfragments compare their depth with the one stored in theirsame position and are only written to the framebuffer if theyare closer than the previously visible fragment However itis common for the color of pixels to be computed multipletimes a phenomenon known as overshading as valuesproduced by previously-computed fragments are occludedby newer fragments if they turn to be closer to the observerTo reduce overshading most GPUs nowadays include anadditional Early-Z test just before the stage that computesthe fragment color However the requirement for the Early-Ztest to reduce the overshading is that opaque primitives areprocessed in front-to-back order so that hidden primitivesare processed after visible ones Our proposed EVR tech-nique reduces the overshading caused by hidden primitivesby identifying them well before they are rasterized andscheduling them after the visible ones thus ensuring thatthey will be rejected by the Early-Z test

Improving Rendering Elimination (RE) RE [1] is atechnique implemented on top of a TBR architecture thatidentifies tiles that do not change between two consecutiveframes RE keeps track of the primitives in each tile and theinput data used for computing their colors Before startingthe rendering process of a tile its input data is comparedagainst that used to compute the same tile in the previousframe and if they match the rendering of the entire tile isskipped because its colors stored in the framebuffer willnot change However we observe that a significant potentialis lost because many equal tiles cannot be identified as suchwhen the only changes between frames occur in hiddenprimitives that do not contribute to the final colors of thetiles Since EVR identifies hidden primitives early they can

be excluded from the tile input data set that RE comparesthus increasing the amount of skipped tiles

Early Visibility Resolution estimates visibility in earlystages of the graphics pipeline by exploiting frame-to-framecoherence Given that animations are produced as a sequenceof similar images visibility tends to remain very similaracross consecutive frames occluded primitives in a frameare prone to be occluded in the following frame as wellThe visibility of a primitive is separately determined forevery tile it overlaps in order to achieve a better precisionsince it may occur that a primitive is partially visible ievisible in some tiles but completely occluded in some othertiles Our proposal is based on computing the depth of thefarthest visible point of each tile in a frame and use thesedepths to predict the visibility of primitives in the next frameWhenever a primitive is assigned to a tile its closest pointto the camera is compared against the depth of the farthestvisible point for that tile in the previous frame if the formeris farther the primitive is considered to be occluded for thattile whereas if it is closer the primitive is considered to bevisible We leverage this early visibility prediction schemeto reduce redundancy in a TBR Graphics Pipeline at twodifferent granularities

bull Fragment level The effectiveness of the traditionalEarly-Z test hidden fragment rejection is improved byprocessing primitives predicted to be occluded afterthose predicted to be visible

bull Tile level The effectiveness of Rendering Eliminationrsquosredundant tile detection is significantly improved byignoring primitives predicted to be occluded whencomputing similarities between tiles

In the Results section we show that early detectionand reordering of potentially occluded primitives reducesovershading by 20 and boosts redundant tile detection by5 yielding speedups of 39 and energy reduction of 43

II BACKGROUND

Tile-Based Rendering The Graphics Pipeline consists ofa sequence of steps required to render a scene generatedby an application Figure 1 shows the block diagram ofa hardware implementation of such pipeline based on thearchitecture of an ARM Mali-450 [2] one of the mostwidespread GPU architectures on the mobile market [3]The pipeline execution is initiated by the application whichsends API commands to the GPU to be processed TheCommand Processor receives these commands and sets theappropriate state for the Graphics Pipeline Among themstreams of vertices are sent as draw commands to be pro-cessed by the pipeline In Tile-Based Rendering (TBR) therendering process is divided into two pipelines Geometryand Raster Furthermore the screen space is partitionedinto regular independently-rendered regions named tileswhich allows for the use of smaller on-chip memories forstorage of temporary depth and color values The Geometry

Pipeline fetches vertices and their attributes (per-vertexinformation such as position color or texture coordinates)from main memory and transforms the vertices from object-space coordinates into the display-space coordinates usinguser-defined programs called vertex shaders and some fixedfunction stages of the pipeline The vertices are groupedinto primitives (usually triangles) in the Primitive Assemblystage which also discards the ones that do not face thecamera or are outside the viewing volume The GeometryPipeline finishes its process in the Polygon List Builderstage which assigns primitives to tiles by filling a memorystructure named Parameter Buffer The Parameter Buffercontains the vertex attributes of all the primitives of theframe being rendered It also stores for each tile its DisplayList a list of pointers to the attributes of the primitives thatoverlap that tile

Raster PipelineFragment ProcessorsFragment Processors

GPUcommand

GPUcommand

CommandProcessorCommandProcessor

VertexFetcherVertex

Fetcher

L2Cache

L2Cache

VertexCacheVertexCache

VertexProcessors

VertexProcessors

PrimitiveAssemblyPrimitiveAssembly

RasterizerRasterizerEarlyDepth Test

EarlyDepth Test

Z-BufferZ-Buffer

ColorBufferColorBuffer

TextureCache

TextureCache

ALU

LoadStore

ALU

Geometry Pipeline

TileCache

TileCache

Polygon ListBuilder

Polygon ListBuilder

TileScheduler

TileScheduler

Blending

TilingEngine

MemoryController

Figure 1 Assumed baseline architecture similar to an ARM Mali-450

The Raster Pipeline is triggered once all the geometry ofthe frame has been processed Tiles are processed sequen-tially by fetching their primitives from the Parameter Bufferand dispatching them to the Rasterizer which discretizesthem into fragments elements containing the informationnecessary to compute the color of a pixel Fragments thencan be queried for visibility in the Early Depth Test stagewhich discards fragments that will not contribute to thecolor of the pixel because an already-processed fragmentoccludes them The fragments passing the test proceed tothe Fragment Processors where their color is computed byuser-defined fragment shaders The output color may thenbe blended with previous computed values for that pixel (incase of transparencies) and the resulting value is stored ina local memory named Color Buffer a rectangular array ofpixel colors consisting of a red green and blue componentfor each color When all of the primitives of a tile havebeen rendered the contents of the Color Buffer are flushedto main memory

Rendering Elimination Rendering Elimination [1] is a

technique that avoids the rendering of tiles that will producethe same color across consecutive frames A signature of theprimitives of each tile is computed and compared with thesignature of the primitives the same tile had in the precedingframe If the two signatures match it is considered that theinputs for the Raster Pipeline have not changed betweenframes and therefore the output will also be the sameConsequently the tile is not rendered and the colors of itspixels are reused with the ones computed in the previousframe Figure 2 shows a block diagram of how the techniqueoperates within the Graphics Pipeline The Signature Buffer1 is an on-chip lookup table that stores for each tile

the signature of the previous frame and the in-progresssignature of the current frame Whenever a primitive reachesthe end of the Geometry Pipeline the signature of its vertexattributes is computed 2 In addition for each tile thatthe primitive overlaps the signature of the current frame forthat tile is updated by combining the temporary value storedin the Signature Buffer entry with the computed signatureof the primitive When all the frame geometry has beenprocessed the Signature Buffer holds the final signaturesfor every tile in the current frame Then whenever a tileis scheduled to be rendered its signatures for the currentand the previous frame are read from the Signature Bufferand compared to decide whether or not the tile needs to berendered 3

PolygonList

Builder

PolygonList

BuilderTile

Scheduler

TileScheduler

ParameterBuffer

ParameterBuffer

Vertex ProcessingVertex Processing

SignatureUnit

SignatureUnit

SignatureBuffer

SignatureBuffer

Fragment ProcessingFragment Processing

Geometry Pipeline Raster Pipeline

Figure 2 Rendering Elimination block diagram

Early Depth Test The Depth Test [4] is a per-fragmentoperation in which occluded fragments are discarded (donot write in the Color Buffer) To do so the depth of theclosest fragment to the camera is kept for every pixel in thescreen in a memory structure named Z Buffer After shadinga fragment and before updating the Color Buffer its depthvalue is checked against the stored value for that position inthe Z Buffer if the new fragment is closer to the camera thanthe previous one the Color Buffer and Z Buffer entries areupdated with the fragmentrsquos color and depth respectivelyOtherwise the buffers are not updated The Early DepthTest is an optimization supported by most modern GPUsin which fragments are discarded before shading them byapplying the Depth Test prior to being dispatched to theFragment Processors a fragment will be shaded only if it

passes this visibility test However not all primitives canbenefit from this optimization because some shaders have thecapability to change the visibility determined by the EarlyDepth Test The most common operations to achieve suchalterations are fragment discard (the execution of the shaderprevents a fragment from progressing into the pipeline thuscausing an incorrect early update of the Z Buffer) and depthwriting (a shader may generate a depth value which maycause a fragment considered visible to become occluded orvice versa)

Blending Transparency is often computed by combininga translucent foreground color with a background color soas to create a filter of the color of the objects behind Toachieve this blending effect an additional color componentnamed alpha expressing the degree of opacity is includedin each pixel The alpha value ranges from 1 to 0 with 1indicating that the fragment is fully opaque and 0 indicatingfull transparency Whenever the fragment shader outputs acolor for a fragment it is combined with the existing valuein the same entry of the Color Buffer in a way that dependson its alpha value To properly render transparent objectsthe value in the Color Buffer must correspond to the colorof all the objects behind the transparent fragment since theblending operation is generally not commutative Thereforethe standard method for applying transparency is to firstrender the opaque geometry (thus taking advantage of theDepth Buffer capabilities) and then render all the translucentgeometry in back-to-front order

III EARLY VISIBILITY RESOLUTION (EVR) OFOCCLUDED PRIMITIVES

Detecting occluded primitives early in the pipeline canprevent us to process them and avoid a significant amount ofineffectual work However this is a complex problem so werely on a simplification that estimates visibility with a lowimplementation cost We exploit the fact that visibility tendsto remain constant across consecutive frames if a primitiveis occluded in a frame it will most likely be occluded inthe following one

A sufficient -but not necessary- condition for a primitiveto be occluded in a tile is that the primitive is entirely locatedfarther from the viewpoint than the farthest visible point inthat tile Based on that observation we label primitives asoccluded in a tile if they are farther than the farthest visiblepoint (hereafter named FVP) for that tile in the previousframe Whenever a frame finishes rendering the visibilityof the complete scene is known so the depth of the FVPcan be extracted for each tile

Visibility is usually determined at a fragment level usingthe Early Depth Test However a large number of mobile 2Dapplications use the so-called Painterrsquos Algorithm [5] whereobjects in the scene are drawn in back-to-front order Thisway a newly-processed opaque fragment always occludespreviously-rendered fragments in the position it maps to

without the need of tracking depth information using theZ Buffer Consequently to determine the FVP for a tilewe must distinguish between primitives that write on the ZBuffer (WOZ primitives) and primitives that do not (NWOZ)

A WOZ Primitives

All information regarding the visibility for these primi-tives is available in the Z Buffer when the tile is renderedThe per-tile FVP depth is computed as the maximum depthvalue stored in the Z Buffer (Zfar) A primitive is labeledas occluded in a given tile if its closest vertex (Znear) to theviewpoint is farther than the FVPrsquos depth from the previousframe

The coarse granularity caused by comparing to a singleZfar value combined with the conservative Znear comparison(which requires that all primitive points are beyond the FVPnot just those overlapping the tile) reduces the detection ratesince not all occluded primitives might be labeled as suchHowever this way the primitives can be labeled as occludedfor a tile earlier in the pipeline with information availableat the Polygon List Builder stage (vertex depths and tilebinning of the primitive) without the need to either clipthem to the boundaries of a tile or rasterize them Note thatZfar is a single value per tile so it is stored in an on-chipmemory buffer at an acceptable energy and area overhead

B NWOZ Primitives

The visibility for these primitives is implicit in the ren-dering order and is therefore not resolved using the ZBuffer However by using a different mechanism occludedprimitives can still be detected in such scenes During thesorting of primitives into tiles we tally how many differentdraw commands have produced primitives that overlappedeach particular tile and store that number in a layer identifiercounter The layer identifier of a tile starts at zero at thebeginning of the frame and is increased by 1 whenever aprimitive that belongs to a new command is sorted to thattile

When a primitive is sorted to a tile it is assigned thecurrent layer identifier of that tile Since opaque primitivesin a layer partially or completely occlude layers laid under itwe can use those identifiers as depth information primitiveswith higher layer identifiers are closer to the observer thanprimitives with smaller ones Later on after rasterizationlayer identifiers are tracked for all the opaque visible frag-ments of a primitive in the Layer Buffer which is a localstructure akin to the Z Buffer

When a tile is completely rendered all the informationconcerning its visibility is available in the Layer Buffer Thedepth of the FVP corresponds to the minimum identifierstored in the Layer Buffer (Lfar) A primitive is labeled asoccluded in a tile if its assigned layer for the current tile issmaller than the tilersquos Lfar from the previous frame

C Hybrid Scenes

A 3D scene is mainly composed of primitives that write inthe Z Buffer but it may also include primitives that do notFor instance a batch of NWOZ primitives are sometimesdrawn at the beginning of the scene as a background or at theend as a HUD1 Besides it is common to find scenes withtraditional alpha blending where geometry is rendered intwo steps In the first one the opaque geometry is renderedIn the second step the translucent primitives are processedin back-to-front order Translucent primitives are NWOZbecause by definition they are not occluders so they mustnot update the Z Buffer

WOZ primitives are also assigned a layer identifier tohelp compare its age relative to NWOZ primitives Howeversince resolving visibility among WOZ primitives themselvesis not determined by their relative age but by comparingtheir explicit depth values we can assign the same layeridentifier to all of the WOZ primitives in a batch If twoprimitives one being a WOZ and the other being an opaqueNWOZ overlap the same pixel visibility is resolved bycomparing their relative age ie by determining which onewas rendered last

The FVP depth of a tile may be either Zfar or Lfardepending on whether the FVP belongs to a WOZ or aNWOZ primitive respectively After computing Lfar wedetermine to which type of primitive it belongs and storethe proper FVP depth value (either Zfar or Lfar) for the tileA boolean value termed FVP-type is then set to indicatewhether the stored FVP corresponds to a WOZ or a NWOZprimitive

Layer 4 3 2

z=05 z=1

1

(a) FVP-type LayerFVP depth 3

Layer 3 2 1

z=0z=05 z=1

(b) FVP-type ZFVP depth 05

Figure 3 FVP depth computation in tiles with both WOZ primitives(white) and NWOZ primitives (striped)

Figure 3 illustrates how the FVP of a tile is computedin the presence of both WOZ and NWOZ primitives Atile is viewed in a top-down perspective with the locationof its primitives represented as rectangles The observer ofthe scene placed on the left ie the right corner is fartherThe top of the figure displays the layer identifiers for allprimitives as well as the Z value for WOZ primitives

1HUD is short for Head-Up Display a visual overlay used to presentinformation to the user

In the scenario presented in Figure 3a Layer 1 is com-pletely occluded by Layer 2 whereas Layer 2 is completelyoccluded by Layers 3 and 4 Layer 3 is visible so the Lfar

of the tile is 3 Since Layer 3 belongs to NWOZ primitivesthe FVP depth of the tile is its Lfar and a correspondingFVP-type that indicates that the FVP is a layer is stored

In the scenario presented in Figure 3b Layer 1 is visibleso the Lfar of the tile is 1 Since Layer 1 belongs to WOZprimitives the FVP depth corresponds to the tilersquos ZfarPrimitives with a depth value of 1 are occluded by primitiveswith smaller depth values while primitives with a depthvalue of 0 do not completely occlude primitives with a depthvalue of 05 Thus the Zfar and consequently the FVP depthof the tile is 05 The FVP-type of the tile is set to indicatethat the FVP is a Z value A primitive is labeled as occludedif one of the following two scenarios occurs

bull The FVP in the previous frame is NWOZ and the layerassigned to the primitive is lower than Lfar

bull The primitive and the FVP in the previous frame areWOZ and the primitiversquos Znear is farther than Zfar

IV REMOVING INNEFECTUAL COMPUTATIONS WITHEVR

In this section we present two optimizations that lever-age the presented EVR mechanism for early detection ofoccluded primitives to avoid ineffectual computations andmemory accesses in the Graphics Pipeline

A Overshading Reduction

Overshading occurs when a pixel is shaded multipletimes because several primitives overlap it If an opaqueprimitive writes into an already-shaded pixel the resourcesdevoted to the previous color computation have been wastedbecause it has no effect in the final image Note that someovershading cannot be avoided such as the one producedby translucent primitives As introduced before GPUs try toreduce overshading by employing an Early Depth Test whichavoids shading a fragment if a closer opaque fragmenthas already been processed Although this mechanism caneliminate a significant fraction of overshading it is heavilydependent on the order that fragments are processed becauseit can only discard fragments which are hidden by thosealready processed A direct solution to the overshadingproblem would be for the application to sort the opaqueprimitives in a front-to-back order However many of thesesoftware-based approaches require building costly spatialhierarchical data structures to render the scene from anysingle viewpoint They are only effective on ldquowalkthroughrdquoapplications where the entire scene is static and only theviewer moves through it because the overheads can beamortized over a large number of frames Furthermore suchapplication-level sorting is often challenging due to cyclicoverlaps among objects or objects containing geometry thatoccludes parts of the same object

Some applications perform a preliminary depth pre-pass(either in hardware or in software) where some or all ofthe geometry is rendered using a simple shader that onlywrites into the Z Buffer After that the actual render pass isexecuted but now having perfect or near-perfect visibilityinformation in the Z Buffer which greatly increases thenumber of fragments discarded by the depth test Despitethe improved efficacy of the depth test the overhead ofthe additional render pass is very high and often offsets itspotential benefits

In this paper we propose to use the speculative visibilitydetermination mechanism described in Section III to dynam-ically reorder opaque primitives so as to render primitivesthat are likely to be occluded after primitives that are likelyto be visible without the need of an additional render passThe reordering is performed in the Polygon List Builderstage when primitives are sorted into tiles In the baselineconfiguration for each primitive the Parameter Buffer isupdated as follows the primitiversquos attributes are stored inmemory and a pointer to those attributes is written into theDisplay List of each tile Then whenever a tile is renderedits Display List is accessed and the pointers to primitivesare dereferenced to access their attributes to rasterize them

The proposed reordering mechanism divides the DisplayList of every tile into two lists Tiles are rendered by fetchinginitially all the primitives from the first list and then theprimitives from the second list Whenever a primitive issorted into a tile its attributes are stored into the ParameterBuffer the same way as in the baseline The pointer tothose attributes on the other hand is stored on one of thelists depending on the type of primitive and its predictedvisibility according to Algorithm 1 This algorithm only

Algorithm 1 Reordering Algorithm based on FVPif Primitive is WOZ then

if Predicted visible thenAppend into First List

elseAppend into Second List

end ifelse NWOZ Primitive

if Second List not empty thenMove Second List to the end of the First List

end ifAppend into First List

end if

reorders opaque WOZ primitives among themselves whilepreserving the order of NWOZ primitives against themselvesand against WOZ primitives Reordering WOZ primitivesdoes not incur in rendering errors NWOZ primitives arenot reordered and all WOZ primitives perform the depthtest as usual which maintains the correctness of the resultproduced by such primitives regardless of the order in which

they are rasterized

2nd Batch1st Batch 4th Batch 3rd Batch

WOZ Primitives Predicted Occluded WOZ Primitives Predicted VisibleNWOZ Primitives

(a) Primitives overlapping a tile divided into 4 batches according to theirprimitive type

1st Batch

List 1 List 2

2nd Batch

3rd Batch

4th Batch

(b) WOZ primitives that are predicted occluded are stored on the SecondList while all other primitives are stored in the First List

Figure 4 Reordering algorithm example

To illustrate Algorithm 1 let us consider Figure 4ashowing 4 different batches of primitives of a particular tileThe two WOZ batches include primitives that are predictedto be visible and primitives that are predicted to be occludedFigure 4b shows how they are reordered

The first processed batch is an NWOZ batch No actionsare performed with the second list since it is empty and allthe primitives in the batch are appended to the first list Nextthere is a WOZ batch whose primitives are appended to thefirst list if they are predicted to be visible in the tile andappended to the second list otherwise When the followingNWOZ batch arrives all the primitives in the second list aremoved to the end of the first list and then the primitives ofthe batch are appended to the first list Finally another WOZbatch is processed whose primitives are again appended tothe two lists according to their predicted visibility

This reordering technique is highly effective at reducingovershading because if the visibility prediction is correct theearly depth test is able to discard more fragments whichreduces the amount of computation and memory accessesdevoted to occluded fragments Note that this scheme doesnot introduce any error as commented above Visibilitymispredictions simply imply a loss of culling effectivenessin the Early Depth Test

B Rendering Elimination Improvement

Rendering Elimination [1] is a technique that detects tilesthat produce the same color across adjacent frames Todo so when primitives are sorted into tiles at the end ofthe Geometry Pipeline a signature per tile is incrementallycomputed on-the-fly with the attributes of all primitivesoverlapping each tile Then when the Raster Pipeline startsprocessing a tile its signature computed for the current

Table IVISIBILITY CASUISTRY

Scenario Frame i Frame i+1

A Visible VisibleB Visible OccludedC Occluded OccludedD Occluded Visible

frame is compared against the signature computed in theprevious frame if both signatures match the tile is notrendered since it will produce the same colors as in theprevious frame Rendering Elimination requires all attributesfrom all primitives of a tile to be exactly the same as inthe previous frame to detect redundancy However in thecase that only occluded primitives change their attributesthe tilersquos colors will be the same as for the precedingframe making Rendering Elimination not able to detect andeliminate such frame-to-frame redundancy In this paperwe also propose using the approximate visibility resolutionmechanism described in Section III to compute signaturesonly with visible primitives so as to improve the effective-ness of Rendering Eliminationrsquos tile redundancy detection

In the baseline operation of Rendering Elimination alookup table named Signature Buffer stores one CRC32per tile Whenever a primitive is sorted the CRC32 ofthe attributes of its vertices is computed Then for all thetiles that the primitive overlaps the corresponding SignatureBuffer entry is read and updated by combining the CRC32value of the entry with the CRC32 value of the sortedprimitive

Using the visibility prediction scheme proposed in Sec-tion III we propose to extend the Rendering Eliminationtechnique as follows For each sorted primitive its depthis compared against the depth of the FVP in the previousframe for each tile it overlaps If the primitive is predictedto be occluded in a tile the Signature Buffer entry forthat tile is not updated with the CRC32 of the primitiveAs it will be shown in the Results section utilizing theFVP depth allows for a significant increase in redundanttile detection Moreover the proposed optimization doesnot produce any rendering errors Table I presents the fourpossibilities regarding the resolved visibility of a primitive(either visible or occluded) across two consecutive frames

For scenarios A and B the optimization behaves likethe baseline Rendering Elimination since the primitive wasvisible in the tile in Frame i it is considered for the signatureof the tile in Frame i + 1 regardless of its final visibilityNote that in scenario B the primitive will be occluded andtherefore will not be considered in the signature in Framei+ 2 This is the case for scenarios C and D

Scenario C is the case that improves over the baselinesince the occluded primitive does not affect the final colorsof the tile not considering the primitive for the signature

enhances redundancy detection while not generating errorsFinally scenario D does not cause rendering errors be-

cause for a primitive P (occluded in Frame i) to be visiblein Frame i+1 at least one of the following two conditionsmust hold

i) P has moved closer to the camera than the farthestdepth of the tile in the previous frame In that case P will beadded to the signature of the tile Since it was not includedin the signature of the previous frame the signatures willdiffer and the tile will be rendered

ii) All the primitives that occluded P have moved (orare not rendered) so that in Frame i + 1 they do nottotally occlude P In that case the attributes of the occluderprimitives must have changed and the signature will bedifferent even if P is not considered for the signature thetile will be rendered

V IMPLEMENTATION

In this section we describe the extra hardware requiredto implement the proposed early visibility resolution mecha-nism which basically consists of additional units to computeand store the FVP (farthest visible point) for all the tiles inthe frame Figure 5 shows how they are integrated into aTBR GPU

PrimitiveAssembly

PrimitiveAssembly

RasterizerRasterizerFragmentProcessing

FragmentProcessing

EarlyDepth

EarlyDepth

CommandProcessor

CommandProcessor

VertexProcessing

VertexProcessing

VertexFetcher

VertexFetcher

ColorBuffer

ColorBuffer

DepthBuffer

DepthBufferTexturesTextures

Hardware

PolygonList

Builder

PolygonList

Builder

TileScheduler

TileScheduler

ParameterBuffer

ParameterBuffer

BlendingBlending

LayerBuffer

LayerBuffer

Memory New Buffer

FVPTable

FVPTable

LayerGenerator

LayerGenerator

Figure 5 Graphics Pipeline including the structures needed to implementFVP computation

A Layer Generator Table

As discussed in Section III layers are tracked to emulatedepth among NWOZ primitives Assigning a layer identifierto a primitive requires to address the following issues

First since the layer identifier is intended to count thenumber of objects (draw commands) whose primitives haveoverlapped a given tile so far each tile must have itsindependent layer counter Of course for a given tile allthe primitives of the same command are assigned the samelayer identifier although that layer may differ from one tileto another

Second since WOZ primitives update their depth into theZ Buffer layer identifiers do not provide any informationamong primitives in a WOZ batch the same identifier canbe assigned to all WOZ primitives in a batch for a giventile

We propose to employ a small on-chip LUT whichwe call Layer Generator Table in order to manage theassociation of layer identifiers to primitives This table hasone entry per tile and each entry contains three fields

1) Last identifier of a command that produced a primitivethat overlapped the tile

2) Last layer assigned to a primitive that overlapped thetile

3) Last type of primitive (WOZNWOZ) that overlappedthe tile

Using the Layer Generator Table (LGT) we can assign alayer to every primitive in all the tiles it overlaps during thePolygon List Builder stage Whenever a primitive is sortedinto a tile the LGT entry for that tile is checked If the storedcommand identifier is the same as the primitiversquos commandidentifier it means that the primitive belongs to the samelayer as the last primitive sorted into that tile Consequentlythe primitive is assigned the layer stored in the entry Aftersorting a primitive into a tile it updates the last type ofprimitive field in the LGT (a binary value NWOZ or WOZ)

On the other hand if the stored command identifieris different to the primitiversquos command the layer maybe increased depending on the type of primitive NWOZprimitives always increase the layer number whereas forWOZ primitives the layer is only increased if the previousprimitive was NWOZ Finally the LUT entry is updatedwith the new command identifier and the new layer value ifthey have changed

The layer identifier of a primitive is stored in the Param-eter Buffer as any other attribute This way layers can beassigned to all the fragments of the primitive at rasterizationtime

B Layer Buffer

The farthest visible layer of a tile can be obtained bycomputing the minimum visible layer of all its pixels Sincetiles are relatively small (eg 16x16 pixels) we can use anon-chip buffer to keep track of per-pixel information for anentire tile This buffer which we call the Layer Buffer hasone entry for every pixel of the tile being rendered (just asthe Z Buffer or the Color Buffer) that stores the visible layerfor that pixel

The Layer Buffer is updated during the Blending stagewhen the final fragment opacity is already determined Todetect opacity we use the same alpha value that fragmentsemploy to blend with colors previously written in the ColorBuffer If the alpha factor is exactly 1 the fragment is opaqueand its layer is written into the Layer Buffer Otherwise

since the fragment is translucent and does not completelyocclude layers behind it the Layer Buffer is not updated

During the blending stage each fragment of a WOZprimitive stores its layer identifier in a register named ZR sothat it identifies the layer of the last visible WOZ primitiveand may be used to distinguish at the end of rendering atile if its FVP corresponds to a WOZ or a NWOZ primitiveie the FVP-type of the tile The value of ZR is comparedto Lfar when the tile finishes rendering if the two valuesare equal the FVP-type of the tile is WOZ Otherwise it isNWOZ

C FVP Table

In order to predict if a primitive is likely to be visible ina tile we use the tilersquos FVP depth of the previous frame sothe entire set of per-tile FVP depths must be stored Suchinformation is maintained in a structure that we call FVPTable The FVP Table has one entry per tile with eachentry containing the previous framersquos FVP depth for that tileEach entry in the table also stores the FVP-type to indicatewhether the type of data stored is a Z or a layer identifier

Whenever a tile finishes rendering its FVP-type is de-termined If the FVP depth belongs to a NWOZ primitivethe FVP Table entry for the tile is updated with Lfar settingits FVP-type bit Otherwise the FPV entry for the tile isupdated with Zfar and the entryrsquos FVP-type bit is cleared

VI EVALUATION METHODOLOGY

A Simulator infrastructure

We employ the Teapot simulation framework [6] to eval-uate our proposal Teapot runs unmodified Android appli-cations for mobile platforms and obtains GPU performanceand energy consumption statistics Table II lists the parame-ters used in the simulations in order to model an architectureresembling the ARM Mali-450 GPU [2] the most widelyused GPU architecture nowadays with almost 20 of themobile GPU market [3]

The traces that feed the Teapot cycle-accurate simulatorare obtained via a two-step process First an Android appli-cation is run in the Android emulator [7] and every OpenGLcommand sent to the GPU is intercepted and stored in a fileSecond those OpenGL commands are fed to the softwarerenderer included in Gallium3D [8] which is instrumentedto generate a trace containing all the information neededto guide the cycle accurate execution such as vertex datashader instructions or memory addresses of the differentstages of the Graphics Pipeline For each application wesimulate 60 consecutive frames from the original applicationrun

McPAT [9] is used to estimate the energy consumptionof the GPU All the additional hardware required for theproposed technique (Layer Generator Table FVT tableLayer Buffer comparators and registers) is modelled usingMcPATrsquos components (SRAMs Registers MUXes XORs)

Table IIGPU SIMULATION PARAMETERS

Baseline GPU Parameters

Tech Specs 400 MHz 1 V 32 nmScreen Resolution 1196x768Tile Size 16x16 pixels

Main Memory

Latency 50-100 cyclesBandwidth 4 Bcycle (dual channel LPDDR3)Size 1 GB

Queues

Vertex (2x) 16 entries 136 bytesentryTriangle Tile 16 entries 388 bytesentryFragment 64 entries 233 bytesentry

Caches

Vertex Cache 64 bytesline 2-way associative4 KB 1 bank 1 cycle

Texture Caches (4x) 64 bytesline 2-way associative8 KB 1 bank 1 cycle

Tile Cache 64 bytesline 8-way associative128 KB 8 banks 1 cycle

L2 Cache 64 bytesline 8-way associative256 KB 8 banks 2 cycles

Color Buffer 64 bytesline 1-way associative1 KB 1 bank 1 cycle

Depth Buffer 64 bytesline 1-way associative1 KB 1 bank 1 cycle

Non-programmable stages

Primitive assembly 1 trianglecycleRasterizer 16 attributescycleEarly Z test 32 in-flight quad-fragments 1 Depth Buffer

Programmable stages

Vertex Processor 1 vertex processorFragment Processor 4 fragment processors

Additional hardware

Layer Generator Table 3600 entries 3 bytesentryFVP Table 3600 entries 4 bytesentryLayer Buffer 64 bytesline 1-way associative

1 KB 1 bank 1 cycle

Regarding system memory Teapot employs DRAMSim2[10]

B Benchmarks

Table III presents the benchmarks employed to test theproposed approach which correspond to twenty unmodifiedAndroid graphics applications All of these applicationshave millions of downloads according to Google Play [11]with some of them surpassing 500 million downloads Theset of benchmarks includes games of the most populargenres in the mobile segment [12] such as puzzle arcadeand simulation The benchmarks also contain a variety ofworkloads completely 2D scenes such as cde or wmwscenes with simple 3D models such as ata or tib) and

scenes with more sophisticated models such as 300 or mstApplications classified as 3D contain both WOZ and NWOZprimitives while applications classified as 2D only containNWOZ primitives

Table IIIBENCHMARK SUITE

Benchmark Alias Genre Type

300 Seize your glory 300 Action 3DAir Attack ata Arcade 3DCrazy Snowboard csn Arcade 3DModern Strike mst First Person Shooter 3DTemple Run ter Platform 3DTigerball tib Physics Puzzle 3DAngry Birds abi Puzzle 2DArmymen arm Strategy 2DAvenger Legends ale Strategy 2DCandy Crush Saga ccs Puzzle 2DCastle Defense cde Tower Defense 2DClash of Clans coc MMO Strategy 2DCut the Rope ctr Puzzle 2DDude Perfect dpe Puzzle 2DHayday hay Simulation 2DHopeless hop Action Survival 2DMagic Touch mto Arcade 2DRedsun red Strategy 2DWherersquos my water wmw Puzzle 2DWorld of goo wog Physics Puzzle 2D

VII EXPERIMENTAL RESULTS

Figure 6 shows the energy consumption of the GPU-Memory system normalized to the Baseline GPU for our setof benchmarks The proposed optimizations that leverage anearly prediction of the visibility achieve a 43 reduction ofenergy consumption on average Energy savings are obtainedin all benchmarks with maximums of more than 80(cde dpe) Figure 7 shows the execution time divided intoGeometry and Raster pipelines normalized to the baselineOn average the proposed techniques achieve 39 executiontime reduction with maximums of more than 70 (ccs cdedpe)

057

01

02

03

04

05

06

07

08

09

1

No

rmal

ize

d e

ne

rgy

con

sum

pti

on

Overhead by additional accesses Overhead by additional hardware

Figure 6 Energy consumption of our EVR proposal normalized to theBaseline GPU

The energy overheads are mainly due to additional writesto the Parameter Buffer to store the layer identifiers Thisoverhead is quite moderate 21 on average as it can be

061

0

01

02

03

04

05

06

07

08

09

1

No

rmal

ize

d e

xecu

tio

n t

ime

Geometry Geometry overhead Raster

Figure 7 Execution time of our EVR proposal normalized to the BaselineGPU

seen in Figure 6 Figure 6 also illustrates that the addi-tional hardware added by the proposed mechanism incursin only 12 energy consumption overhead on average thestructures needed to manage the FVP information (LayerGenerator Table Layer Buffer and FVP Table) generate05 additional static and dynamic energy consumptionwhile the LUTs needed to implement Rendering Elimina-tion contribute to an additional 07 energy consumptionThe computation of Rendering Eliminationrsquos tile signaturesincurs in time overhead in the Geometry Pipeline whenevera primitive overlaps a large number of tiles since thepipeline is stalled waiting for all signatures to be sequentiallyupdated Figure 7 reports such overheads in execution timewhich on average represents 05 of the total

300 ata csn mst ter tib Average

0

1

2

3

4

5

6

Shad

ed

fra

gme

nts

pe

r p

ixe

l

Baseline EVR Oracle

Figure 8 Comparison of the number of shaded fragments per pixel amongthe baseline GPU our EVR proposal and an oracle

These important reductions in energy consumption andexecution time are mainly produced by avoiding the process-ing of ineffectual fragments (fragments that are occluded orare the same as in the previous frame) Figure 8 shows thenumber of fragments shaded per pixel using the proposedearly visibility resolution mechanism to reorder primitives(EVR) compared to the baseline for our set of 3D bench-marks We also compare our scheme with an oracle approach(which ideally assumes that the Z Buffer is initialized withthe final visibility of the tile ndashthe final depth valuesndash beforeit is executed) EVR significantly reduces (20) the numberof vainly shaded fragments and its results are close to thoseobtained by an oracle approach EVR cannot reach the oraclebecause of its approximate nature First it uses visibilityinformation of the previous frame which may have changed

Second it estimates visibility at a primitive-level while theoracle resolves visibility at the finest possible granularityfragment level

Moreover a large fraction of tiles are detected to beredundant and its execution is completely bypassed avoidingnot only the Fragment Shader stage for all their fragmentsbut also the rest of the stages of the Raster Pipeline forthose tiles Figure 9 shows the percentage of detectedredundant tiles ndashproducing the same colors as the previousframendash for our set of benchmarks Results are shown for thebaseline Rendering Elimination (RE) the proposed EVR-aided Rendering Elimination (EVR) and an oracle setup thatcan perfectly identify all tiles of a frame that are equal tothose of the previous frame

0

10

20

30

40

50

60

70

80

90

100

Det

ect

ed

eq

ual

tile

s

EVR RE Oracle

Figure 9 Percentage of detected equal tiles by EVR compared to REand an oracle

On average EVR avoids the rendering of 54 of the tilesreducing 5 more tiles than the baseline RE Predicting oc-cluded primitives and not adding them to the tilersquos signatureallows the detection of equal tiles in benchmarks in whichRE was hardly effective such as 300 or mst The majorityof these tiles that are identified as redundant corresponds toportions of the screen in which WOZ primitives are coveredby NWOZ primitives in the form of a HUD In most casesthe scene contains objects that are in motion but completelyoccluded by NWOZ geometry The layer-based visibilityscheme allows EVR to identify additional redundant tilesin benchmarks with a high degree of redundancy detectedby RE such as cde or mto In some applications such as hayor wmw the additional tiles eliminated exceeds 10 witha maximum of 30

The additional redundant tiles detected results in anaverage 10 reduction of energy consumption comparedto the baseline RE as presented in Figure 10 The earlyvisibility resolution incurs in some overheads which aregrouped together in the figure In the Geometry Pipeline theLayer Generator and FVP tables are accessed to generate alayer identifier which is stored in the Parameter Buffer Inthe Raster Pipeline the layer identifiers are read and writteninto the Layer Buffer When a tile finishes its rendering itsFVP is computed by accessing the Z and Layer Buffers andthe result is stored in the FVP Table Although the required

09

02

03

04

05

06

07

08

09

1

Ener

gy c

on

sum

pti

on

no

rmal

ized

to

RE

Overhead by FVP Computation

Figure 10 Energy consumption of our EVR proposal normalized to RE

sequential check of the two tables for each primitive andeach tile to which it is mapped could incur in some timeoverhead it is more than offset by the reduction in numberof primitives that can skip the signature computation stepsince they are occluded This is shown in Figure 11 whichcompares execution time broken down into Geometry andRaster Pipelines for the Baseline GPU RE and our proposedEVR approach for early visibility resolution Note that REhas to read the temporary hashes held in the Signature Bufferfor all the tiles that a primitive overlaps shift them as manybytes as the size of the primitive and finally combine themwith the hash of the primitive to produce a new signature forthe tile This process is avoided in our scheme if a primitiveis determined to be occluded in a tile since EVR marks it notto be included into the tilersquos signature The only exceptionwhere our EVR scheme does not reduce Geometry cycles ishop a benchmark that has very few primitives concentratedin a reduced amount of tiles Consequently the averagenumber of primitives to combine into the signature of a tile issmall limiting the benefits of occluded primitive detectionOn average our EVR mechanism reduces the execution timein the Geometry Pipeline by 4 with respect to RE

Moreover Rendering Elimination may induce time andenergy overheads in benchmarks where not enough redun-dant tiles are detected to offset the signature computationsuch as 300 or mst On the other hand our scheme is moreeffective at detecting redundant tiles and for non-redundanttiles specially in 3D benchmarks the primitive reordering in-creases the efficiency of the Early Depth Test which reducesthe amount of computations in the fragment processors Thisresults in overall speedups for all benchmarks

VIII RELATED WORK

Occlusion culling is a fundamental problem in computergraphics with an extensive literature spanning more thanthree decades In this section we focus on the most influ-ential works and the ones most related to our proposal

The Z Buffer [4] is the de facto standard to resolvevisibility due to its effectiveness and low implementationcost The Hierarchical Z Buffer [13] is a variation of thebaseline technique in which a depth pyramid is used to testvisibility The base level of the pyramid is the Z Buffer

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

300 ata csn mst ter tib abi arm ale ccs cde coc ctr dpe hay hop mto red wmw wog AVG

0

02

04

06

08

1

No

rmal

ize

d e

xecu

tio

n t

ime

Geometry Raster

Figure 11 Execution time comparison of our EVR proposal and RE against the baseline GPU

and higher levels are constructed by combining the depthof four pixels at the next lower level typically by choosingthe farthest one Entire primitives can be discarded withoutaccessing the Z Buffer by comparing their nearest depthagainst the values in higher levels in the pyramid OurEVR proposal also compares the depth of primitives toa FVP depth which would correspond to the top of thepyramid of the Hierarchical Z Buffer However the FVPdepth contains final visibility information which allowsunlike the Z pyramid to detect primitives that will beoccluded by others processed later Moreover the FVP depthincludes more information than just the top of the Z pyramidallowing the detection of occluded NWOZ primitives that donot use the Z buffer

Z-Prepass [14] draws the scene in two steps first thegeometry is rendered using simple fragment shaders onlyto quickly fill the Z Buffer Later the geometry is renderedagain with proper shaders but now with perfect visibilityinformation in-place so that all occluded fragments can bediscarded This additional render pass incurs in significantoverheads which may not always be offset by the increase inthe fragments discarded in the Early Depth Test By workingat a coarser granularity (primitive instead of fragment) EVRdoes not need to perform the pre-pass but still achievesresults comparable to having complete visibility information

The concept of layers has been previously adopted inthe context of occlusion culling most notably in DepthPeeling [15] an algorithm that renders geometry multipletimes peeling off the surface layer at each pixel in eachpass Recently Andersson et al [16] leveraged a two-layer representation of depths to avoid bandwidth spent inupdating the Hierarchical Z Buffer while in the work ofScheckel and Kolb [17] layers are used in combinationwith the alpha parameter to completely cull transparentfragments Unlike EVR these approaches cannot combinevisibility information of both WOZ and NWOZ primitivesfor a better visibility determination

Computing visibility at a fragment level (known as image-precision [18]) is useful to solve certain problems suchas circular dependencies However resolving visibility ata coarser grain could reduce the number of computations

needed Hardware occlusion queries [19] are a feature thatallow the user to query simple geometry (such as thebounding volumes) against the current contents of the ZBuffer The query counts the number of fragments thatpass the Z Test and the result allows the application toavoid rendering entire objects at the expense of CPU-GPUsynchronization Furthermore as with the Early Depth Testin order for occlusion queries to perform well both objectsand queries must be sent in front-to-back order EVR istransparent to the application in both axis it does not requireneither synchronization nor ordering

Multiple works reduce overshading by means of reorder-ing the primitives that make up a scene Govindaraju et al[20] propose an algorithm to sort non-overlapping objectsin either front-to-back or back-to front order from a givenviewpoint In the work of Chen et al [21] static objectsare preprocessed in order to create a depth-sorted list ofprimitives for every possible viewpoint The approach ofHan and Sander [22] also preprocesses objects to createseveral sorted lists that are indexed at runtime to ensureoptimal order but they consider movement by taking intoaccount not only viewpoints but also several key framesWeber and Stamminger [23] use a graph representationof dependencies in animated scenes with a fixed camerato sort primitives accordingly and leverage frame-to-framecoherence to merge different graphs and keep the overallstructure manageable VRO [24] also takes advantage oftemporal coherence to reorder objects entirely in hardwareand reduce overshading Unlike these approaches EVR isapplied at a finer granularity (primitive instead of object)does not need to perform any preprocess and can also beemployed in interactive scenes not just animated ones

IX CONCLUSIONS

We have presented a mechanism to determine visibilityin early stages of the Graphics Pipeline based on exploitingframe coherence Since consecutive frames tend to be verysimilar we use the information of a frame to estimate thevisibility for the following one

The proposed technique collects the depth of the farthestvisible primitive of every tile whenever its rendering processis complete For each overlapped tile the depth of a primitive

is compared against the depth stored for that tile in thepreceding frame If it is farther the primitive is occluded

This paper demonstrates the benefits of early visibilityprediction to remove ineffectual computations by increasingthe effectiveness of the Early Z Test a commonly usedtechnique in contemporary GPUs and Rendering Elimina-tion a recently proposed technique to exploit redundantcomputations The former works at pixel granularity and thelatter works at tile granularity

Using the predicted visibility information opaque prim-itives whose visibility is resolved using the Z Buffer arereordered such that primitives predicted as visible are ren-dered first which avoids the shading of occluded fragmentsBesides primitives predicted to be occluded are not con-sidered when generating the signature used by RenderingElimination to identify tiles that are equal to the ones in theprevious frame That increases the number of tiles that areidentified as redundant and consequently whose renderingcan be avoided

Our technique provides average speedups of 39 andenergy savings of 43 for a set of commercial Android ap-plications The reorder mechanism achieves overshading re-ductions comparable to having a Z Buffer filled with perfectvisibility information without requiring any additional renderpass to compute depths On the other hand by improvingthe tile redundancy detection of Rendering Elimination theraster pipeline of the GPU skips the rendering of more thanhalf of the tiles on average

X ACKNOWLEDGEMENTS

This work has been partially supported by the Span-ish State Research Agency under grant TIN2016-75344-R (AEIFEDER EU) and by the Generalitat de Catalunyaunder the AGAUR-FI program

REFERENCES

[1] M Anglada E de Lucas J-M Parcerisa J L AragonP Marcuello and A Gonzalez ldquoRendering elimination Earlydiscard of redundant tiles in the graphics pipelinerdquo in Pro-ceedings of the 25th IEEE International Symposium on High-Performance Computer Architecture IEEE 2019

[2] ldquoArm mali-450 gpurdquo httpsdeveloperarmcomproductsgraphics-and-multimediamali-gpusmali-450-gpu accessedDecember 10 2018

[3] ldquoHardware gpu marketrdquo httphwstatsunity3dcommobilegpuhtml accessed December 10 2018

[4] E Catmull ldquoA subdivision algorithm for computer display ofcurved surfacesrdquo tech rep Utah University Salt Lake CitySchool of Computing 1974

[5] ldquoPainterrsquos algorithmrdquo httpswwwsiggraphorgeducationmaterialsHyperGraphscanlinevisibilitypainterhtmaccessed December 10 2018

[6] J-M Arnau J-M Parcerisa and P Xekalakis ldquoTeapot atoolset for evaluating performance power and image qualityon mobile graphics systemsrdquo in Proceedings of the 27thInternational ACM Conference on Supercomputing pp 37ndash46 ACM 2013

[7] ldquoAndroid studiordquo httpsdeveloperandroidcomstudioindexhtml accessed December 10 2018

[8] ldquoGallium3drdquo httpswwwfreedesktoporgwikiSoftwaregallium accessed December 10 2018

[9] S Li J H Ahn R D Strong J B Brockman D M Tullsenand N P Jouppi ldquoMcPAT An Integrated Power Area andTiming Modeling Framework for Multicore and ManycoreArchitecturesrdquo in Proceedings of the 42nd Annual IEEEACMInternational Symposium on Microarchitecture pp 469ndash4802009

[10] P Rosenfeld E Cooper-Balis and B Jacob ldquoDramsim2 Acycle accurate memory system simulatorrdquo IEEE ComputerArchitecture Letters vol 10 no 1 pp 16ndash19 2011

[11] ldquoGoogle playrdquo httpsplaygooglecom accessed December10 2018

[12] ldquoMobile game statisticsrdquo httpsmediumcomsm appintelnew-mobile-game-statistics-every-game-publisher-should-know-in-2016-f1f8eef64f66 accessed December 102018

[13] N Greene M Kass and G Miller ldquoHierarchical z-buffervisibilityrdquo in Proceedings of the 20th Annual Conference onComputer Graphics and Interactive Techniques pp 231ndash238ACM 1993

[14] ldquoEarly z rejectionrdquo httpssoftwareintelcomen-usarticlesearly-z-rejection-sample accessed December 10 2018

[15] C Everitt ldquoInteractive order-independent transparencyrdquoWhite paper NVIDIA vol 2 no 6 p 7 2001

[16] M Andersson J Hasselgren and T Akenine-MollerldquoMasked depth culling for graphics hardwarerdquo ACM Trans-actions on Graphics vol 34 no 6 p 188 2015

[17] S Scheckel and A Kolb ldquoMin-max mipmaps for efficient2d occlusion cullingrdquo in Conference on Computer GraphicsVisualization and Computer Vision 2016

[18] I E Sutherland R F Sproull and R A SchumackerldquoA characterization of ten hidden-surface algorithmsrdquo ACMComputing Surveys vol 6 no 1 pp 1ndash55 1974

[19] O Mattausch J Bittner and M Wimmer ldquoChc++ Coherenthierarchical culling revisitedrdquo in Computer Graphics Forumvol 27 pp 221ndash230 Wiley Online Library 2008

[20] N K Govindaraju M Henson M C Lin and D ManochaldquoInteractive visibility ordering and transparency computationsamong geometric primitives in complex environmentsrdquo inProceedings of the 2005 Symposium on Interactive 3D Graph-ics and Games pp 49ndash56 ACM 2005

[21] G Chen P V Sander D Nehab L Yang and L Hu ldquoDepth-presorted triangle listsrdquo ACM Transactions on Graphicsvol 31 no 6 p 160 2012

[22] S Han and P V Sander ldquoTriangle reordering for reducedoverdraw in animated scenesrdquo in Proceedings of the 20thACM SIGGRAPH Symposium on Interactive 3D Graphics andGames pp 23ndash27 ACM 2016

[23] C Weber and M Stamminger ldquoTopological triangle sortingfor predefined camera pathsrdquo in Proceedings of the Confer-ence on Vision Modeling and Visualization pp 153ndash160Eurographics Association 2016

[24] E De Lucas P Marcuello J-M Parcerisa and A GonzalezldquoVisibility rendering order Improving energy efficiency onmobile gpus through frame coherencerdquo IEEE Transactionson Parallel and Distributed Systems 2018

be excluded from the tile input data set that RE comparesthus increasing the amount of skipped tiles

Early Visibility Resolution estimates visibility in earlystages of the graphics pipeline by exploiting frame-to-framecoherence Given that animations are produced as a sequenceof similar images visibility tends to remain very similaracross consecutive frames occluded primitives in a frameare prone to be occluded in the following frame as wellThe visibility of a primitive is separately determined forevery tile it overlaps in order to achieve a better precisionsince it may occur that a primitive is partially visible ievisible in some tiles but completely occluded in some othertiles Our proposal is based on computing the depth of thefarthest visible point of each tile in a frame and use thesedepths to predict the visibility of primitives in the next frameWhenever a primitive is assigned to a tile its closest pointto the camera is compared against the depth of the farthestvisible point for that tile in the previous frame if the formeris farther the primitive is considered to be occluded for thattile whereas if it is closer the primitive is considered to bevisible We leverage this early visibility prediction schemeto reduce redundancy in a TBR Graphics Pipeline at twodifferent granularities

bull Fragment level The effectiveness of the traditionalEarly-Z test hidden fragment rejection is improved byprocessing primitives predicted to be occluded afterthose predicted to be visible

bull Tile level The effectiveness of Rendering Eliminationrsquosredundant tile detection is significantly improved byignoring primitives predicted to be occluded whencomputing similarities between tiles

In the Results section we show that early detectionand reordering of potentially occluded primitives reducesovershading by 20 and boosts redundant tile detection by5 yielding speedups of 39 and energy reduction of 43

II BACKGROUND

Tile-Based Rendering The Graphics Pipeline consists ofa sequence of steps required to render a scene generatedby an application Figure 1 shows the block diagram ofa hardware implementation of such pipeline based on thearchitecture of an ARM Mali-450 [2] one of the mostwidespread GPU architectures on the mobile market [3]The pipeline execution is initiated by the application whichsends API commands to the GPU to be processed TheCommand Processor receives these commands and sets theappropriate state for the Graphics Pipeline Among themstreams of vertices are sent as draw commands to be pro-cessed by the pipeline In Tile-Based Rendering (TBR) therendering process is divided into two pipelines Geometryand Raster Furthermore the screen space is partitionedinto regular independently-rendered regions named tileswhich allows for the use of smaller on-chip memories forstorage of temporary depth and color values The Geometry

Pipeline fetches vertices and their attributes (per-vertexinformation such as position color or texture coordinates)from main memory and transforms the vertices from object-space coordinates into the display-space coordinates usinguser-defined programs called vertex shaders and some fixedfunction stages of the pipeline The vertices are groupedinto primitives (usually triangles) in the Primitive Assemblystage which also discards the ones that do not face thecamera or are outside the viewing volume The GeometryPipeline finishes its process in the Polygon List Builderstage which assigns primitives to tiles by filling a memorystructure named Parameter Buffer The Parameter Buffercontains the vertex attributes of all the primitives of theframe being rendered It also stores for each tile its DisplayList a list of pointers to the attributes of the primitives thatoverlap that tile

Raster PipelineFragment ProcessorsFragment Processors

GPUcommand

GPUcommand

CommandProcessorCommandProcessor

VertexFetcherVertex

Fetcher

L2Cache

L2Cache

VertexCacheVertexCache

VertexProcessors

VertexProcessors

PrimitiveAssemblyPrimitiveAssembly

RasterizerRasterizerEarlyDepth Test

EarlyDepth Test

Z-BufferZ-Buffer

ColorBufferColorBuffer

TextureCache

TextureCache

ALU

LoadStore

ALU

Geometry Pipeline

TileCache

TileCache

Polygon ListBuilder

Polygon ListBuilder

TileScheduler

TileScheduler

Blending

TilingEngine

MemoryController

Figure 1 Assumed baseline architecture similar to an ARM Mali-450

The Raster Pipeline is triggered once all the geometry ofthe frame has been processed Tiles are processed sequen-tially by fetching their primitives from the Parameter Bufferand dispatching them to the Rasterizer which discretizesthem into fragments elements containing the informationnecessary to compute the color of a pixel Fragments thencan be queried for visibility in the Early Depth Test stagewhich discards fragments that will not contribute to thecolor of the pixel because an already-processed fragmentoccludes them The fragments passing the test proceed tothe Fragment Processors where their color is computed byuser-defined fragment shaders The output color may thenbe blended with previous computed values for that pixel (incase of transparencies) and the resulting value is stored ina local memory named Color Buffer a rectangular array ofpixel colors consisting of a red green and blue componentfor each color When all of the primitives of a tile havebeen rendered the contents of the Color Buffer are flushedto main memory

Rendering Elimination Rendering Elimination [1] is a

technique that avoids the rendering of tiles that will producethe same color across consecutive frames A signature of theprimitives of each tile is computed and compared with thesignature of the primitives the same tile had in the precedingframe If the two signatures match it is considered that theinputs for the Raster Pipeline have not changed betweenframes and therefore the output will also be the sameConsequently the tile is not rendered and the colors of itspixels are reused with the ones computed in the previousframe Figure 2 shows a block diagram of how the techniqueoperates within the Graphics Pipeline The Signature Buffer1 is an on-chip lookup table that stores for each tile

the signature of the previous frame and the in-progresssignature of the current frame Whenever a primitive reachesthe end of the Geometry Pipeline the signature of its vertexattributes is computed 2 In addition for each tile thatthe primitive overlaps the signature of the current frame forthat tile is updated by combining the temporary value storedin the Signature Buffer entry with the computed signatureof the primitive When all the frame geometry has beenprocessed the Signature Buffer holds the final signaturesfor every tile in the current frame Then whenever a tileis scheduled to be rendered its signatures for the currentand the previous frame are read from the Signature Bufferand compared to decide whether or not the tile needs to berendered 3

PolygonList

Builder

PolygonList

BuilderTile

Scheduler

TileScheduler

ParameterBuffer

ParameterBuffer

Vertex ProcessingVertex Processing

SignatureUnit

SignatureUnit

SignatureBuffer

SignatureBuffer

Fragment ProcessingFragment Processing

Geometry Pipeline Raster Pipeline

Figure 2 Rendering Elimination block diagram

Early Depth Test The Depth Test [4] is a per-fragmentoperation in which occluded fragments are discarded (donot write in the Color Buffer) To do so the depth of theclosest fragment to the camera is kept for every pixel in thescreen in a memory structure named Z Buffer After shadinga fragment and before updating the Color Buffer its depthvalue is checked against the stored value for that position inthe Z Buffer if the new fragment is closer to the camera thanthe previous one the Color Buffer and Z Buffer entries areupdated with the fragmentrsquos color and depth respectivelyOtherwise the buffers are not updated The Early DepthTest is an optimization supported by most modern GPUsin which fragments are discarded before shading them byapplying the Depth Test prior to being dispatched to theFragment Processors a fragment will be shaded only if it

passes this visibility test However not all primitives canbenefit from this optimization because some shaders have thecapability to change the visibility determined by the EarlyDepth Test The most common operations to achieve suchalterations are fragment discard (the execution of the shaderprevents a fragment from progressing into the pipeline thuscausing an incorrect early update of the Z Buffer) and depthwriting (a shader may generate a depth value which maycause a fragment considered visible to become occluded orvice versa)

Blending Transparency is often computed by combininga translucent foreground color with a background color soas to create a filter of the color of the objects behind Toachieve this blending effect an additional color componentnamed alpha expressing the degree of opacity is includedin each pixel The alpha value ranges from 1 to 0 with 1indicating that the fragment is fully opaque and 0 indicatingfull transparency Whenever the fragment shader outputs acolor for a fragment it is combined with the existing valuein the same entry of the Color Buffer in a way that dependson its alpha value To properly render transparent objectsthe value in the Color Buffer must correspond to the colorof all the objects behind the transparent fragment since theblending operation is generally not commutative Thereforethe standard method for applying transparency is to firstrender the opaque geometry (thus taking advantage of theDepth Buffer capabilities) and then render all the translucentgeometry in back-to-front order

III EARLY VISIBILITY RESOLUTION (EVR) OFOCCLUDED PRIMITIVES

Detecting occluded primitives early in the pipeline canprevent us to process them and avoid a significant amount ofineffectual work However this is a complex problem so werely on a simplification that estimates visibility with a lowimplementation cost We exploit the fact that visibility tendsto remain constant across consecutive frames if a primitiveis occluded in a frame it will most likely be occluded inthe following one

A sufficient -but not necessary- condition for a primitiveto be occluded in a tile is that the primitive is entirely locatedfarther from the viewpoint than the farthest visible point inthat tile Based on that observation we label primitives asoccluded in a tile if they are farther than the farthest visiblepoint (hereafter named FVP) for that tile in the previousframe Whenever a frame finishes rendering the visibilityof the complete scene is known so the depth of the FVPcan be extracted for each tile

Visibility is usually determined at a fragment level usingthe Early Depth Test However a large number of mobile 2Dapplications use the so-called Painterrsquos Algorithm [5] whereobjects in the scene are drawn in back-to-front order Thisway a newly-processed opaque fragment always occludespreviously-rendered fragments in the position it maps to

without the need of tracking depth information using theZ Buffer Consequently to determine the FVP for a tilewe must distinguish between primitives that write on the ZBuffer (WOZ primitives) and primitives that do not (NWOZ)

A WOZ Primitives

All information regarding the visibility for these primi-tives is available in the Z Buffer when the tile is renderedThe per-tile FVP depth is computed as the maximum depthvalue stored in the Z Buffer (Zfar) A primitive is labeledas occluded in a given tile if its closest vertex (Znear) to theviewpoint is farther than the FVPrsquos depth from the previousframe

The coarse granularity caused by comparing to a singleZfar value combined with the conservative Znear comparison(which requires that all primitive points are beyond the FVPnot just those overlapping the tile) reduces the detection ratesince not all occluded primitives might be labeled as suchHowever this way the primitives can be labeled as occludedfor a tile earlier in the pipeline with information availableat the Polygon List Builder stage (vertex depths and tilebinning of the primitive) without the need to either clipthem to the boundaries of a tile or rasterize them Note thatZfar is a single value per tile so it is stored in an on-chipmemory buffer at an acceptable energy and area overhead

B NWOZ Primitives

The visibility for these primitives is implicit in the ren-dering order and is therefore not resolved using the ZBuffer However by using a different mechanism occludedprimitives can still be detected in such scenes During thesorting of primitives into tiles we tally how many differentdraw commands have produced primitives that overlappedeach particular tile and store that number in a layer identifiercounter The layer identifier of a tile starts at zero at thebeginning of the frame and is increased by 1 whenever aprimitive that belongs to a new command is sorted to thattile

When a primitive is sorted to a tile it is assigned thecurrent layer identifier of that tile Since opaque primitivesin a layer partially or completely occlude layers laid under itwe can use those identifiers as depth information primitiveswith higher layer identifiers are closer to the observer thanprimitives with smaller ones Later on after rasterizationlayer identifiers are tracked for all the opaque visible frag-ments of a primitive in the Layer Buffer which is a localstructure akin to the Z Buffer

When a tile is completely rendered all the informationconcerning its visibility is available in the Layer Buffer Thedepth of the FVP corresponds to the minimum identifierstored in the Layer Buffer (Lfar) A primitive is labeled asoccluded in a tile if its assigned layer for the current tile issmaller than the tilersquos Lfar from the previous frame

C Hybrid Scenes

A 3D scene is mainly composed of primitives that write inthe Z Buffer but it may also include primitives that do notFor instance a batch of NWOZ primitives are sometimesdrawn at the beginning of the scene as a background or at theend as a HUD1 Besides it is common to find scenes withtraditional alpha blending where geometry is rendered intwo steps In the first one the opaque geometry is renderedIn the second step the translucent primitives are processedin back-to-front order Translucent primitives are NWOZbecause by definition they are not occluders so they mustnot update the Z Buffer

WOZ primitives are also assigned a layer identifier tohelp compare its age relative to NWOZ primitives Howeversince resolving visibility among WOZ primitives themselvesis not determined by their relative age but by comparingtheir explicit depth values we can assign the same layeridentifier to all of the WOZ primitives in a batch If twoprimitives one being a WOZ and the other being an opaqueNWOZ overlap the same pixel visibility is resolved bycomparing their relative age ie by determining which onewas rendered last

The FVP depth of a tile may be either Zfar or Lfardepending on whether the FVP belongs to a WOZ or aNWOZ primitive respectively After computing Lfar wedetermine to which type of primitive it belongs and storethe proper FVP depth value (either Zfar or Lfar) for the tileA boolean value termed FVP-type is then set to indicatewhether the stored FVP corresponds to a WOZ or a NWOZprimitive

Layer 4 3 2

z=05 z=1

1

(a) FVP-type LayerFVP depth 3

Layer 3 2 1

z=0z=05 z=1

(b) FVP-type ZFVP depth 05

Figure 3 FVP depth computation in tiles with both WOZ primitives(white) and NWOZ primitives (striped)

Figure 3 illustrates how the FVP of a tile is computedin the presence of both WOZ and NWOZ primitives Atile is viewed in a top-down perspective with the locationof its primitives represented as rectangles The observer ofthe scene placed on the left ie the right corner is fartherThe top of the figure displays the layer identifiers for allprimitives as well as the Z value for WOZ primitives

1HUD is short for Head-Up Display a visual overlay used to presentinformation to the user

In the scenario presented in Figure 3a Layer 1 is com-pletely occluded by Layer 2 whereas Layer 2 is completelyoccluded by Layers 3 and 4 Layer 3 is visible so the Lfar

of the tile is 3 Since Layer 3 belongs to NWOZ primitivesthe FVP depth of the tile is its Lfar and a correspondingFVP-type that indicates that the FVP is a layer is stored

In the scenario presented in Figure 3b Layer 1 is visibleso the Lfar of the tile is 1 Since Layer 1 belongs to WOZprimitives the FVP depth corresponds to the tilersquos ZfarPrimitives with a depth value of 1 are occluded by primitiveswith smaller depth values while primitives with a depthvalue of 0 do not completely occlude primitives with a depthvalue of 05 Thus the Zfar and consequently the FVP depthof the tile is 05 The FVP-type of the tile is set to indicatethat the FVP is a Z value A primitive is labeled as occludedif one of the following two scenarios occurs

bull The FVP in the previous frame is NWOZ and the layerassigned to the primitive is lower than Lfar

bull The primitive and the FVP in the previous frame areWOZ and the primitiversquos Znear is farther than Zfar

IV REMOVING INNEFECTUAL COMPUTATIONS WITHEVR

In this section we present two optimizations that lever-age the presented EVR mechanism for early detection ofoccluded primitives to avoid ineffectual computations andmemory accesses in the Graphics Pipeline

A Overshading Reduction

Overshading occurs when a pixel is shaded multipletimes because several primitives overlap it If an opaqueprimitive writes into an already-shaded pixel the resourcesdevoted to the previous color computation have been wastedbecause it has no effect in the final image Note that someovershading cannot be avoided such as the one producedby translucent primitives As introduced before GPUs try toreduce overshading by employing an Early Depth Test whichavoids shading a fragment if a closer opaque fragmenthas already been processed Although this mechanism caneliminate a significant fraction of overshading it is heavilydependent on the order that fragments are processed becauseit can only discard fragments which are hidden by thosealready processed A direct solution to the overshadingproblem would be for the application to sort the opaqueprimitives in a front-to-back order However many of thesesoftware-based approaches require building costly spatialhierarchical data structures to render the scene from anysingle viewpoint They are only effective on ldquowalkthroughrdquoapplications where the entire scene is static and only theviewer moves through it because the overheads can beamortized over a large number of frames Furthermore suchapplication-level sorting is often challenging due to cyclicoverlaps among objects or objects containing geometry thatoccludes parts of the same object

Some applications perform a preliminary depth pre-pass(either in hardware or in software) where some or all ofthe geometry is rendered using a simple shader that onlywrites into the Z Buffer After that the actual render pass isexecuted but now having perfect or near-perfect visibilityinformation in the Z Buffer which greatly increases thenumber of fragments discarded by the depth test Despitethe improved efficacy of the depth test the overhead ofthe additional render pass is very high and often offsets itspotential benefits

In this paper we propose to use the speculative visibilitydetermination mechanism described in Section III to dynam-ically reorder opaque primitives so as to render primitivesthat are likely to be occluded after primitives that are likelyto be visible without the need of an additional render passThe reordering is performed in the Polygon List Builderstage when primitives are sorted into tiles In the baselineconfiguration for each primitive the Parameter Buffer isupdated as follows the primitiversquos attributes are stored inmemory and a pointer to those attributes is written into theDisplay List of each tile Then whenever a tile is renderedits Display List is accessed and the pointers to primitivesare dereferenced to access their attributes to rasterize them

The proposed reordering mechanism divides the DisplayList of every tile into two lists Tiles are rendered by fetchinginitially all the primitives from the first list and then theprimitives from the second list Whenever a primitive issorted into a tile its attributes are stored into the ParameterBuffer the same way as in the baseline The pointer tothose attributes on the other hand is stored on one of thelists depending on the type of primitive and its predictedvisibility according to Algorithm 1 This algorithm only

Algorithm 1 Reordering Algorithm based on FVPif Primitive is WOZ then

if Predicted visible thenAppend into First List

elseAppend into Second List

end ifelse NWOZ Primitive

if Second List not empty thenMove Second List to the end of the First List

end ifAppend into First List

end if

reorders opaque WOZ primitives among themselves whilepreserving the order of NWOZ primitives against themselvesand against WOZ primitives Reordering WOZ primitivesdoes not incur in rendering errors NWOZ primitives arenot reordered and all WOZ primitives perform the depthtest as usual which maintains the correctness of the resultproduced by such primitives regardless of the order in which

they are rasterized

2nd Batch1st Batch 4th Batch 3rd Batch

WOZ Primitives Predicted Occluded WOZ Primitives Predicted VisibleNWOZ Primitives

(a) Primitives overlapping a tile divided into 4 batches according to theirprimitive type

1st Batch

List 1 List 2

2nd Batch

3rd Batch

4th Batch

(b) WOZ primitives that are predicted occluded are stored on the SecondList while all other primitives are stored in the First List

Figure 4 Reordering algorithm example

To illustrate Algorithm 1 let us consider Figure 4ashowing 4 different batches of primitives of a particular tileThe two WOZ batches include primitives that are predictedto be visible and primitives that are predicted to be occludedFigure 4b shows how they are reordered

The first processed batch is an NWOZ batch No actionsare performed with the second list since it is empty and allthe primitives in the batch are appended to the first list Nextthere is a WOZ batch whose primitives are appended to thefirst list if they are predicted to be visible in the tile andappended to the second list otherwise When the followingNWOZ batch arrives all the primitives in the second list aremoved to the end of the first list and then the primitives ofthe batch are appended to the first list Finally another WOZbatch is processed whose primitives are again appended tothe two lists according to their predicted visibility

This reordering technique is highly effective at reducingovershading because if the visibility prediction is correct theearly depth test is able to discard more fragments whichreduces the amount of computation and memory accessesdevoted to occluded fragments Note that this scheme doesnot introduce any error as commented above Visibilitymispredictions simply imply a loss of culling effectivenessin the Early Depth Test

B Rendering Elimination Improvement

Rendering Elimination [1] is a technique that detects tilesthat produce the same color across adjacent frames Todo so when primitives are sorted into tiles at the end ofthe Geometry Pipeline a signature per tile is incrementallycomputed on-the-fly with the attributes of all primitivesoverlapping each tile Then when the Raster Pipeline startsprocessing a tile its signature computed for the current

Table IVISIBILITY CASUISTRY

Scenario Frame i Frame i+1

A Visible VisibleB Visible OccludedC Occluded OccludedD Occluded Visible

frame is compared against the signature computed in theprevious frame if both signatures match the tile is notrendered since it will produce the same colors as in theprevious frame Rendering Elimination requires all attributesfrom all primitives of a tile to be exactly the same as inthe previous frame to detect redundancy However in thecase that only occluded primitives change their attributesthe tilersquos colors will be the same as for the precedingframe making Rendering Elimination not able to detect andeliminate such frame-to-frame redundancy In this paperwe also propose using the approximate visibility resolutionmechanism described in Section III to compute signaturesonly with visible primitives so as to improve the effective-ness of Rendering Eliminationrsquos tile redundancy detection

In the baseline operation of Rendering Elimination alookup table named Signature Buffer stores one CRC32per tile Whenever a primitive is sorted the CRC32 ofthe attributes of its vertices is computed Then for all thetiles that the primitive overlaps the corresponding SignatureBuffer entry is read and updated by combining the CRC32value of the entry with the CRC32 value of the sortedprimitive

Using the visibility prediction scheme proposed in Sec-tion III we propose to extend the Rendering Eliminationtechnique as follows For each sorted primitive its depthis compared against the depth of the FVP in the previousframe for each tile it overlaps If the primitive is predictedto be occluded in a tile the Signature Buffer entry forthat tile is not updated with the CRC32 of the primitiveAs it will be shown in the Results section utilizing theFVP depth allows for a significant increase in redundanttile detection Moreover the proposed optimization doesnot produce any rendering errors Table I presents the fourpossibilities regarding the resolved visibility of a primitive(either visible or occluded) across two consecutive frames

For scenarios A and B the optimization behaves likethe baseline Rendering Elimination since the primitive wasvisible in the tile in Frame i it is considered for the signatureof the tile in Frame i + 1 regardless of its final visibilityNote that in scenario B the primitive will be occluded andtherefore will not be considered in the signature in Framei+ 2 This is the case for scenarios C and D

Scenario C is the case that improves over the baselinesince the occluded primitive does not affect the final colorsof the tile not considering the primitive for the signature

enhances redundancy detection while not generating errorsFinally scenario D does not cause rendering errors be-

cause for a primitive P (occluded in Frame i) to be visiblein Frame i+1 at least one of the following two conditionsmust hold

i) P has moved closer to the camera than the farthestdepth of the tile in the previous frame In that case P will beadded to the signature of the tile Since it was not includedin the signature of the previous frame the signatures willdiffer and the tile will be rendered

ii) All the primitives that occluded P have moved (orare not rendered) so that in Frame i + 1 they do nottotally occlude P In that case the attributes of the occluderprimitives must have changed and the signature will bedifferent even if P is not considered for the signature thetile will be rendered

V IMPLEMENTATION

In this section we describe the extra hardware requiredto implement the proposed early visibility resolution mecha-nism which basically consists of additional units to computeand store the FVP (farthest visible point) for all the tiles inthe frame Figure 5 shows how they are integrated into aTBR GPU

PrimitiveAssembly

PrimitiveAssembly

RasterizerRasterizerFragmentProcessing

FragmentProcessing

EarlyDepth

EarlyDepth

CommandProcessor

CommandProcessor

VertexProcessing

VertexProcessing

VertexFetcher

VertexFetcher

ColorBuffer

ColorBuffer

DepthBuffer

DepthBufferTexturesTextures

Hardware

PolygonList

Builder

PolygonList

Builder

TileScheduler

TileScheduler

ParameterBuffer

ParameterBuffer

BlendingBlending

LayerBuffer

LayerBuffer

Memory New Buffer

FVPTable

FVPTable

LayerGenerator

LayerGenerator

Figure 5 Graphics Pipeline including the structures needed to implementFVP computation

A Layer Generator Table

As discussed in Section III layers are tracked to emulatedepth among NWOZ primitives Assigning a layer identifierto a primitive requires to address the following issues

First since the layer identifier is intended to count thenumber of objects (draw commands) whose primitives haveoverlapped a given tile so far each tile must have itsindependent layer counter Of course for a given tile allthe primitives of the same command are assigned the samelayer identifier although that layer may differ from one tileto another

Second since WOZ primitives update their depth into theZ Buffer layer identifiers do not provide any informationamong primitives in a WOZ batch the same identifier canbe assigned to all WOZ primitives in a batch for a giventile

We propose to employ a small on-chip LUT whichwe call Layer Generator Table in order to manage theassociation of layer identifiers to primitives This table hasone entry per tile and each entry contains three fields

1) Last identifier of a command that produced a primitivethat overlapped the tile

2) Last layer assigned to a primitive that overlapped thetile

3) Last type of primitive (WOZNWOZ) that overlappedthe tile

Using the Layer Generator Table (LGT) we can assign alayer to every primitive in all the tiles it overlaps during thePolygon List Builder stage Whenever a primitive is sortedinto a tile the LGT entry for that tile is checked If the storedcommand identifier is the same as the primitiversquos commandidentifier it means that the primitive belongs to the samelayer as the last primitive sorted into that tile Consequentlythe primitive is assigned the layer stored in the entry Aftersorting a primitive into a tile it updates the last type ofprimitive field in the LGT (a binary value NWOZ or WOZ)

On the other hand if the stored command identifieris different to the primitiversquos command the layer maybe increased depending on the type of primitive NWOZprimitives always increase the layer number whereas forWOZ primitives the layer is only increased if the previousprimitive was NWOZ Finally the LUT entry is updatedwith the new command identifier and the new layer value ifthey have changed

The layer identifier of a primitive is stored in the Param-eter Buffer as any other attribute This way layers can beassigned to all the fragments of the primitive at rasterizationtime

B Layer Buffer

The farthest visible layer of a tile can be obtained bycomputing the minimum visible layer of all its pixels Sincetiles are relatively small (eg 16x16 pixels) we can use anon-chip buffer to keep track of per-pixel information for anentire tile This buffer which we call the Layer Buffer hasone entry for every pixel of the tile being rendered (just asthe Z Buffer or the Color Buffer) that stores the visible layerfor that pixel

The Layer Buffer is updated during the Blending stagewhen the final fragment opacity is already determined Todetect opacity we use the same alpha value that fragmentsemploy to blend with colors previously written in the ColorBuffer If the alpha factor is exactly 1 the fragment is opaqueand its layer is written into the Layer Buffer Otherwise

since the fragment is translucent and does not completelyocclude layers behind it the Layer Buffer is not updated

During the blending stage each fragment of a WOZprimitive stores its layer identifier in a register named ZR sothat it identifies the layer of the last visible WOZ primitiveand may be used to distinguish at the end of rendering atile if its FVP corresponds to a WOZ or a NWOZ primitiveie the FVP-type of the tile The value of ZR is comparedto Lfar when the tile finishes rendering if the two valuesare equal the FVP-type of the tile is WOZ Otherwise it isNWOZ

C FVP Table

In order to predict if a primitive is likely to be visible ina tile we use the tilersquos FVP depth of the previous frame sothe entire set of per-tile FVP depths must be stored Suchinformation is maintained in a structure that we call FVPTable The FVP Table has one entry per tile with eachentry containing the previous framersquos FVP depth for that tileEach entry in the table also stores the FVP-type to indicatewhether the type of data stored is a Z or a layer identifier

Whenever a tile finishes rendering its FVP-type is de-termined If the FVP depth belongs to a NWOZ primitivethe FVP Table entry for the tile is updated with Lfar settingits FVP-type bit Otherwise the FPV entry for the tile isupdated with Zfar and the entryrsquos FVP-type bit is cleared

VI EVALUATION METHODOLOGY

A Simulator infrastructure

We employ the Teapot simulation framework [6] to eval-uate our proposal Teapot runs unmodified Android appli-cations for mobile platforms and obtains GPU performanceand energy consumption statistics Table II lists the parame-ters used in the simulations in order to model an architectureresembling the ARM Mali-450 GPU [2] the most widelyused GPU architecture nowadays with almost 20 of themobile GPU market [3]

The traces that feed the Teapot cycle-accurate simulatorare obtained via a two-step process First an Android appli-cation is run in the Android emulator [7] and every OpenGLcommand sent to the GPU is intercepted and stored in a fileSecond those OpenGL commands are fed to the softwarerenderer included in Gallium3D [8] which is instrumentedto generate a trace containing all the information neededto guide the cycle accurate execution such as vertex datashader instructions or memory addresses of the differentstages of the Graphics Pipeline For each application wesimulate 60 consecutive frames from the original applicationrun

McPAT [9] is used to estimate the energy consumptionof the GPU All the additional hardware required for theproposed technique (Layer Generator Table FVT tableLayer Buffer comparators and registers) is modelled usingMcPATrsquos components (SRAMs Registers MUXes XORs)

Table IIGPU SIMULATION PARAMETERS

Baseline GPU Parameters

Tech Specs 400 MHz 1 V 32 nmScreen Resolution 1196x768Tile Size 16x16 pixels

Main Memory

Latency 50-100 cyclesBandwidth 4 Bcycle (dual channel LPDDR3)Size 1 GB

Queues

Vertex (2x) 16 entries 136 bytesentryTriangle Tile 16 entries 388 bytesentryFragment 64 entries 233 bytesentry

Caches

Vertex Cache 64 bytesline 2-way associative4 KB 1 bank 1 cycle

Texture Caches (4x) 64 bytesline 2-way associative8 KB 1 bank 1 cycle

Tile Cache 64 bytesline 8-way associative128 KB 8 banks 1 cycle

L2 Cache 64 bytesline 8-way associative256 KB 8 banks 2 cycles

Color Buffer 64 bytesline 1-way associative1 KB 1 bank 1 cycle

Depth Buffer 64 bytesline 1-way associative1 KB 1 bank 1 cycle

Non-programmable stages

Primitive assembly 1 trianglecycleRasterizer 16 attributescycleEarly Z test 32 in-flight quad-fragments 1 Depth Buffer

Programmable stages

Vertex Processor 1 vertex processorFragment Processor 4 fragment processors

Additional hardware

Layer Generator Table 3600 entries 3 bytesentryFVP Table 3600 entries 4 bytesentryLayer Buffer 64 bytesline 1-way associative

1 KB 1 bank 1 cycle

Regarding system memory Teapot employs DRAMSim2[10]

B Benchmarks

Table III presents the benchmarks employed to test theproposed approach which correspond to twenty unmodifiedAndroid graphics applications All of these applicationshave millions of downloads according to Google Play [11]with some of them surpassing 500 million downloads Theset of benchmarks includes games of the most populargenres in the mobile segment [12] such as puzzle arcadeand simulation The benchmarks also contain a variety ofworkloads completely 2D scenes such as cde or wmwscenes with simple 3D models such as ata or tib) and

scenes with more sophisticated models such as 300 or mstApplications classified as 3D contain both WOZ and NWOZprimitives while applications classified as 2D only containNWOZ primitives

Table IIIBENCHMARK SUITE

Benchmark Alias Genre Type

300 Seize your glory 300 Action 3DAir Attack ata Arcade 3DCrazy Snowboard csn Arcade 3DModern Strike mst First Person Shooter 3DTemple Run ter Platform 3DTigerball tib Physics Puzzle 3DAngry Birds abi Puzzle 2DArmymen arm Strategy 2DAvenger Legends ale Strategy 2DCandy Crush Saga ccs Puzzle 2DCastle Defense cde Tower Defense 2DClash of Clans coc MMO Strategy 2DCut the Rope ctr Puzzle 2DDude Perfect dpe Puzzle 2DHayday hay Simulation 2DHopeless hop Action Survival 2DMagic Touch mto Arcade 2DRedsun red Strategy 2DWherersquos my water wmw Puzzle 2DWorld of goo wog Physics Puzzle 2D

VII EXPERIMENTAL RESULTS

Figure 6 shows the energy consumption of the GPU-Memory system normalized to the Baseline GPU for our setof benchmarks The proposed optimizations that leverage anearly prediction of the visibility achieve a 43 reduction ofenergy consumption on average Energy savings are obtainedin all benchmarks with maximums of more than 80(cde dpe) Figure 7 shows the execution time divided intoGeometry and Raster pipelines normalized to the baselineOn average the proposed techniques achieve 39 executiontime reduction with maximums of more than 70 (ccs cdedpe)

057

01

02

03

04

05

06

07

08

09

1

No

rmal

ize

d e

ne

rgy

con

sum

pti

on

Overhead by additional accesses Overhead by additional hardware

Figure 6 Energy consumption of our EVR proposal normalized to theBaseline GPU

The energy overheads are mainly due to additional writesto the Parameter Buffer to store the layer identifiers Thisoverhead is quite moderate 21 on average as it can be

061

0

01

02

03

04

05

06

07

08

09

1

No

rmal

ize

d e

xecu

tio

n t

ime

Geometry Geometry overhead Raster

Figure 7 Execution time of our EVR proposal normalized to the BaselineGPU

seen in Figure 6 Figure 6 also illustrates that the addi-tional hardware added by the proposed mechanism incursin only 12 energy consumption overhead on average thestructures needed to manage the FVP information (LayerGenerator Table Layer Buffer and FVP Table) generate05 additional static and dynamic energy consumptionwhile the LUTs needed to implement Rendering Elimina-tion contribute to an additional 07 energy consumptionThe computation of Rendering Eliminationrsquos tile signaturesincurs in time overhead in the Geometry Pipeline whenevera primitive overlaps a large number of tiles since thepipeline is stalled waiting for all signatures to be sequentiallyupdated Figure 7 reports such overheads in execution timewhich on average represents 05 of the total

300 ata csn mst ter tib Average

0

1

2

3

4

5

6

Shad

ed

fra

gme

nts

pe

r p

ixe

l

Baseline EVR Oracle

Figure 8 Comparison of the number of shaded fragments per pixel amongthe baseline GPU our EVR proposal and an oracle

These important reductions in energy consumption andexecution time are mainly produced by avoiding the process-ing of ineffectual fragments (fragments that are occluded orare the same as in the previous frame) Figure 8 shows thenumber of fragments shaded per pixel using the proposedearly visibility resolution mechanism to reorder primitives(EVR) compared to the baseline for our set of 3D bench-marks We also compare our scheme with an oracle approach(which ideally assumes that the Z Buffer is initialized withthe final visibility of the tile ndashthe final depth valuesndash beforeit is executed) EVR significantly reduces (20) the numberof vainly shaded fragments and its results are close to thoseobtained by an oracle approach EVR cannot reach the oraclebecause of its approximate nature First it uses visibilityinformation of the previous frame which may have changed

Second it estimates visibility at a primitive-level while theoracle resolves visibility at the finest possible granularityfragment level

Moreover a large fraction of tiles are detected to beredundant and its execution is completely bypassed avoidingnot only the Fragment Shader stage for all their fragmentsbut also the rest of the stages of the Raster Pipeline forthose tiles Figure 9 shows the percentage of detectedredundant tiles ndashproducing the same colors as the previousframendash for our set of benchmarks Results are shown for thebaseline Rendering Elimination (RE) the proposed EVR-aided Rendering Elimination (EVR) and an oracle setup thatcan perfectly identify all tiles of a frame that are equal tothose of the previous frame

0

10

20

30

40

50

60

70

80

90

100

Det

ect

ed

eq

ual

tile

s

EVR RE Oracle

Figure 9 Percentage of detected equal tiles by EVR compared to REand an oracle

On average EVR avoids the rendering of 54 of the tilesreducing 5 more tiles than the baseline RE Predicting oc-cluded primitives and not adding them to the tilersquos signatureallows the detection of equal tiles in benchmarks in whichRE was hardly effective such as 300 or mst The majorityof these tiles that are identified as redundant corresponds toportions of the screen in which WOZ primitives are coveredby NWOZ primitives in the form of a HUD In most casesthe scene contains objects that are in motion but completelyoccluded by NWOZ geometry The layer-based visibilityscheme allows EVR to identify additional redundant tilesin benchmarks with a high degree of redundancy detectedby RE such as cde or mto In some applications such as hayor wmw the additional tiles eliminated exceeds 10 witha maximum of 30

The additional redundant tiles detected results in anaverage 10 reduction of energy consumption comparedto the baseline RE as presented in Figure 10 The earlyvisibility resolution incurs in some overheads which aregrouped together in the figure In the Geometry Pipeline theLayer Generator and FVP tables are accessed to generate alayer identifier which is stored in the Parameter Buffer Inthe Raster Pipeline the layer identifiers are read and writteninto the Layer Buffer When a tile finishes its rendering itsFVP is computed by accessing the Z and Layer Buffers andthe result is stored in the FVP Table Although the required

09

02

03

04

05

06

07

08

09

1

Ener

gy c

on

sum

pti

on

no

rmal

ized

to

RE

Overhead by FVP Computation

Figure 10 Energy consumption of our EVR proposal normalized to RE

sequential check of the two tables for each primitive andeach tile to which it is mapped could incur in some timeoverhead it is more than offset by the reduction in numberof primitives that can skip the signature computation stepsince they are occluded This is shown in Figure 11 whichcompares execution time broken down into Geometry andRaster Pipelines for the Baseline GPU RE and our proposedEVR approach for early visibility resolution Note that REhas to read the temporary hashes held in the Signature Bufferfor all the tiles that a primitive overlaps shift them as manybytes as the size of the primitive and finally combine themwith the hash of the primitive to produce a new signature forthe tile This process is avoided in our scheme if a primitiveis determined to be occluded in a tile since EVR marks it notto be included into the tilersquos signature The only exceptionwhere our EVR scheme does not reduce Geometry cycles ishop a benchmark that has very few primitives concentratedin a reduced amount of tiles Consequently the averagenumber of primitives to combine into the signature of a tile issmall limiting the benefits of occluded primitive detectionOn average our EVR mechanism reduces the execution timein the Geometry Pipeline by 4 with respect to RE

Moreover Rendering Elimination may induce time andenergy overheads in benchmarks where not enough redun-dant tiles are detected to offset the signature computationsuch as 300 or mst On the other hand our scheme is moreeffective at detecting redundant tiles and for non-redundanttiles specially in 3D benchmarks the primitive reordering in-creases the efficiency of the Early Depth Test which reducesthe amount of computations in the fragment processors Thisresults in overall speedups for all benchmarks

VIII RELATED WORK

Occlusion culling is a fundamental problem in computergraphics with an extensive literature spanning more thanthree decades In this section we focus on the most influ-ential works and the ones most related to our proposal

The Z Buffer [4] is the de facto standard to resolvevisibility due to its effectiveness and low implementationcost The Hierarchical Z Buffer [13] is a variation of thebaseline technique in which a depth pyramid is used to testvisibility The base level of the pyramid is the Z Buffer

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

300 ata csn mst ter tib abi arm ale ccs cde coc ctr dpe hay hop mto red wmw wog AVG

0

02

04

06

08

1

No

rmal

ize

d e

xecu

tio

n t

ime

Geometry Raster

Figure 11 Execution time comparison of our EVR proposal and RE against the baseline GPU

and higher levels are constructed by combining the depthof four pixels at the next lower level typically by choosingthe farthest one Entire primitives can be discarded withoutaccessing the Z Buffer by comparing their nearest depthagainst the values in higher levels in the pyramid OurEVR proposal also compares the depth of primitives toa FVP depth which would correspond to the top of thepyramid of the Hierarchical Z Buffer However the FVPdepth contains final visibility information which allowsunlike the Z pyramid to detect primitives that will beoccluded by others processed later Moreover the FVP depthincludes more information than just the top of the Z pyramidallowing the detection of occluded NWOZ primitives that donot use the Z buffer

Z-Prepass [14] draws the scene in two steps first thegeometry is rendered using simple fragment shaders onlyto quickly fill the Z Buffer Later the geometry is renderedagain with proper shaders but now with perfect visibilityinformation in-place so that all occluded fragments can bediscarded This additional render pass incurs in significantoverheads which may not always be offset by the increase inthe fragments discarded in the Early Depth Test By workingat a coarser granularity (primitive instead of fragment) EVRdoes not need to perform the pre-pass but still achievesresults comparable to having complete visibility information

The concept of layers has been previously adopted inthe context of occlusion culling most notably in DepthPeeling [15] an algorithm that renders geometry multipletimes peeling off the surface layer at each pixel in eachpass Recently Andersson et al [16] leveraged a two-layer representation of depths to avoid bandwidth spent inupdating the Hierarchical Z Buffer while in the work ofScheckel and Kolb [17] layers are used in combinationwith the alpha parameter to completely cull transparentfragments Unlike EVR these approaches cannot combinevisibility information of both WOZ and NWOZ primitivesfor a better visibility determination

Computing visibility at a fragment level (known as image-precision [18]) is useful to solve certain problems suchas circular dependencies However resolving visibility ata coarser grain could reduce the number of computations

needed Hardware occlusion queries [19] are a feature thatallow the user to query simple geometry (such as thebounding volumes) against the current contents of the ZBuffer The query counts the number of fragments thatpass the Z Test and the result allows the application toavoid rendering entire objects at the expense of CPU-GPUsynchronization Furthermore as with the Early Depth Testin order for occlusion queries to perform well both objectsand queries must be sent in front-to-back order EVR istransparent to the application in both axis it does not requireneither synchronization nor ordering

Multiple works reduce overshading by means of reorder-ing the primitives that make up a scene Govindaraju et al[20] propose an algorithm to sort non-overlapping objectsin either front-to-back or back-to front order from a givenviewpoint In the work of Chen et al [21] static objectsare preprocessed in order to create a depth-sorted list ofprimitives for every possible viewpoint The approach ofHan and Sander [22] also preprocesses objects to createseveral sorted lists that are indexed at runtime to ensureoptimal order but they consider movement by taking intoaccount not only viewpoints but also several key framesWeber and Stamminger [23] use a graph representationof dependencies in animated scenes with a fixed camerato sort primitives accordingly and leverage frame-to-framecoherence to merge different graphs and keep the overallstructure manageable VRO [24] also takes advantage oftemporal coherence to reorder objects entirely in hardwareand reduce overshading Unlike these approaches EVR isapplied at a finer granularity (primitive instead of object)does not need to perform any preprocess and can also beemployed in interactive scenes not just animated ones

IX CONCLUSIONS

We have presented a mechanism to determine visibilityin early stages of the Graphics Pipeline based on exploitingframe coherence Since consecutive frames tend to be verysimilar we use the information of a frame to estimate thevisibility for the following one

The proposed technique collects the depth of the farthestvisible primitive of every tile whenever its rendering processis complete For each overlapped tile the depth of a primitive

is compared against the depth stored for that tile in thepreceding frame If it is farther the primitive is occluded

This paper demonstrates the benefits of early visibilityprediction to remove ineffectual computations by increasingthe effectiveness of the Early Z Test a commonly usedtechnique in contemporary GPUs and Rendering Elimina-tion a recently proposed technique to exploit redundantcomputations The former works at pixel granularity and thelatter works at tile granularity

Using the predicted visibility information opaque prim-itives whose visibility is resolved using the Z Buffer arereordered such that primitives predicted as visible are ren-dered first which avoids the shading of occluded fragmentsBesides primitives predicted to be occluded are not con-sidered when generating the signature used by RenderingElimination to identify tiles that are equal to the ones in theprevious frame That increases the number of tiles that areidentified as redundant and consequently whose renderingcan be avoided

Our technique provides average speedups of 39 andenergy savings of 43 for a set of commercial Android ap-plications The reorder mechanism achieves overshading re-ductions comparable to having a Z Buffer filled with perfectvisibility information without requiring any additional renderpass to compute depths On the other hand by improvingthe tile redundancy detection of Rendering Elimination theraster pipeline of the GPU skips the rendering of more thanhalf of the tiles on average

X ACKNOWLEDGEMENTS

This work has been partially supported by the Span-ish State Research Agency under grant TIN2016-75344-R (AEIFEDER EU) and by the Generalitat de Catalunyaunder the AGAUR-FI program

REFERENCES

[1] M Anglada E de Lucas J-M Parcerisa J L AragonP Marcuello and A Gonzalez ldquoRendering elimination Earlydiscard of redundant tiles in the graphics pipelinerdquo in Pro-ceedings of the 25th IEEE International Symposium on High-Performance Computer Architecture IEEE 2019

[2] ldquoArm mali-450 gpurdquo httpsdeveloperarmcomproductsgraphics-and-multimediamali-gpusmali-450-gpu accessedDecember 10 2018

[3] ldquoHardware gpu marketrdquo httphwstatsunity3dcommobilegpuhtml accessed December 10 2018

[4] E Catmull ldquoA subdivision algorithm for computer display ofcurved surfacesrdquo tech rep Utah University Salt Lake CitySchool of Computing 1974

[5] ldquoPainterrsquos algorithmrdquo httpswwwsiggraphorgeducationmaterialsHyperGraphscanlinevisibilitypainterhtmaccessed December 10 2018

[6] J-M Arnau J-M Parcerisa and P Xekalakis ldquoTeapot atoolset for evaluating performance power and image qualityon mobile graphics systemsrdquo in Proceedings of the 27thInternational ACM Conference on Supercomputing pp 37ndash46 ACM 2013

[7] ldquoAndroid studiordquo httpsdeveloperandroidcomstudioindexhtml accessed December 10 2018

[8] ldquoGallium3drdquo httpswwwfreedesktoporgwikiSoftwaregallium accessed December 10 2018

[9] S Li J H Ahn R D Strong J B Brockman D M Tullsenand N P Jouppi ldquoMcPAT An Integrated Power Area andTiming Modeling Framework for Multicore and ManycoreArchitecturesrdquo in Proceedings of the 42nd Annual IEEEACMInternational Symposium on Microarchitecture pp 469ndash4802009

[10] P Rosenfeld E Cooper-Balis and B Jacob ldquoDramsim2 Acycle accurate memory system simulatorrdquo IEEE ComputerArchitecture Letters vol 10 no 1 pp 16ndash19 2011

[11] ldquoGoogle playrdquo httpsplaygooglecom accessed December10 2018

[12] ldquoMobile game statisticsrdquo httpsmediumcomsm appintelnew-mobile-game-statistics-every-game-publisher-should-know-in-2016-f1f8eef64f66 accessed December 102018

[13] N Greene M Kass and G Miller ldquoHierarchical z-buffervisibilityrdquo in Proceedings of the 20th Annual Conference onComputer Graphics and Interactive Techniques pp 231ndash238ACM 1993

[14] ldquoEarly z rejectionrdquo httpssoftwareintelcomen-usarticlesearly-z-rejection-sample accessed December 10 2018

[15] C Everitt ldquoInteractive order-independent transparencyrdquoWhite paper NVIDIA vol 2 no 6 p 7 2001

[16] M Andersson J Hasselgren and T Akenine-MollerldquoMasked depth culling for graphics hardwarerdquo ACM Trans-actions on Graphics vol 34 no 6 p 188 2015

[17] S Scheckel and A Kolb ldquoMin-max mipmaps for efficient2d occlusion cullingrdquo in Conference on Computer GraphicsVisualization and Computer Vision 2016

[18] I E Sutherland R F Sproull and R A SchumackerldquoA characterization of ten hidden-surface algorithmsrdquo ACMComputing Surveys vol 6 no 1 pp 1ndash55 1974

[19] O Mattausch J Bittner and M Wimmer ldquoChc++ Coherenthierarchical culling revisitedrdquo in Computer Graphics Forumvol 27 pp 221ndash230 Wiley Online Library 2008

[20] N K Govindaraju M Henson M C Lin and D ManochaldquoInteractive visibility ordering and transparency computationsamong geometric primitives in complex environmentsrdquo inProceedings of the 2005 Symposium on Interactive 3D Graph-ics and Games pp 49ndash56 ACM 2005

[21] G Chen P V Sander D Nehab L Yang and L Hu ldquoDepth-presorted triangle listsrdquo ACM Transactions on Graphicsvol 31 no 6 p 160 2012

[22] S Han and P V Sander ldquoTriangle reordering for reducedoverdraw in animated scenesrdquo in Proceedings of the 20thACM SIGGRAPH Symposium on Interactive 3D Graphics andGames pp 23ndash27 ACM 2016

[23] C Weber and M Stamminger ldquoTopological triangle sortingfor predefined camera pathsrdquo in Proceedings of the Confer-ence on Vision Modeling and Visualization pp 153ndash160Eurographics Association 2016

[24] E De Lucas P Marcuello J-M Parcerisa and A GonzalezldquoVisibility rendering order Improving energy efficiency onmobile gpus through frame coherencerdquo IEEE Transactionson Parallel and Distributed Systems 2018

technique that avoids the rendering of tiles that will producethe same color across consecutive frames A signature of theprimitives of each tile is computed and compared with thesignature of the primitives the same tile had in the precedingframe If the two signatures match it is considered that theinputs for the Raster Pipeline have not changed betweenframes and therefore the output will also be the sameConsequently the tile is not rendered and the colors of itspixels are reused with the ones computed in the previousframe Figure 2 shows a block diagram of how the techniqueoperates within the Graphics Pipeline The Signature Buffer1 is an on-chip lookup table that stores for each tile

the signature of the previous frame and the in-progresssignature of the current frame Whenever a primitive reachesthe end of the Geometry Pipeline the signature of its vertexattributes is computed 2 In addition for each tile thatthe primitive overlaps the signature of the current frame forthat tile is updated by combining the temporary value storedin the Signature Buffer entry with the computed signatureof the primitive When all the frame geometry has beenprocessed the Signature Buffer holds the final signaturesfor every tile in the current frame Then whenever a tileis scheduled to be rendered its signatures for the currentand the previous frame are read from the Signature Bufferand compared to decide whether or not the tile needs to berendered 3

PolygonList

Builder

PolygonList

BuilderTile

Scheduler

TileScheduler

ParameterBuffer

ParameterBuffer

Vertex ProcessingVertex Processing

SignatureUnit

SignatureUnit

SignatureBuffer

SignatureBuffer

Fragment ProcessingFragment Processing

Geometry Pipeline Raster Pipeline

Figure 2 Rendering Elimination block diagram

Early Depth Test The Depth Test [4] is a per-fragmentoperation in which occluded fragments are discarded (donot write in the Color Buffer) To do so the depth of theclosest fragment to the camera is kept for every pixel in thescreen in a memory structure named Z Buffer After shadinga fragment and before updating the Color Buffer its depthvalue is checked against the stored value for that position inthe Z Buffer if the new fragment is closer to the camera thanthe previous one the Color Buffer and Z Buffer entries areupdated with the fragmentrsquos color and depth respectivelyOtherwise the buffers are not updated The Early DepthTest is an optimization supported by most modern GPUsin which fragments are discarded before shading them byapplying the Depth Test prior to being dispatched to theFragment Processors a fragment will be shaded only if it

passes this visibility test However not all primitives canbenefit from this optimization because some shaders have thecapability to change the visibility determined by the EarlyDepth Test The most common operations to achieve suchalterations are fragment discard (the execution of the shaderprevents a fragment from progressing into the pipeline thuscausing an incorrect early update of the Z Buffer) and depthwriting (a shader may generate a depth value which maycause a fragment considered visible to become occluded orvice versa)

Blending Transparency is often computed by combininga translucent foreground color with a background color soas to create a filter of the color of the objects behind Toachieve this blending effect an additional color componentnamed alpha expressing the degree of opacity is includedin each pixel The alpha value ranges from 1 to 0 with 1indicating that the fragment is fully opaque and 0 indicatingfull transparency Whenever the fragment shader outputs acolor for a fragment it is combined with the existing valuein the same entry of the Color Buffer in a way that dependson its alpha value To properly render transparent objectsthe value in the Color Buffer must correspond to the colorof all the objects behind the transparent fragment since theblending operation is generally not commutative Thereforethe standard method for applying transparency is to firstrender the opaque geometry (thus taking advantage of theDepth Buffer capabilities) and then render all the translucentgeometry in back-to-front order

III EARLY VISIBILITY RESOLUTION (EVR) OFOCCLUDED PRIMITIVES

Detecting occluded primitives early in the pipeline canprevent us to process them and avoid a significant amount ofineffectual work However this is a complex problem so werely on a simplification that estimates visibility with a lowimplementation cost We exploit the fact that visibility tendsto remain constant across consecutive frames if a primitiveis occluded in a frame it will most likely be occluded inthe following one

A sufficient -but not necessary- condition for a primitiveto be occluded in a tile is that the primitive is entirely locatedfarther from the viewpoint than the farthest visible point inthat tile Based on that observation we label primitives asoccluded in a tile if they are farther than the farthest visiblepoint (hereafter named FVP) for that tile in the previousframe Whenever a frame finishes rendering the visibilityof the complete scene is known so the depth of the FVPcan be extracted for each tile

Visibility is usually determined at a fragment level usingthe Early Depth Test However a large number of mobile 2Dapplications use the so-called Painterrsquos Algorithm [5] whereobjects in the scene are drawn in back-to-front order Thisway a newly-processed opaque fragment always occludespreviously-rendered fragments in the position it maps to

without the need of tracking depth information using theZ Buffer Consequently to determine the FVP for a tilewe must distinguish between primitives that write on the ZBuffer (WOZ primitives) and primitives that do not (NWOZ)

A WOZ Primitives

All information regarding the visibility for these primi-tives is available in the Z Buffer when the tile is renderedThe per-tile FVP depth is computed as the maximum depthvalue stored in the Z Buffer (Zfar) A primitive is labeledas occluded in a given tile if its closest vertex (Znear) to theviewpoint is farther than the FVPrsquos depth from the previousframe

The coarse granularity caused by comparing to a singleZfar value combined with the conservative Znear comparison(which requires that all primitive points are beyond the FVPnot just those overlapping the tile) reduces the detection ratesince not all occluded primitives might be labeled as suchHowever this way the primitives can be labeled as occludedfor a tile earlier in the pipeline with information availableat the Polygon List Builder stage (vertex depths and tilebinning of the primitive) without the need to either clipthem to the boundaries of a tile or rasterize them Note thatZfar is a single value per tile so it is stored in an on-chipmemory buffer at an acceptable energy and area overhead

B NWOZ Primitives

The visibility for these primitives is implicit in the ren-dering order and is therefore not resolved using the ZBuffer However by using a different mechanism occludedprimitives can still be detected in such scenes During thesorting of primitives into tiles we tally how many differentdraw commands have produced primitives that overlappedeach particular tile and store that number in a layer identifiercounter The layer identifier of a tile starts at zero at thebeginning of the frame and is increased by 1 whenever aprimitive that belongs to a new command is sorted to thattile

When a primitive is sorted to a tile it is assigned thecurrent layer identifier of that tile Since opaque primitivesin a layer partially or completely occlude layers laid under itwe can use those identifiers as depth information primitiveswith higher layer identifiers are closer to the observer thanprimitives with smaller ones Later on after rasterizationlayer identifiers are tracked for all the opaque visible frag-ments of a primitive in the Layer Buffer which is a localstructure akin to the Z Buffer

When a tile is completely rendered all the informationconcerning its visibility is available in the Layer Buffer Thedepth of the FVP corresponds to the minimum identifierstored in the Layer Buffer (Lfar) A primitive is labeled asoccluded in a tile if its assigned layer for the current tile issmaller than the tilersquos Lfar from the previous frame

C Hybrid Scenes

A 3D scene is mainly composed of primitives that write inthe Z Buffer but it may also include primitives that do notFor instance a batch of NWOZ primitives are sometimesdrawn at the beginning of the scene as a background or at theend as a HUD1 Besides it is common to find scenes withtraditional alpha blending where geometry is rendered intwo steps In the first one the opaque geometry is renderedIn the second step the translucent primitives are processedin back-to-front order Translucent primitives are NWOZbecause by definition they are not occluders so they mustnot update the Z Buffer

WOZ primitives are also assigned a layer identifier tohelp compare its age relative to NWOZ primitives Howeversince resolving visibility among WOZ primitives themselvesis not determined by their relative age but by comparingtheir explicit depth values we can assign the same layeridentifier to all of the WOZ primitives in a batch If twoprimitives one being a WOZ and the other being an opaqueNWOZ overlap the same pixel visibility is resolved bycomparing their relative age ie by determining which onewas rendered last

The FVP depth of a tile may be either Zfar or Lfardepending on whether the FVP belongs to a WOZ or aNWOZ primitive respectively After computing Lfar wedetermine to which type of primitive it belongs and storethe proper FVP depth value (either Zfar or Lfar) for the tileA boolean value termed FVP-type is then set to indicatewhether the stored FVP corresponds to a WOZ or a NWOZprimitive

Layer 4 3 2

z=05 z=1

1

(a) FVP-type LayerFVP depth 3

Layer 3 2 1

z=0z=05 z=1

(b) FVP-type ZFVP depth 05

Figure 3 FVP depth computation in tiles with both WOZ primitives(white) and NWOZ primitives (striped)

Figure 3 illustrates how the FVP of a tile is computedin the presence of both WOZ and NWOZ primitives Atile is viewed in a top-down perspective with the locationof its primitives represented as rectangles The observer ofthe scene placed on the left ie the right corner is fartherThe top of the figure displays the layer identifiers for allprimitives as well as the Z value for WOZ primitives

1HUD is short for Head-Up Display a visual overlay used to presentinformation to the user

In the scenario presented in Figure 3a Layer 1 is com-pletely occluded by Layer 2 whereas Layer 2 is completelyoccluded by Layers 3 and 4 Layer 3 is visible so the Lfar

of the tile is 3 Since Layer 3 belongs to NWOZ primitivesthe FVP depth of the tile is its Lfar and a correspondingFVP-type that indicates that the FVP is a layer is stored

In the scenario presented in Figure 3b Layer 1 is visibleso the Lfar of the tile is 1 Since Layer 1 belongs to WOZprimitives the FVP depth corresponds to the tilersquos ZfarPrimitives with a depth value of 1 are occluded by primitiveswith smaller depth values while primitives with a depthvalue of 0 do not completely occlude primitives with a depthvalue of 05 Thus the Zfar and consequently the FVP depthof the tile is 05 The FVP-type of the tile is set to indicatethat the FVP is a Z value A primitive is labeled as occludedif one of the following two scenarios occurs

bull The FVP in the previous frame is NWOZ and the layerassigned to the primitive is lower than Lfar

bull The primitive and the FVP in the previous frame areWOZ and the primitiversquos Znear is farther than Zfar

IV REMOVING INNEFECTUAL COMPUTATIONS WITHEVR

In this section we present two optimizations that lever-age the presented EVR mechanism for early detection ofoccluded primitives to avoid ineffectual computations andmemory accesses in the Graphics Pipeline

A Overshading Reduction

Overshading occurs when a pixel is shaded multipletimes because several primitives overlap it If an opaqueprimitive writes into an already-shaded pixel the resourcesdevoted to the previous color computation have been wastedbecause it has no effect in the final image Note that someovershading cannot be avoided such as the one producedby translucent primitives As introduced before GPUs try toreduce overshading by employing an Early Depth Test whichavoids shading a fragment if a closer opaque fragmenthas already been processed Although this mechanism caneliminate a significant fraction of overshading it is heavilydependent on the order that fragments are processed becauseit can only discard fragments which are hidden by thosealready processed A direct solution to the overshadingproblem would be for the application to sort the opaqueprimitives in a front-to-back order However many of thesesoftware-based approaches require building costly spatialhierarchical data structures to render the scene from anysingle viewpoint They are only effective on ldquowalkthroughrdquoapplications where the entire scene is static and only theviewer moves through it because the overheads can beamortized over a large number of frames Furthermore suchapplication-level sorting is often challenging due to cyclicoverlaps among objects or objects containing geometry thatoccludes parts of the same object

Some applications perform a preliminary depth pre-pass(either in hardware or in software) where some or all ofthe geometry is rendered using a simple shader that onlywrites into the Z Buffer After that the actual render pass isexecuted but now having perfect or near-perfect visibilityinformation in the Z Buffer which greatly increases thenumber of fragments discarded by the depth test Despitethe improved efficacy of the depth test the overhead ofthe additional render pass is very high and often offsets itspotential benefits

In this paper we propose to use the speculative visibilitydetermination mechanism described in Section III to dynam-ically reorder opaque primitives so as to render primitivesthat are likely to be occluded after primitives that are likelyto be visible without the need of an additional render passThe reordering is performed in the Polygon List Builderstage when primitives are sorted into tiles In the baselineconfiguration for each primitive the Parameter Buffer isupdated as follows the primitiversquos attributes are stored inmemory and a pointer to those attributes is written into theDisplay List of each tile Then whenever a tile is renderedits Display List is accessed and the pointers to primitivesare dereferenced to access their attributes to rasterize them

The proposed reordering mechanism divides the DisplayList of every tile into two lists Tiles are rendered by fetchinginitially all the primitives from the first list and then theprimitives from the second list Whenever a primitive issorted into a tile its attributes are stored into the ParameterBuffer the same way as in the baseline The pointer tothose attributes on the other hand is stored on one of thelists depending on the type of primitive and its predictedvisibility according to Algorithm 1 This algorithm only

Algorithm 1 Reordering Algorithm based on FVPif Primitive is WOZ then

if Predicted visible thenAppend into First List

elseAppend into Second List

end ifelse NWOZ Primitive

if Second List not empty thenMove Second List to the end of the First List

end ifAppend into First List

end if

reorders opaque WOZ primitives among themselves whilepreserving the order of NWOZ primitives against themselvesand against WOZ primitives Reordering WOZ primitivesdoes not incur in rendering errors NWOZ primitives arenot reordered and all WOZ primitives perform the depthtest as usual which maintains the correctness of the resultproduced by such primitives regardless of the order in which

they are rasterized

2nd Batch1st Batch 4th Batch 3rd Batch

WOZ Primitives Predicted Occluded WOZ Primitives Predicted VisibleNWOZ Primitives

(a) Primitives overlapping a tile divided into 4 batches according to theirprimitive type

1st Batch

List 1 List 2

2nd Batch

3rd Batch

4th Batch

(b) WOZ primitives that are predicted occluded are stored on the SecondList while all other primitives are stored in the First List

Figure 4 Reordering algorithm example

To illustrate Algorithm 1 let us consider Figure 4ashowing 4 different batches of primitives of a particular tileThe two WOZ batches include primitives that are predictedto be visible and primitives that are predicted to be occludedFigure 4b shows how they are reordered

The first processed batch is an NWOZ batch No actionsare performed with the second list since it is empty and allthe primitives in the batch are appended to the first list Nextthere is a WOZ batch whose primitives are appended to thefirst list if they are predicted to be visible in the tile andappended to the second list otherwise When the followingNWOZ batch arrives all the primitives in the second list aremoved to the end of the first list and then the primitives ofthe batch are appended to the first list Finally another WOZbatch is processed whose primitives are again appended tothe two lists according to their predicted visibility

This reordering technique is highly effective at reducingovershading because if the visibility prediction is correct theearly depth test is able to discard more fragments whichreduces the amount of computation and memory accessesdevoted to occluded fragments Note that this scheme doesnot introduce any error as commented above Visibilitymispredictions simply imply a loss of culling effectivenessin the Early Depth Test

B Rendering Elimination Improvement

Rendering Elimination [1] is a technique that detects tilesthat produce the same color across adjacent frames Todo so when primitives are sorted into tiles at the end ofthe Geometry Pipeline a signature per tile is incrementallycomputed on-the-fly with the attributes of all primitivesoverlapping each tile Then when the Raster Pipeline startsprocessing a tile its signature computed for the current

Table IVISIBILITY CASUISTRY

Scenario Frame i Frame i+1

A Visible VisibleB Visible OccludedC Occluded OccludedD Occluded Visible

frame is compared against the signature computed in theprevious frame if both signatures match the tile is notrendered since it will produce the same colors as in theprevious frame Rendering Elimination requires all attributesfrom all primitives of a tile to be exactly the same as inthe previous frame to detect redundancy However in thecase that only occluded primitives change their attributesthe tilersquos colors will be the same as for the precedingframe making Rendering Elimination not able to detect andeliminate such frame-to-frame redundancy In this paperwe also propose using the approximate visibility resolutionmechanism described in Section III to compute signaturesonly with visible primitives so as to improve the effective-ness of Rendering Eliminationrsquos tile redundancy detection

In the baseline operation of Rendering Elimination alookup table named Signature Buffer stores one CRC32per tile Whenever a primitive is sorted the CRC32 ofthe attributes of its vertices is computed Then for all thetiles that the primitive overlaps the corresponding SignatureBuffer entry is read and updated by combining the CRC32value of the entry with the CRC32 value of the sortedprimitive

Using the visibility prediction scheme proposed in Sec-tion III we propose to extend the Rendering Eliminationtechnique as follows For each sorted primitive its depthis compared against the depth of the FVP in the previousframe for each tile it overlaps If the primitive is predictedto be occluded in a tile the Signature Buffer entry forthat tile is not updated with the CRC32 of the primitiveAs it will be shown in the Results section utilizing theFVP depth allows for a significant increase in redundanttile detection Moreover the proposed optimization doesnot produce any rendering errors Table I presents the fourpossibilities regarding the resolved visibility of a primitive(either visible or occluded) across two consecutive frames

For scenarios A and B the optimization behaves likethe baseline Rendering Elimination since the primitive wasvisible in the tile in Frame i it is considered for the signatureof the tile in Frame i + 1 regardless of its final visibilityNote that in scenario B the primitive will be occluded andtherefore will not be considered in the signature in Framei+ 2 This is the case for scenarios C and D

Scenario C is the case that improves over the baselinesince the occluded primitive does not affect the final colorsof the tile not considering the primitive for the signature

enhances redundancy detection while not generating errorsFinally scenario D does not cause rendering errors be-

cause for a primitive P (occluded in Frame i) to be visiblein Frame i+1 at least one of the following two conditionsmust hold

i) P has moved closer to the camera than the farthestdepth of the tile in the previous frame In that case P will beadded to the signature of the tile Since it was not includedin the signature of the previous frame the signatures willdiffer and the tile will be rendered

ii) All the primitives that occluded P have moved (orare not rendered) so that in Frame i + 1 they do nottotally occlude P In that case the attributes of the occluderprimitives must have changed and the signature will bedifferent even if P is not considered for the signature thetile will be rendered

V IMPLEMENTATION

In this section we describe the extra hardware requiredto implement the proposed early visibility resolution mecha-nism which basically consists of additional units to computeand store the FVP (farthest visible point) for all the tiles inthe frame Figure 5 shows how they are integrated into aTBR GPU

PrimitiveAssembly

PrimitiveAssembly

RasterizerRasterizerFragmentProcessing

FragmentProcessing

EarlyDepth

EarlyDepth

CommandProcessor

CommandProcessor

VertexProcessing

VertexProcessing

VertexFetcher

VertexFetcher

ColorBuffer

ColorBuffer

DepthBuffer

DepthBufferTexturesTextures

Hardware

PolygonList

Builder

PolygonList

Builder

TileScheduler

TileScheduler

ParameterBuffer

ParameterBuffer

BlendingBlending

LayerBuffer

LayerBuffer

Memory New Buffer

FVPTable

FVPTable

LayerGenerator

LayerGenerator

Figure 5 Graphics Pipeline including the structures needed to implementFVP computation

A Layer Generator Table

As discussed in Section III layers are tracked to emulatedepth among NWOZ primitives Assigning a layer identifierto a primitive requires to address the following issues

First since the layer identifier is intended to count thenumber of objects (draw commands) whose primitives haveoverlapped a given tile so far each tile must have itsindependent layer counter Of course for a given tile allthe primitives of the same command are assigned the samelayer identifier although that layer may differ from one tileto another

Second since WOZ primitives update their depth into theZ Buffer layer identifiers do not provide any informationamong primitives in a WOZ batch the same identifier canbe assigned to all WOZ primitives in a batch for a giventile

We propose to employ a small on-chip LUT whichwe call Layer Generator Table in order to manage theassociation of layer identifiers to primitives This table hasone entry per tile and each entry contains three fields

1) Last identifier of a command that produced a primitivethat overlapped the tile

2) Last layer assigned to a primitive that overlapped thetile

3) Last type of primitive (WOZNWOZ) that overlappedthe tile

Using the Layer Generator Table (LGT) we can assign alayer to every primitive in all the tiles it overlaps during thePolygon List Builder stage Whenever a primitive is sortedinto a tile the LGT entry for that tile is checked If the storedcommand identifier is the same as the primitiversquos commandidentifier it means that the primitive belongs to the samelayer as the last primitive sorted into that tile Consequentlythe primitive is assigned the layer stored in the entry Aftersorting a primitive into a tile it updates the last type ofprimitive field in the LGT (a binary value NWOZ or WOZ)

On the other hand if the stored command identifieris different to the primitiversquos command the layer maybe increased depending on the type of primitive NWOZprimitives always increase the layer number whereas forWOZ primitives the layer is only increased if the previousprimitive was NWOZ Finally the LUT entry is updatedwith the new command identifier and the new layer value ifthey have changed

The layer identifier of a primitive is stored in the Param-eter Buffer as any other attribute This way layers can beassigned to all the fragments of the primitive at rasterizationtime

B Layer Buffer

The farthest visible layer of a tile can be obtained bycomputing the minimum visible layer of all its pixels Sincetiles are relatively small (eg 16x16 pixels) we can use anon-chip buffer to keep track of per-pixel information for anentire tile This buffer which we call the Layer Buffer hasone entry for every pixel of the tile being rendered (just asthe Z Buffer or the Color Buffer) that stores the visible layerfor that pixel

The Layer Buffer is updated during the Blending stagewhen the final fragment opacity is already determined Todetect opacity we use the same alpha value that fragmentsemploy to blend with colors previously written in the ColorBuffer If the alpha factor is exactly 1 the fragment is opaqueand its layer is written into the Layer Buffer Otherwise

since the fragment is translucent and does not completelyocclude layers behind it the Layer Buffer is not updated

During the blending stage each fragment of a WOZprimitive stores its layer identifier in a register named ZR sothat it identifies the layer of the last visible WOZ primitiveand may be used to distinguish at the end of rendering atile if its FVP corresponds to a WOZ or a NWOZ primitiveie the FVP-type of the tile The value of ZR is comparedto Lfar when the tile finishes rendering if the two valuesare equal the FVP-type of the tile is WOZ Otherwise it isNWOZ

C FVP Table

In order to predict if a primitive is likely to be visible ina tile we use the tilersquos FVP depth of the previous frame sothe entire set of per-tile FVP depths must be stored Suchinformation is maintained in a structure that we call FVPTable The FVP Table has one entry per tile with eachentry containing the previous framersquos FVP depth for that tileEach entry in the table also stores the FVP-type to indicatewhether the type of data stored is a Z or a layer identifier

Whenever a tile finishes rendering its FVP-type is de-termined If the FVP depth belongs to a NWOZ primitivethe FVP Table entry for the tile is updated with Lfar settingits FVP-type bit Otherwise the FPV entry for the tile isupdated with Zfar and the entryrsquos FVP-type bit is cleared

VI EVALUATION METHODOLOGY

A Simulator infrastructure

We employ the Teapot simulation framework [6] to eval-uate our proposal Teapot runs unmodified Android appli-cations for mobile platforms and obtains GPU performanceand energy consumption statistics Table II lists the parame-ters used in the simulations in order to model an architectureresembling the ARM Mali-450 GPU [2] the most widelyused GPU architecture nowadays with almost 20 of themobile GPU market [3]

The traces that feed the Teapot cycle-accurate simulatorare obtained via a two-step process First an Android appli-cation is run in the Android emulator [7] and every OpenGLcommand sent to the GPU is intercepted and stored in a fileSecond those OpenGL commands are fed to the softwarerenderer included in Gallium3D [8] which is instrumentedto generate a trace containing all the information neededto guide the cycle accurate execution such as vertex datashader instructions or memory addresses of the differentstages of the Graphics Pipeline For each application wesimulate 60 consecutive frames from the original applicationrun

McPAT [9] is used to estimate the energy consumptionof the GPU All the additional hardware required for theproposed technique (Layer Generator Table FVT tableLayer Buffer comparators and registers) is modelled usingMcPATrsquos components (SRAMs Registers MUXes XORs)

Table IIGPU SIMULATION PARAMETERS

Baseline GPU Parameters

Tech Specs 400 MHz 1 V 32 nmScreen Resolution 1196x768Tile Size 16x16 pixels

Main Memory

Latency 50-100 cyclesBandwidth 4 Bcycle (dual channel LPDDR3)Size 1 GB

Queues

Vertex (2x) 16 entries 136 bytesentryTriangle Tile 16 entries 388 bytesentryFragment 64 entries 233 bytesentry

Caches

Vertex Cache 64 bytesline 2-way associative4 KB 1 bank 1 cycle

Texture Caches (4x) 64 bytesline 2-way associative8 KB 1 bank 1 cycle

Tile Cache 64 bytesline 8-way associative128 KB 8 banks 1 cycle

L2 Cache 64 bytesline 8-way associative256 KB 8 banks 2 cycles

Color Buffer 64 bytesline 1-way associative1 KB 1 bank 1 cycle

Depth Buffer 64 bytesline 1-way associative1 KB 1 bank 1 cycle

Non-programmable stages

Primitive assembly 1 trianglecycleRasterizer 16 attributescycleEarly Z test 32 in-flight quad-fragments 1 Depth Buffer

Programmable stages

Vertex Processor 1 vertex processorFragment Processor 4 fragment processors

Additional hardware

Layer Generator Table 3600 entries 3 bytesentryFVP Table 3600 entries 4 bytesentryLayer Buffer 64 bytesline 1-way associative

1 KB 1 bank 1 cycle

Regarding system memory Teapot employs DRAMSim2[10]

B Benchmarks

Table III presents the benchmarks employed to test theproposed approach which correspond to twenty unmodifiedAndroid graphics applications All of these applicationshave millions of downloads according to Google Play [11]with some of them surpassing 500 million downloads Theset of benchmarks includes games of the most populargenres in the mobile segment [12] such as puzzle arcadeand simulation The benchmarks also contain a variety ofworkloads completely 2D scenes such as cde or wmwscenes with simple 3D models such as ata or tib) and

scenes with more sophisticated models such as 300 or mstApplications classified as 3D contain both WOZ and NWOZprimitives while applications classified as 2D only containNWOZ primitives

Table IIIBENCHMARK SUITE

Benchmark Alias Genre Type

300 Seize your glory 300 Action 3DAir Attack ata Arcade 3DCrazy Snowboard csn Arcade 3DModern Strike mst First Person Shooter 3DTemple Run ter Platform 3DTigerball tib Physics Puzzle 3DAngry Birds abi Puzzle 2DArmymen arm Strategy 2DAvenger Legends ale Strategy 2DCandy Crush Saga ccs Puzzle 2DCastle Defense cde Tower Defense 2DClash of Clans coc MMO Strategy 2DCut the Rope ctr Puzzle 2DDude Perfect dpe Puzzle 2DHayday hay Simulation 2DHopeless hop Action Survival 2DMagic Touch mto Arcade 2DRedsun red Strategy 2DWherersquos my water wmw Puzzle 2DWorld of goo wog Physics Puzzle 2D

VII EXPERIMENTAL RESULTS

Figure 6 shows the energy consumption of the GPU-Memory system normalized to the Baseline GPU for our setof benchmarks The proposed optimizations that leverage anearly prediction of the visibility achieve a 43 reduction ofenergy consumption on average Energy savings are obtainedin all benchmarks with maximums of more than 80(cde dpe) Figure 7 shows the execution time divided intoGeometry and Raster pipelines normalized to the baselineOn average the proposed techniques achieve 39 executiontime reduction with maximums of more than 70 (ccs cdedpe)

057

01

02

03

04

05

06

07

08

09

1

No

rmal

ize

d e

ne

rgy

con

sum

pti

on

Overhead by additional accesses Overhead by additional hardware

Figure 6 Energy consumption of our EVR proposal normalized to theBaseline GPU

The energy overheads are mainly due to additional writesto the Parameter Buffer to store the layer identifiers Thisoverhead is quite moderate 21 on average as it can be

061

0

01

02

03

04

05

06

07

08

09

1

No

rmal

ize

d e

xecu

tio

n t

ime

Geometry Geometry overhead Raster

Figure 7 Execution time of our EVR proposal normalized to the BaselineGPU

seen in Figure 6 Figure 6 also illustrates that the addi-tional hardware added by the proposed mechanism incursin only 12 energy consumption overhead on average thestructures needed to manage the FVP information (LayerGenerator Table Layer Buffer and FVP Table) generate05 additional static and dynamic energy consumptionwhile the LUTs needed to implement Rendering Elimina-tion contribute to an additional 07 energy consumptionThe computation of Rendering Eliminationrsquos tile signaturesincurs in time overhead in the Geometry Pipeline whenevera primitive overlaps a large number of tiles since thepipeline is stalled waiting for all signatures to be sequentiallyupdated Figure 7 reports such overheads in execution timewhich on average represents 05 of the total

300 ata csn mst ter tib Average

0

1

2

3

4

5

6

Shad

ed

fra

gme

nts

pe

r p

ixe

l

Baseline EVR Oracle

Figure 8 Comparison of the number of shaded fragments per pixel amongthe baseline GPU our EVR proposal and an oracle

These important reductions in energy consumption andexecution time are mainly produced by avoiding the process-ing of ineffectual fragments (fragments that are occluded orare the same as in the previous frame) Figure 8 shows thenumber of fragments shaded per pixel using the proposedearly visibility resolution mechanism to reorder primitives(EVR) compared to the baseline for our set of 3D bench-marks We also compare our scheme with an oracle approach(which ideally assumes that the Z Buffer is initialized withthe final visibility of the tile ndashthe final depth valuesndash beforeit is executed) EVR significantly reduces (20) the numberof vainly shaded fragments and its results are close to thoseobtained by an oracle approach EVR cannot reach the oraclebecause of its approximate nature First it uses visibilityinformation of the previous frame which may have changed

Second it estimates visibility at a primitive-level while theoracle resolves visibility at the finest possible granularityfragment level

Moreover a large fraction of tiles are detected to beredundant and its execution is completely bypassed avoidingnot only the Fragment Shader stage for all their fragmentsbut also the rest of the stages of the Raster Pipeline forthose tiles Figure 9 shows the percentage of detectedredundant tiles ndashproducing the same colors as the previousframendash for our set of benchmarks Results are shown for thebaseline Rendering Elimination (RE) the proposed EVR-aided Rendering Elimination (EVR) and an oracle setup thatcan perfectly identify all tiles of a frame that are equal tothose of the previous frame

0

10

20

30

40

50

60

70

80

90

100

Det

ect

ed

eq

ual

tile

s

EVR RE Oracle

Figure 9 Percentage of detected equal tiles by EVR compared to REand an oracle

On average EVR avoids the rendering of 54 of the tilesreducing 5 more tiles than the baseline RE Predicting oc-cluded primitives and not adding them to the tilersquos signatureallows the detection of equal tiles in benchmarks in whichRE was hardly effective such as 300 or mst The majorityof these tiles that are identified as redundant corresponds toportions of the screen in which WOZ primitives are coveredby NWOZ primitives in the form of a HUD In most casesthe scene contains objects that are in motion but completelyoccluded by NWOZ geometry The layer-based visibilityscheme allows EVR to identify additional redundant tilesin benchmarks with a high degree of redundancy detectedby RE such as cde or mto In some applications such as hayor wmw the additional tiles eliminated exceeds 10 witha maximum of 30

The additional redundant tiles detected results in anaverage 10 reduction of energy consumption comparedto the baseline RE as presented in Figure 10 The earlyvisibility resolution incurs in some overheads which aregrouped together in the figure In the Geometry Pipeline theLayer Generator and FVP tables are accessed to generate alayer identifier which is stored in the Parameter Buffer Inthe Raster Pipeline the layer identifiers are read and writteninto the Layer Buffer When a tile finishes its rendering itsFVP is computed by accessing the Z and Layer Buffers andthe result is stored in the FVP Table Although the required

09

02

03

04

05

06

07

08

09

1

Ener

gy c

on

sum

pti

on

no

rmal

ized

to

RE

Overhead by FVP Computation

Figure 10 Energy consumption of our EVR proposal normalized to RE

sequential check of the two tables for each primitive andeach tile to which it is mapped could incur in some timeoverhead it is more than offset by the reduction in numberof primitives that can skip the signature computation stepsince they are occluded This is shown in Figure 11 whichcompares execution time broken down into Geometry andRaster Pipelines for the Baseline GPU RE and our proposedEVR approach for early visibility resolution Note that REhas to read the temporary hashes held in the Signature Bufferfor all the tiles that a primitive overlaps shift them as manybytes as the size of the primitive and finally combine themwith the hash of the primitive to produce a new signature forthe tile This process is avoided in our scheme if a primitiveis determined to be occluded in a tile since EVR marks it notto be included into the tilersquos signature The only exceptionwhere our EVR scheme does not reduce Geometry cycles ishop a benchmark that has very few primitives concentratedin a reduced amount of tiles Consequently the averagenumber of primitives to combine into the signature of a tile issmall limiting the benefits of occluded primitive detectionOn average our EVR mechanism reduces the execution timein the Geometry Pipeline by 4 with respect to RE

Moreover Rendering Elimination may induce time andenergy overheads in benchmarks where not enough redun-dant tiles are detected to offset the signature computationsuch as 300 or mst On the other hand our scheme is moreeffective at detecting redundant tiles and for non-redundanttiles specially in 3D benchmarks the primitive reordering in-creases the efficiency of the Early Depth Test which reducesthe amount of computations in the fragment processors Thisresults in overall speedups for all benchmarks

VIII RELATED WORK

Occlusion culling is a fundamental problem in computergraphics with an extensive literature spanning more thanthree decades In this section we focus on the most influ-ential works and the ones most related to our proposal

The Z Buffer [4] is the de facto standard to resolvevisibility due to its effectiveness and low implementationcost The Hierarchical Z Buffer [13] is a variation of thebaseline technique in which a depth pyramid is used to testvisibility The base level of the pyramid is the Z Buffer

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

300 ata csn mst ter tib abi arm ale ccs cde coc ctr dpe hay hop mto red wmw wog AVG

0

02

04

06

08

1

No

rmal

ize

d e

xecu

tio

n t

ime

Geometry Raster

Figure 11 Execution time comparison of our EVR proposal and RE against the baseline GPU

and higher levels are constructed by combining the depthof four pixels at the next lower level typically by choosingthe farthest one Entire primitives can be discarded withoutaccessing the Z Buffer by comparing their nearest depthagainst the values in higher levels in the pyramid OurEVR proposal also compares the depth of primitives toa FVP depth which would correspond to the top of thepyramid of the Hierarchical Z Buffer However the FVPdepth contains final visibility information which allowsunlike the Z pyramid to detect primitives that will beoccluded by others processed later Moreover the FVP depthincludes more information than just the top of the Z pyramidallowing the detection of occluded NWOZ primitives that donot use the Z buffer

Z-Prepass [14] draws the scene in two steps first thegeometry is rendered using simple fragment shaders onlyto quickly fill the Z Buffer Later the geometry is renderedagain with proper shaders but now with perfect visibilityinformation in-place so that all occluded fragments can bediscarded This additional render pass incurs in significantoverheads which may not always be offset by the increase inthe fragments discarded in the Early Depth Test By workingat a coarser granularity (primitive instead of fragment) EVRdoes not need to perform the pre-pass but still achievesresults comparable to having complete visibility information

The concept of layers has been previously adopted inthe context of occlusion culling most notably in DepthPeeling [15] an algorithm that renders geometry multipletimes peeling off the surface layer at each pixel in eachpass Recently Andersson et al [16] leveraged a two-layer representation of depths to avoid bandwidth spent inupdating the Hierarchical Z Buffer while in the work ofScheckel and Kolb [17] layers are used in combinationwith the alpha parameter to completely cull transparentfragments Unlike EVR these approaches cannot combinevisibility information of both WOZ and NWOZ primitivesfor a better visibility determination

Computing visibility at a fragment level (known as image-precision [18]) is useful to solve certain problems suchas circular dependencies However resolving visibility ata coarser grain could reduce the number of computations

needed Hardware occlusion queries [19] are a feature thatallow the user to query simple geometry (such as thebounding volumes) against the current contents of the ZBuffer The query counts the number of fragments thatpass the Z Test and the result allows the application toavoid rendering entire objects at the expense of CPU-GPUsynchronization Furthermore as with the Early Depth Testin order for occlusion queries to perform well both objectsand queries must be sent in front-to-back order EVR istransparent to the application in both axis it does not requireneither synchronization nor ordering

Multiple works reduce overshading by means of reorder-ing the primitives that make up a scene Govindaraju et al[20] propose an algorithm to sort non-overlapping objectsin either front-to-back or back-to front order from a givenviewpoint In the work of Chen et al [21] static objectsare preprocessed in order to create a depth-sorted list ofprimitives for every possible viewpoint The approach ofHan and Sander [22] also preprocesses objects to createseveral sorted lists that are indexed at runtime to ensureoptimal order but they consider movement by taking intoaccount not only viewpoints but also several key framesWeber and Stamminger [23] use a graph representationof dependencies in animated scenes with a fixed camerato sort primitives accordingly and leverage frame-to-framecoherence to merge different graphs and keep the overallstructure manageable VRO [24] also takes advantage oftemporal coherence to reorder objects entirely in hardwareand reduce overshading Unlike these approaches EVR isapplied at a finer granularity (primitive instead of object)does not need to perform any preprocess and can also beemployed in interactive scenes not just animated ones

IX CONCLUSIONS

We have presented a mechanism to determine visibilityin early stages of the Graphics Pipeline based on exploitingframe coherence Since consecutive frames tend to be verysimilar we use the information of a frame to estimate thevisibility for the following one

The proposed technique collects the depth of the farthestvisible primitive of every tile whenever its rendering processis complete For each overlapped tile the depth of a primitive

is compared against the depth stored for that tile in thepreceding frame If it is farther the primitive is occluded

This paper demonstrates the benefits of early visibilityprediction to remove ineffectual computations by increasingthe effectiveness of the Early Z Test a commonly usedtechnique in contemporary GPUs and Rendering Elimina-tion a recently proposed technique to exploit redundantcomputations The former works at pixel granularity and thelatter works at tile granularity

Using the predicted visibility information opaque prim-itives whose visibility is resolved using the Z Buffer arereordered such that primitives predicted as visible are ren-dered first which avoids the shading of occluded fragmentsBesides primitives predicted to be occluded are not con-sidered when generating the signature used by RenderingElimination to identify tiles that are equal to the ones in theprevious frame That increases the number of tiles that areidentified as redundant and consequently whose renderingcan be avoided

Our technique provides average speedups of 39 andenergy savings of 43 for a set of commercial Android ap-plications The reorder mechanism achieves overshading re-ductions comparable to having a Z Buffer filled with perfectvisibility information without requiring any additional renderpass to compute depths On the other hand by improvingthe tile redundancy detection of Rendering Elimination theraster pipeline of the GPU skips the rendering of more thanhalf of the tiles on average

X ACKNOWLEDGEMENTS

This work has been partially supported by the Span-ish State Research Agency under grant TIN2016-75344-R (AEIFEDER EU) and by the Generalitat de Catalunyaunder the AGAUR-FI program

REFERENCES

[1] M Anglada E de Lucas J-M Parcerisa J L AragonP Marcuello and A Gonzalez ldquoRendering elimination Earlydiscard of redundant tiles in the graphics pipelinerdquo in Pro-ceedings of the 25th IEEE International Symposium on High-Performance Computer Architecture IEEE 2019

[2] ldquoArm mali-450 gpurdquo httpsdeveloperarmcomproductsgraphics-and-multimediamali-gpusmali-450-gpu accessedDecember 10 2018

[3] ldquoHardware gpu marketrdquo httphwstatsunity3dcommobilegpuhtml accessed December 10 2018

[4] E Catmull ldquoA subdivision algorithm for computer display ofcurved surfacesrdquo tech rep Utah University Salt Lake CitySchool of Computing 1974

[5] ldquoPainterrsquos algorithmrdquo httpswwwsiggraphorgeducationmaterialsHyperGraphscanlinevisibilitypainterhtmaccessed December 10 2018

[6] J-M Arnau J-M Parcerisa and P Xekalakis ldquoTeapot atoolset for evaluating performance power and image qualityon mobile graphics systemsrdquo in Proceedings of the 27thInternational ACM Conference on Supercomputing pp 37ndash46 ACM 2013

[7] ldquoAndroid studiordquo httpsdeveloperandroidcomstudioindexhtml accessed December 10 2018

[8] ldquoGallium3drdquo httpswwwfreedesktoporgwikiSoftwaregallium accessed December 10 2018

[9] S Li J H Ahn R D Strong J B Brockman D M Tullsenand N P Jouppi ldquoMcPAT An Integrated Power Area andTiming Modeling Framework for Multicore and ManycoreArchitecturesrdquo in Proceedings of the 42nd Annual IEEEACMInternational Symposium on Microarchitecture pp 469ndash4802009

[10] P Rosenfeld E Cooper-Balis and B Jacob ldquoDramsim2 Acycle accurate memory system simulatorrdquo IEEE ComputerArchitecture Letters vol 10 no 1 pp 16ndash19 2011

[11] ldquoGoogle playrdquo httpsplaygooglecom accessed December10 2018

[12] ldquoMobile game statisticsrdquo httpsmediumcomsm appintelnew-mobile-game-statistics-every-game-publisher-should-know-in-2016-f1f8eef64f66 accessed December 102018

[13] N Greene M Kass and G Miller ldquoHierarchical z-buffervisibilityrdquo in Proceedings of the 20th Annual Conference onComputer Graphics and Interactive Techniques pp 231ndash238ACM 1993

[14] ldquoEarly z rejectionrdquo httpssoftwareintelcomen-usarticlesearly-z-rejection-sample accessed December 10 2018

[15] C Everitt ldquoInteractive order-independent transparencyrdquoWhite paper NVIDIA vol 2 no 6 p 7 2001

[16] M Andersson J Hasselgren and T Akenine-MollerldquoMasked depth culling for graphics hardwarerdquo ACM Trans-actions on Graphics vol 34 no 6 p 188 2015

[17] S Scheckel and A Kolb ldquoMin-max mipmaps for efficient2d occlusion cullingrdquo in Conference on Computer GraphicsVisualization and Computer Vision 2016

[18] I E Sutherland R F Sproull and R A SchumackerldquoA characterization of ten hidden-surface algorithmsrdquo ACMComputing Surveys vol 6 no 1 pp 1ndash55 1974

[19] O Mattausch J Bittner and M Wimmer ldquoChc++ Coherenthierarchical culling revisitedrdquo in Computer Graphics Forumvol 27 pp 221ndash230 Wiley Online Library 2008

[20] N K Govindaraju M Henson M C Lin and D ManochaldquoInteractive visibility ordering and transparency computationsamong geometric primitives in complex environmentsrdquo inProceedings of the 2005 Symposium on Interactive 3D Graph-ics and Games pp 49ndash56 ACM 2005

[21] G Chen P V Sander D Nehab L Yang and L Hu ldquoDepth-presorted triangle listsrdquo ACM Transactions on Graphicsvol 31 no 6 p 160 2012

[22] S Han and P V Sander ldquoTriangle reordering for reducedoverdraw in animated scenesrdquo in Proceedings of the 20thACM SIGGRAPH Symposium on Interactive 3D Graphics andGames pp 23ndash27 ACM 2016

[23] C Weber and M Stamminger ldquoTopological triangle sortingfor predefined camera pathsrdquo in Proceedings of the Confer-ence on Vision Modeling and Visualization pp 153ndash160Eurographics Association 2016

[24] E De Lucas P Marcuello J-M Parcerisa and A GonzalezldquoVisibility rendering order Improving energy efficiency onmobile gpus through frame coherencerdquo IEEE Transactionson Parallel and Distributed Systems 2018

without the need of tracking depth information using theZ Buffer Consequently to determine the FVP for a tilewe must distinguish between primitives that write on the ZBuffer (WOZ primitives) and primitives that do not (NWOZ)

A WOZ Primitives

All information regarding the visibility for these primi-tives is available in the Z Buffer when the tile is renderedThe per-tile FVP depth is computed as the maximum depthvalue stored in the Z Buffer (Zfar) A primitive is labeledas occluded in a given tile if its closest vertex (Znear) to theviewpoint is farther than the FVPrsquos depth from the previousframe

The coarse granularity caused by comparing to a singleZfar value combined with the conservative Znear comparison(which requires that all primitive points are beyond the FVPnot just those overlapping the tile) reduces the detection ratesince not all occluded primitives might be labeled as suchHowever this way the primitives can be labeled as occludedfor a tile earlier in the pipeline with information availableat the Polygon List Builder stage (vertex depths and tilebinning of the primitive) without the need to either clipthem to the boundaries of a tile or rasterize them Note thatZfar is a single value per tile so it is stored in an on-chipmemory buffer at an acceptable energy and area overhead

B NWOZ Primitives

The visibility for these primitives is implicit in the ren-dering order and is therefore not resolved using the ZBuffer However by using a different mechanism occludedprimitives can still be detected in such scenes During thesorting of primitives into tiles we tally how many differentdraw commands have produced primitives that overlappedeach particular tile and store that number in a layer identifiercounter The layer identifier of a tile starts at zero at thebeginning of the frame and is increased by 1 whenever aprimitive that belongs to a new command is sorted to thattile

When a primitive is sorted to a tile it is assigned thecurrent layer identifier of that tile Since opaque primitivesin a layer partially or completely occlude layers laid under itwe can use those identifiers as depth information primitiveswith higher layer identifiers are closer to the observer thanprimitives with smaller ones Later on after rasterizationlayer identifiers are tracked for all the opaque visible frag-ments of a primitive in the Layer Buffer which is a localstructure akin to the Z Buffer

When a tile is completely rendered all the informationconcerning its visibility is available in the Layer Buffer Thedepth of the FVP corresponds to the minimum identifierstored in the Layer Buffer (Lfar) A primitive is labeled asoccluded in a tile if its assigned layer for the current tile issmaller than the tilersquos Lfar from the previous frame

C Hybrid Scenes

A 3D scene is mainly composed of primitives that write inthe Z Buffer but it may also include primitives that do notFor instance a batch of NWOZ primitives are sometimesdrawn at the beginning of the scene as a background or at theend as a HUD1 Besides it is common to find scenes withtraditional alpha blending where geometry is rendered intwo steps In the first one the opaque geometry is renderedIn the second step the translucent primitives are processedin back-to-front order Translucent primitives are NWOZbecause by definition they are not occluders so they mustnot update the Z Buffer

WOZ primitives are also assigned a layer identifier tohelp compare its age relative to NWOZ primitives Howeversince resolving visibility among WOZ primitives themselvesis not determined by their relative age but by comparingtheir explicit depth values we can assign the same layeridentifier to all of the WOZ primitives in a batch If twoprimitives one being a WOZ and the other being an opaqueNWOZ overlap the same pixel visibility is resolved bycomparing their relative age ie by determining which onewas rendered last

The FVP depth of a tile may be either Zfar or Lfardepending on whether the FVP belongs to a WOZ or aNWOZ primitive respectively After computing Lfar wedetermine to which type of primitive it belongs and storethe proper FVP depth value (either Zfar or Lfar) for the tileA boolean value termed FVP-type is then set to indicatewhether the stored FVP corresponds to a WOZ or a NWOZprimitive

Layer 4 3 2

z=05 z=1

1

(a) FVP-type LayerFVP depth 3

Layer 3 2 1

z=0z=05 z=1

(b) FVP-type ZFVP depth 05

Figure 3 FVP depth computation in tiles with both WOZ primitives(white) and NWOZ primitives (striped)

Figure 3 illustrates how the FVP of a tile is computedin the presence of both WOZ and NWOZ primitives Atile is viewed in a top-down perspective with the locationof its primitives represented as rectangles The observer ofthe scene placed on the left ie the right corner is fartherThe top of the figure displays the layer identifiers for allprimitives as well as the Z value for WOZ primitives

1HUD is short for Head-Up Display a visual overlay used to presentinformation to the user

In the scenario presented in Figure 3a Layer 1 is com-pletely occluded by Layer 2 whereas Layer 2 is completelyoccluded by Layers 3 and 4 Layer 3 is visible so the Lfar

of the tile is 3 Since Layer 3 belongs to NWOZ primitivesthe FVP depth of the tile is its Lfar and a correspondingFVP-type that indicates that the FVP is a layer is stored

In the scenario presented in Figure 3b Layer 1 is visibleso the Lfar of the tile is 1 Since Layer 1 belongs to WOZprimitives the FVP depth corresponds to the tilersquos ZfarPrimitives with a depth value of 1 are occluded by primitiveswith smaller depth values while primitives with a depthvalue of 0 do not completely occlude primitives with a depthvalue of 05 Thus the Zfar and consequently the FVP depthof the tile is 05 The FVP-type of the tile is set to indicatethat the FVP is a Z value A primitive is labeled as occludedif one of the following two scenarios occurs

bull The FVP in the previous frame is NWOZ and the layerassigned to the primitive is lower than Lfar

bull The primitive and the FVP in the previous frame areWOZ and the primitiversquos Znear is farther than Zfar

IV REMOVING INNEFECTUAL COMPUTATIONS WITHEVR

In this section we present two optimizations that lever-age the presented EVR mechanism for early detection ofoccluded primitives to avoid ineffectual computations andmemory accesses in the Graphics Pipeline

A Overshading Reduction

Overshading occurs when a pixel is shaded multipletimes because several primitives overlap it If an opaqueprimitive writes into an already-shaded pixel the resourcesdevoted to the previous color computation have been wastedbecause it has no effect in the final image Note that someovershading cannot be avoided such as the one producedby translucent primitives As introduced before GPUs try toreduce overshading by employing an Early Depth Test whichavoids shading a fragment if a closer opaque fragmenthas already been processed Although this mechanism caneliminate a significant fraction of overshading it is heavilydependent on the order that fragments are processed becauseit can only discard fragments which are hidden by thosealready processed A direct solution to the overshadingproblem would be for the application to sort the opaqueprimitives in a front-to-back order However many of thesesoftware-based approaches require building costly spatialhierarchical data structures to render the scene from anysingle viewpoint They are only effective on ldquowalkthroughrdquoapplications where the entire scene is static and only theviewer moves through it because the overheads can beamortized over a large number of frames Furthermore suchapplication-level sorting is often challenging due to cyclicoverlaps among objects or objects containing geometry thatoccludes parts of the same object

Some applications perform a preliminary depth pre-pass(either in hardware or in software) where some or all ofthe geometry is rendered using a simple shader that onlywrites into the Z Buffer After that the actual render pass isexecuted but now having perfect or near-perfect visibilityinformation in the Z Buffer which greatly increases thenumber of fragments discarded by the depth test Despitethe improved efficacy of the depth test the overhead ofthe additional render pass is very high and often offsets itspotential benefits

In this paper we propose to use the speculative visibilitydetermination mechanism described in Section III to dynam-ically reorder opaque primitives so as to render primitivesthat are likely to be occluded after primitives that are likelyto be visible without the need of an additional render passThe reordering is performed in the Polygon List Builderstage when primitives are sorted into tiles In the baselineconfiguration for each primitive the Parameter Buffer isupdated as follows the primitiversquos attributes are stored inmemory and a pointer to those attributes is written into theDisplay List of each tile Then whenever a tile is renderedits Display List is accessed and the pointers to primitivesare dereferenced to access their attributes to rasterize them

The proposed reordering mechanism divides the DisplayList of every tile into two lists Tiles are rendered by fetchinginitially all the primitives from the first list and then theprimitives from the second list Whenever a primitive issorted into a tile its attributes are stored into the ParameterBuffer the same way as in the baseline The pointer tothose attributes on the other hand is stored on one of thelists depending on the type of primitive and its predictedvisibility according to Algorithm 1 This algorithm only

Algorithm 1 Reordering Algorithm based on FVPif Primitive is WOZ then

if Predicted visible thenAppend into First List

elseAppend into Second List

end ifelse NWOZ Primitive

if Second List not empty thenMove Second List to the end of the First List

end ifAppend into First List

end if

reorders opaque WOZ primitives among themselves whilepreserving the order of NWOZ primitives against themselvesand against WOZ primitives Reordering WOZ primitivesdoes not incur in rendering errors NWOZ primitives arenot reordered and all WOZ primitives perform the depthtest as usual which maintains the correctness of the resultproduced by such primitives regardless of the order in which

they are rasterized

2nd Batch1st Batch 4th Batch 3rd Batch

WOZ Primitives Predicted Occluded WOZ Primitives Predicted VisibleNWOZ Primitives

(a) Primitives overlapping a tile divided into 4 batches according to theirprimitive type

1st Batch

List 1 List 2

2nd Batch

3rd Batch

4th Batch

(b) WOZ primitives that are predicted occluded are stored on the SecondList while all other primitives are stored in the First List

Figure 4 Reordering algorithm example

To illustrate Algorithm 1 let us consider Figure 4ashowing 4 different batches of primitives of a particular tileThe two WOZ batches include primitives that are predictedto be visible and primitives that are predicted to be occludedFigure 4b shows how they are reordered

The first processed batch is an NWOZ batch No actionsare performed with the second list since it is empty and allthe primitives in the batch are appended to the first list Nextthere is a WOZ batch whose primitives are appended to thefirst list if they are predicted to be visible in the tile andappended to the second list otherwise When the followingNWOZ batch arrives all the primitives in the second list aremoved to the end of the first list and then the primitives ofthe batch are appended to the first list Finally another WOZbatch is processed whose primitives are again appended tothe two lists according to their predicted visibility

This reordering technique is highly effective at reducingovershading because if the visibility prediction is correct theearly depth test is able to discard more fragments whichreduces the amount of computation and memory accessesdevoted to occluded fragments Note that this scheme doesnot introduce any error as commented above Visibilitymispredictions simply imply a loss of culling effectivenessin the Early Depth Test

B Rendering Elimination Improvement

Rendering Elimination [1] is a technique that detects tilesthat produce the same color across adjacent frames Todo so when primitives are sorted into tiles at the end ofthe Geometry Pipeline a signature per tile is incrementallycomputed on-the-fly with the attributes of all primitivesoverlapping each tile Then when the Raster Pipeline startsprocessing a tile its signature computed for the current

Table IVISIBILITY CASUISTRY

Scenario Frame i Frame i+1

A Visible VisibleB Visible OccludedC Occluded OccludedD Occluded Visible

frame is compared against the signature computed in theprevious frame if both signatures match the tile is notrendered since it will produce the same colors as in theprevious frame Rendering Elimination requires all attributesfrom all primitives of a tile to be exactly the same as inthe previous frame to detect redundancy However in thecase that only occluded primitives change their attributesthe tilersquos colors will be the same as for the precedingframe making Rendering Elimination not able to detect andeliminate such frame-to-frame redundancy In this paperwe also propose using the approximate visibility resolutionmechanism described in Section III to compute signaturesonly with visible primitives so as to improve the effective-ness of Rendering Eliminationrsquos tile redundancy detection

In the baseline operation of Rendering Elimination alookup table named Signature Buffer stores one CRC32per tile Whenever a primitive is sorted the CRC32 ofthe attributes of its vertices is computed Then for all thetiles that the primitive overlaps the corresponding SignatureBuffer entry is read and updated by combining the CRC32value of the entry with the CRC32 value of the sortedprimitive

Using the visibility prediction scheme proposed in Sec-tion III we propose to extend the Rendering Eliminationtechnique as follows For each sorted primitive its depthis compared against the depth of the FVP in the previousframe for each tile it overlaps If the primitive is predictedto be occluded in a tile the Signature Buffer entry forthat tile is not updated with the CRC32 of the primitiveAs it will be shown in the Results section utilizing theFVP depth allows for a significant increase in redundanttile detection Moreover the proposed optimization doesnot produce any rendering errors Table I presents the fourpossibilities regarding the resolved visibility of a primitive(either visible or occluded) across two consecutive frames

For scenarios A and B the optimization behaves likethe baseline Rendering Elimination since the primitive wasvisible in the tile in Frame i it is considered for the signatureof the tile in Frame i + 1 regardless of its final visibilityNote that in scenario B the primitive will be occluded andtherefore will not be considered in the signature in Framei+ 2 This is the case for scenarios C and D

Scenario C is the case that improves over the baselinesince the occluded primitive does not affect the final colorsof the tile not considering the primitive for the signature

enhances redundancy detection while not generating errorsFinally scenario D does not cause rendering errors be-

cause for a primitive P (occluded in Frame i) to be visiblein Frame i+1 at least one of the following two conditionsmust hold

i) P has moved closer to the camera than the farthestdepth of the tile in the previous frame In that case P will beadded to the signature of the tile Since it was not includedin the signature of the previous frame the signatures willdiffer and the tile will be rendered

ii) All the primitives that occluded P have moved (orare not rendered) so that in Frame i + 1 they do nottotally occlude P In that case the attributes of the occluderprimitives must have changed and the signature will bedifferent even if P is not considered for the signature thetile will be rendered

V IMPLEMENTATION

In this section we describe the extra hardware requiredto implement the proposed early visibility resolution mecha-nism which basically consists of additional units to computeand store the FVP (farthest visible point) for all the tiles inthe frame Figure 5 shows how they are integrated into aTBR GPU

PrimitiveAssembly

PrimitiveAssembly

RasterizerRasterizerFragmentProcessing

FragmentProcessing

EarlyDepth

EarlyDepth

CommandProcessor

CommandProcessor

VertexProcessing

VertexProcessing

VertexFetcher

VertexFetcher

ColorBuffer

ColorBuffer

DepthBuffer

DepthBufferTexturesTextures

Hardware

PolygonList

Builder

PolygonList

Builder

TileScheduler

TileScheduler

ParameterBuffer

ParameterBuffer

BlendingBlending

LayerBuffer

LayerBuffer

Memory New Buffer

FVPTable

FVPTable

LayerGenerator

LayerGenerator

Figure 5 Graphics Pipeline including the structures needed to implementFVP computation

A Layer Generator Table

As discussed in Section III layers are tracked to emulatedepth among NWOZ primitives Assigning a layer identifierto a primitive requires to address the following issues

First since the layer identifier is intended to count thenumber of objects (draw commands) whose primitives haveoverlapped a given tile so far each tile must have itsindependent layer counter Of course for a given tile allthe primitives of the same command are assigned the samelayer identifier although that layer may differ from one tileto another

Second since WOZ primitives update their depth into theZ Buffer layer identifiers do not provide any informationamong primitives in a WOZ batch the same identifier canbe assigned to all WOZ primitives in a batch for a giventile

We propose to employ a small on-chip LUT whichwe call Layer Generator Table in order to manage theassociation of layer identifiers to primitives This table hasone entry per tile and each entry contains three fields

1) Last identifier of a command that produced a primitivethat overlapped the tile

2) Last layer assigned to a primitive that overlapped thetile

3) Last type of primitive (WOZNWOZ) that overlappedthe tile

Using the Layer Generator Table (LGT) we can assign alayer to every primitive in all the tiles it overlaps during thePolygon List Builder stage Whenever a primitive is sortedinto a tile the LGT entry for that tile is checked If the storedcommand identifier is the same as the primitiversquos commandidentifier it means that the primitive belongs to the samelayer as the last primitive sorted into that tile Consequentlythe primitive is assigned the layer stored in the entry Aftersorting a primitive into a tile it updates the last type ofprimitive field in the LGT (a binary value NWOZ or WOZ)

On the other hand if the stored command identifieris different to the primitiversquos command the layer maybe increased depending on the type of primitive NWOZprimitives always increase the layer number whereas forWOZ primitives the layer is only increased if the previousprimitive was NWOZ Finally the LUT entry is updatedwith the new command identifier and the new layer value ifthey have changed

The layer identifier of a primitive is stored in the Param-eter Buffer as any other attribute This way layers can beassigned to all the fragments of the primitive at rasterizationtime

B Layer Buffer

The farthest visible layer of a tile can be obtained bycomputing the minimum visible layer of all its pixels Sincetiles are relatively small (eg 16x16 pixels) we can use anon-chip buffer to keep track of per-pixel information for anentire tile This buffer which we call the Layer Buffer hasone entry for every pixel of the tile being rendered (just asthe Z Buffer or the Color Buffer) that stores the visible layerfor that pixel

The Layer Buffer is updated during the Blending stagewhen the final fragment opacity is already determined Todetect opacity we use the same alpha value that fragmentsemploy to blend with colors previously written in the ColorBuffer If the alpha factor is exactly 1 the fragment is opaqueand its layer is written into the Layer Buffer Otherwise

since the fragment is translucent and does not completelyocclude layers behind it the Layer Buffer is not updated

During the blending stage each fragment of a WOZprimitive stores its layer identifier in a register named ZR sothat it identifies the layer of the last visible WOZ primitiveand may be used to distinguish at the end of rendering atile if its FVP corresponds to a WOZ or a NWOZ primitiveie the FVP-type of the tile The value of ZR is comparedto Lfar when the tile finishes rendering if the two valuesare equal the FVP-type of the tile is WOZ Otherwise it isNWOZ

C FVP Table

In order to predict if a primitive is likely to be visible ina tile we use the tilersquos FVP depth of the previous frame sothe entire set of per-tile FVP depths must be stored Suchinformation is maintained in a structure that we call FVPTable The FVP Table has one entry per tile with eachentry containing the previous framersquos FVP depth for that tileEach entry in the table also stores the FVP-type to indicatewhether the type of data stored is a Z or a layer identifier

Whenever a tile finishes rendering its FVP-type is de-termined If the FVP depth belongs to a NWOZ primitivethe FVP Table entry for the tile is updated with Lfar settingits FVP-type bit Otherwise the FPV entry for the tile isupdated with Zfar and the entryrsquos FVP-type bit is cleared

VI EVALUATION METHODOLOGY

A Simulator infrastructure

We employ the Teapot simulation framework [6] to eval-uate our proposal Teapot runs unmodified Android appli-cations for mobile platforms and obtains GPU performanceand energy consumption statistics Table II lists the parame-ters used in the simulations in order to model an architectureresembling the ARM Mali-450 GPU [2] the most widelyused GPU architecture nowadays with almost 20 of themobile GPU market [3]

The traces that feed the Teapot cycle-accurate simulatorare obtained via a two-step process First an Android appli-cation is run in the Android emulator [7] and every OpenGLcommand sent to the GPU is intercepted and stored in a fileSecond those OpenGL commands are fed to the softwarerenderer included in Gallium3D [8] which is instrumentedto generate a trace containing all the information neededto guide the cycle accurate execution such as vertex datashader instructions or memory addresses of the differentstages of the Graphics Pipeline For each application wesimulate 60 consecutive frames from the original applicationrun

McPAT [9] is used to estimate the energy consumptionof the GPU All the additional hardware required for theproposed technique (Layer Generator Table FVT tableLayer Buffer comparators and registers) is modelled usingMcPATrsquos components (SRAMs Registers MUXes XORs)

Table IIGPU SIMULATION PARAMETERS

Baseline GPU Parameters

Tech Specs 400 MHz 1 V 32 nmScreen Resolution 1196x768Tile Size 16x16 pixels

Main Memory

Latency 50-100 cyclesBandwidth 4 Bcycle (dual channel LPDDR3)Size 1 GB

Queues

Vertex (2x) 16 entries 136 bytesentryTriangle Tile 16 entries 388 bytesentryFragment 64 entries 233 bytesentry

Caches

Vertex Cache 64 bytesline 2-way associative4 KB 1 bank 1 cycle

Texture Caches (4x) 64 bytesline 2-way associative8 KB 1 bank 1 cycle

Tile Cache 64 bytesline 8-way associative128 KB 8 banks 1 cycle

L2 Cache 64 bytesline 8-way associative256 KB 8 banks 2 cycles

Color Buffer 64 bytesline 1-way associative1 KB 1 bank 1 cycle

Depth Buffer 64 bytesline 1-way associative1 KB 1 bank 1 cycle

Non-programmable stages

Primitive assembly 1 trianglecycleRasterizer 16 attributescycleEarly Z test 32 in-flight quad-fragments 1 Depth Buffer

Programmable stages

Vertex Processor 1 vertex processorFragment Processor 4 fragment processors

Additional hardware

Layer Generator Table 3600 entries 3 bytesentryFVP Table 3600 entries 4 bytesentryLayer Buffer 64 bytesline 1-way associative

1 KB 1 bank 1 cycle

Regarding system memory Teapot employs DRAMSim2[10]

B Benchmarks

Table III presents the benchmarks employed to test theproposed approach which correspond to twenty unmodifiedAndroid graphics applications All of these applicationshave millions of downloads according to Google Play [11]with some of them surpassing 500 million downloads Theset of benchmarks includes games of the most populargenres in the mobile segment [12] such as puzzle arcadeand simulation The benchmarks also contain a variety ofworkloads completely 2D scenes such as cde or wmwscenes with simple 3D models such as ata or tib) and

scenes with more sophisticated models such as 300 or mstApplications classified as 3D contain both WOZ and NWOZprimitives while applications classified as 2D only containNWOZ primitives

Table IIIBENCHMARK SUITE

Benchmark Alias Genre Type

300 Seize your glory 300 Action 3DAir Attack ata Arcade 3DCrazy Snowboard csn Arcade 3DModern Strike mst First Person Shooter 3DTemple Run ter Platform 3DTigerball tib Physics Puzzle 3DAngry Birds abi Puzzle 2DArmymen arm Strategy 2DAvenger Legends ale Strategy 2DCandy Crush Saga ccs Puzzle 2DCastle Defense cde Tower Defense 2DClash of Clans coc MMO Strategy 2DCut the Rope ctr Puzzle 2DDude Perfect dpe Puzzle 2DHayday hay Simulation 2DHopeless hop Action Survival 2DMagic Touch mto Arcade 2DRedsun red Strategy 2DWherersquos my water wmw Puzzle 2DWorld of goo wog Physics Puzzle 2D

VII EXPERIMENTAL RESULTS

Figure 6 shows the energy consumption of the GPU-Memory system normalized to the Baseline GPU for our setof benchmarks The proposed optimizations that leverage anearly prediction of the visibility achieve a 43 reduction ofenergy consumption on average Energy savings are obtainedin all benchmarks with maximums of more than 80(cde dpe) Figure 7 shows the execution time divided intoGeometry and Raster pipelines normalized to the baselineOn average the proposed techniques achieve 39 executiontime reduction with maximums of more than 70 (ccs cdedpe)

057

01

02

03

04

05

06

07

08

09

1

No

rmal

ize

d e

ne

rgy

con

sum

pti

on

Overhead by additional accesses Overhead by additional hardware

Figure 6 Energy consumption of our EVR proposal normalized to theBaseline GPU

The energy overheads are mainly due to additional writesto the Parameter Buffer to store the layer identifiers Thisoverhead is quite moderate 21 on average as it can be

061

0

01

02

03

04

05

06

07

08

09

1

No

rmal

ize

d e

xecu

tio

n t

ime

Geometry Geometry overhead Raster

Figure 7 Execution time of our EVR proposal normalized to the BaselineGPU

seen in Figure 6 Figure 6 also illustrates that the addi-tional hardware added by the proposed mechanism incursin only 12 energy consumption overhead on average thestructures needed to manage the FVP information (LayerGenerator Table Layer Buffer and FVP Table) generate05 additional static and dynamic energy consumptionwhile the LUTs needed to implement Rendering Elimina-tion contribute to an additional 07 energy consumptionThe computation of Rendering Eliminationrsquos tile signaturesincurs in time overhead in the Geometry Pipeline whenevera primitive overlaps a large number of tiles since thepipeline is stalled waiting for all signatures to be sequentiallyupdated Figure 7 reports such overheads in execution timewhich on average represents 05 of the total

300 ata csn mst ter tib Average

0

1

2

3

4

5

6

Shad

ed

fra

gme

nts

pe

r p

ixe

l

Baseline EVR Oracle

Figure 8 Comparison of the number of shaded fragments per pixel amongthe baseline GPU our EVR proposal and an oracle

These important reductions in energy consumption andexecution time are mainly produced by avoiding the process-ing of ineffectual fragments (fragments that are occluded orare the same as in the previous frame) Figure 8 shows thenumber of fragments shaded per pixel using the proposedearly visibility resolution mechanism to reorder primitives(EVR) compared to the baseline for our set of 3D bench-marks We also compare our scheme with an oracle approach(which ideally assumes that the Z Buffer is initialized withthe final visibility of the tile ndashthe final depth valuesndash beforeit is executed) EVR significantly reduces (20) the numberof vainly shaded fragments and its results are close to thoseobtained by an oracle approach EVR cannot reach the oraclebecause of its approximate nature First it uses visibilityinformation of the previous frame which may have changed

Second it estimates visibility at a primitive-level while theoracle resolves visibility at the finest possible granularityfragment level

Moreover a large fraction of tiles are detected to beredundant and its execution is completely bypassed avoidingnot only the Fragment Shader stage for all their fragmentsbut also the rest of the stages of the Raster Pipeline forthose tiles Figure 9 shows the percentage of detectedredundant tiles ndashproducing the same colors as the previousframendash for our set of benchmarks Results are shown for thebaseline Rendering Elimination (RE) the proposed EVR-aided Rendering Elimination (EVR) and an oracle setup thatcan perfectly identify all tiles of a frame that are equal tothose of the previous frame

0

10

20

30

40

50

60

70

80

90

100

Det

ect

ed

eq

ual

tile

s

EVR RE Oracle

Figure 9 Percentage of detected equal tiles by EVR compared to REand an oracle

On average EVR avoids the rendering of 54 of the tilesreducing 5 more tiles than the baseline RE Predicting oc-cluded primitives and not adding them to the tilersquos signatureallows the detection of equal tiles in benchmarks in whichRE was hardly effective such as 300 or mst The majorityof these tiles that are identified as redundant corresponds toportions of the screen in which WOZ primitives are coveredby NWOZ primitives in the form of a HUD In most casesthe scene contains objects that are in motion but completelyoccluded by NWOZ geometry The layer-based visibilityscheme allows EVR to identify additional redundant tilesin benchmarks with a high degree of redundancy detectedby RE such as cde or mto In some applications such as hayor wmw the additional tiles eliminated exceeds 10 witha maximum of 30

The additional redundant tiles detected results in anaverage 10 reduction of energy consumption comparedto the baseline RE as presented in Figure 10 The earlyvisibility resolution incurs in some overheads which aregrouped together in the figure In the Geometry Pipeline theLayer Generator and FVP tables are accessed to generate alayer identifier which is stored in the Parameter Buffer Inthe Raster Pipeline the layer identifiers are read and writteninto the Layer Buffer When a tile finishes its rendering itsFVP is computed by accessing the Z and Layer Buffers andthe result is stored in the FVP Table Although the required

09

02

03

04

05

06

07

08

09

1

Ener

gy c

on

sum

pti

on

no

rmal

ized

to

RE

Overhead by FVP Computation

Figure 10 Energy consumption of our EVR proposal normalized to RE

sequential check of the two tables for each primitive andeach tile to which it is mapped could incur in some timeoverhead it is more than offset by the reduction in numberof primitives that can skip the signature computation stepsince they are occluded This is shown in Figure 11 whichcompares execution time broken down into Geometry andRaster Pipelines for the Baseline GPU RE and our proposedEVR approach for early visibility resolution Note that REhas to read the temporary hashes held in the Signature Bufferfor all the tiles that a primitive overlaps shift them as manybytes as the size of the primitive and finally combine themwith the hash of the primitive to produce a new signature forthe tile This process is avoided in our scheme if a primitiveis determined to be occluded in a tile since EVR marks it notto be included into the tilersquos signature The only exceptionwhere our EVR scheme does not reduce Geometry cycles ishop a benchmark that has very few primitives concentratedin a reduced amount of tiles Consequently the averagenumber of primitives to combine into the signature of a tile issmall limiting the benefits of occluded primitive detectionOn average our EVR mechanism reduces the execution timein the Geometry Pipeline by 4 with respect to RE

Moreover Rendering Elimination may induce time andenergy overheads in benchmarks where not enough redun-dant tiles are detected to offset the signature computationsuch as 300 or mst On the other hand our scheme is moreeffective at detecting redundant tiles and for non-redundanttiles specially in 3D benchmarks the primitive reordering in-creases the efficiency of the Early Depth Test which reducesthe amount of computations in the fragment processors Thisresults in overall speedups for all benchmarks

VIII RELATED WORK

Occlusion culling is a fundamental problem in computergraphics with an extensive literature spanning more thanthree decades In this section we focus on the most influ-ential works and the ones most related to our proposal

The Z Buffer [4] is the de facto standard to resolvevisibility due to its effectiveness and low implementationcost The Hierarchical Z Buffer [13] is a variation of thebaseline technique in which a depth pyramid is used to testvisibility The base level of the pyramid is the Z Buffer

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

300 ata csn mst ter tib abi arm ale ccs cde coc ctr dpe hay hop mto red wmw wog AVG

0

02

04

06

08

1

No

rmal

ize

d e

xecu

tio

n t

ime

Geometry Raster

Figure 11 Execution time comparison of our EVR proposal and RE against the baseline GPU

and higher levels are constructed by combining the depthof four pixels at the next lower level typically by choosingthe farthest one Entire primitives can be discarded withoutaccessing the Z Buffer by comparing their nearest depthagainst the values in higher levels in the pyramid OurEVR proposal also compares the depth of primitives toa FVP depth which would correspond to the top of thepyramid of the Hierarchical Z Buffer However the FVPdepth contains final visibility information which allowsunlike the Z pyramid to detect primitives that will beoccluded by others processed later Moreover the FVP depthincludes more information than just the top of the Z pyramidallowing the detection of occluded NWOZ primitives that donot use the Z buffer

Z-Prepass [14] draws the scene in two steps first thegeometry is rendered using simple fragment shaders onlyto quickly fill the Z Buffer Later the geometry is renderedagain with proper shaders but now with perfect visibilityinformation in-place so that all occluded fragments can bediscarded This additional render pass incurs in significantoverheads which may not always be offset by the increase inthe fragments discarded in the Early Depth Test By workingat a coarser granularity (primitive instead of fragment) EVRdoes not need to perform the pre-pass but still achievesresults comparable to having complete visibility information

The concept of layers has been previously adopted inthe context of occlusion culling most notably in DepthPeeling [15] an algorithm that renders geometry multipletimes peeling off the surface layer at each pixel in eachpass Recently Andersson et al [16] leveraged a two-layer representation of depths to avoid bandwidth spent inupdating the Hierarchical Z Buffer while in the work ofScheckel and Kolb [17] layers are used in combinationwith the alpha parameter to completely cull transparentfragments Unlike EVR these approaches cannot combinevisibility information of both WOZ and NWOZ primitivesfor a better visibility determination

Computing visibility at a fragment level (known as image-precision [18]) is useful to solve certain problems suchas circular dependencies However resolving visibility ata coarser grain could reduce the number of computations

needed Hardware occlusion queries [19] are a feature thatallow the user to query simple geometry (such as thebounding volumes) against the current contents of the ZBuffer The query counts the number of fragments thatpass the Z Test and the result allows the application toavoid rendering entire objects at the expense of CPU-GPUsynchronization Furthermore as with the Early Depth Testin order for occlusion queries to perform well both objectsand queries must be sent in front-to-back order EVR istransparent to the application in both axis it does not requireneither synchronization nor ordering

Multiple works reduce overshading by means of reorder-ing the primitives that make up a scene Govindaraju et al[20] propose an algorithm to sort non-overlapping objectsin either front-to-back or back-to front order from a givenviewpoint In the work of Chen et al [21] static objectsare preprocessed in order to create a depth-sorted list ofprimitives for every possible viewpoint The approach ofHan and Sander [22] also preprocesses objects to createseveral sorted lists that are indexed at runtime to ensureoptimal order but they consider movement by taking intoaccount not only viewpoints but also several key framesWeber and Stamminger [23] use a graph representationof dependencies in animated scenes with a fixed camerato sort primitives accordingly and leverage frame-to-framecoherence to merge different graphs and keep the overallstructure manageable VRO [24] also takes advantage oftemporal coherence to reorder objects entirely in hardwareand reduce overshading Unlike these approaches EVR isapplied at a finer granularity (primitive instead of object)does not need to perform any preprocess and can also beemployed in interactive scenes not just animated ones

IX CONCLUSIONS

We have presented a mechanism to determine visibilityin early stages of the Graphics Pipeline based on exploitingframe coherence Since consecutive frames tend to be verysimilar we use the information of a frame to estimate thevisibility for the following one

The proposed technique collects the depth of the farthestvisible primitive of every tile whenever its rendering processis complete For each overlapped tile the depth of a primitive

is compared against the depth stored for that tile in thepreceding frame If it is farther the primitive is occluded

This paper demonstrates the benefits of early visibilityprediction to remove ineffectual computations by increasingthe effectiveness of the Early Z Test a commonly usedtechnique in contemporary GPUs and Rendering Elimina-tion a recently proposed technique to exploit redundantcomputations The former works at pixel granularity and thelatter works at tile granularity

Using the predicted visibility information opaque prim-itives whose visibility is resolved using the Z Buffer arereordered such that primitives predicted as visible are ren-dered first which avoids the shading of occluded fragmentsBesides primitives predicted to be occluded are not con-sidered when generating the signature used by RenderingElimination to identify tiles that are equal to the ones in theprevious frame That increases the number of tiles that areidentified as redundant and consequently whose renderingcan be avoided

Our technique provides average speedups of 39 andenergy savings of 43 for a set of commercial Android ap-plications The reorder mechanism achieves overshading re-ductions comparable to having a Z Buffer filled with perfectvisibility information without requiring any additional renderpass to compute depths On the other hand by improvingthe tile redundancy detection of Rendering Elimination theraster pipeline of the GPU skips the rendering of more thanhalf of the tiles on average

X ACKNOWLEDGEMENTS

This work has been partially supported by the Span-ish State Research Agency under grant TIN2016-75344-R (AEIFEDER EU) and by the Generalitat de Catalunyaunder the AGAUR-FI program

REFERENCES

[1] M Anglada E de Lucas J-M Parcerisa J L AragonP Marcuello and A Gonzalez ldquoRendering elimination Earlydiscard of redundant tiles in the graphics pipelinerdquo in Pro-ceedings of the 25th IEEE International Symposium on High-Performance Computer Architecture IEEE 2019

[2] ldquoArm mali-450 gpurdquo httpsdeveloperarmcomproductsgraphics-and-multimediamali-gpusmali-450-gpu accessedDecember 10 2018

[3] ldquoHardware gpu marketrdquo httphwstatsunity3dcommobilegpuhtml accessed December 10 2018

[4] E Catmull ldquoA subdivision algorithm for computer display ofcurved surfacesrdquo tech rep Utah University Salt Lake CitySchool of Computing 1974

[5] ldquoPainterrsquos algorithmrdquo httpswwwsiggraphorgeducationmaterialsHyperGraphscanlinevisibilitypainterhtmaccessed December 10 2018

[6] J-M Arnau J-M Parcerisa and P Xekalakis ldquoTeapot atoolset for evaluating performance power and image qualityon mobile graphics systemsrdquo in Proceedings of the 27thInternational ACM Conference on Supercomputing pp 37ndash46 ACM 2013

[7] ldquoAndroid studiordquo httpsdeveloperandroidcomstudioindexhtml accessed December 10 2018

[8] ldquoGallium3drdquo httpswwwfreedesktoporgwikiSoftwaregallium accessed December 10 2018

[9] S Li J H Ahn R D Strong J B Brockman D M Tullsenand N P Jouppi ldquoMcPAT An Integrated Power Area andTiming Modeling Framework for Multicore and ManycoreArchitecturesrdquo in Proceedings of the 42nd Annual IEEEACMInternational Symposium on Microarchitecture pp 469ndash4802009

[10] P Rosenfeld E Cooper-Balis and B Jacob ldquoDramsim2 Acycle accurate memory system simulatorrdquo IEEE ComputerArchitecture Letters vol 10 no 1 pp 16ndash19 2011

[11] ldquoGoogle playrdquo httpsplaygooglecom accessed December10 2018

[12] ldquoMobile game statisticsrdquo httpsmediumcomsm appintelnew-mobile-game-statistics-every-game-publisher-should-know-in-2016-f1f8eef64f66 accessed December 102018

[13] N Greene M Kass and G Miller ldquoHierarchical z-buffervisibilityrdquo in Proceedings of the 20th Annual Conference onComputer Graphics and Interactive Techniques pp 231ndash238ACM 1993

[14] ldquoEarly z rejectionrdquo httpssoftwareintelcomen-usarticlesearly-z-rejection-sample accessed December 10 2018

[15] C Everitt ldquoInteractive order-independent transparencyrdquoWhite paper NVIDIA vol 2 no 6 p 7 2001

[16] M Andersson J Hasselgren and T Akenine-MollerldquoMasked depth culling for graphics hardwarerdquo ACM Trans-actions on Graphics vol 34 no 6 p 188 2015

[17] S Scheckel and A Kolb ldquoMin-max mipmaps for efficient2d occlusion cullingrdquo in Conference on Computer GraphicsVisualization and Computer Vision 2016

[18] I E Sutherland R F Sproull and R A SchumackerldquoA characterization of ten hidden-surface algorithmsrdquo ACMComputing Surveys vol 6 no 1 pp 1ndash55 1974

[19] O Mattausch J Bittner and M Wimmer ldquoChc++ Coherenthierarchical culling revisitedrdquo in Computer Graphics Forumvol 27 pp 221ndash230 Wiley Online Library 2008

[20] N K Govindaraju M Henson M C Lin and D ManochaldquoInteractive visibility ordering and transparency computationsamong geometric primitives in complex environmentsrdquo inProceedings of the 2005 Symposium on Interactive 3D Graph-ics and Games pp 49ndash56 ACM 2005

[21] G Chen P V Sander D Nehab L Yang and L Hu ldquoDepth-presorted triangle listsrdquo ACM Transactions on Graphicsvol 31 no 6 p 160 2012

[22] S Han and P V Sander ldquoTriangle reordering for reducedoverdraw in animated scenesrdquo in Proceedings of the 20thACM SIGGRAPH Symposium on Interactive 3D Graphics andGames pp 23ndash27 ACM 2016

[23] C Weber and M Stamminger ldquoTopological triangle sortingfor predefined camera pathsrdquo in Proceedings of the Confer-ence on Vision Modeling and Visualization pp 153ndash160Eurographics Association 2016

[24] E De Lucas P Marcuello J-M Parcerisa and A GonzalezldquoVisibility rendering order Improving energy efficiency onmobile gpus through frame coherencerdquo IEEE Transactionson Parallel and Distributed Systems 2018

In the scenario presented in Figure 3a Layer 1 is com-pletely occluded by Layer 2 whereas Layer 2 is completelyoccluded by Layers 3 and 4 Layer 3 is visible so the Lfar

of the tile is 3 Since Layer 3 belongs to NWOZ primitivesthe FVP depth of the tile is its Lfar and a correspondingFVP-type that indicates that the FVP is a layer is stored

In the scenario presented in Figure 3b Layer 1 is visibleso the Lfar of the tile is 1 Since Layer 1 belongs to WOZprimitives the FVP depth corresponds to the tilersquos ZfarPrimitives with a depth value of 1 are occluded by primitiveswith smaller depth values while primitives with a depthvalue of 0 do not completely occlude primitives with a depthvalue of 05 Thus the Zfar and consequently the FVP depthof the tile is 05 The FVP-type of the tile is set to indicatethat the FVP is a Z value A primitive is labeled as occludedif one of the following two scenarios occurs

bull The FVP in the previous frame is NWOZ and the layerassigned to the primitive is lower than Lfar

bull The primitive and the FVP in the previous frame areWOZ and the primitiversquos Znear is farther than Zfar

IV REMOVING INNEFECTUAL COMPUTATIONS WITHEVR

In this section we present two optimizations that lever-age the presented EVR mechanism for early detection ofoccluded primitives to avoid ineffectual computations andmemory accesses in the Graphics Pipeline

A Overshading Reduction

Overshading occurs when a pixel is shaded multipletimes because several primitives overlap it If an opaqueprimitive writes into an already-shaded pixel the resourcesdevoted to the previous color computation have been wastedbecause it has no effect in the final image Note that someovershading cannot be avoided such as the one producedby translucent primitives As introduced before GPUs try toreduce overshading by employing an Early Depth Test whichavoids shading a fragment if a closer opaque fragmenthas already been processed Although this mechanism caneliminate a significant fraction of overshading it is heavilydependent on the order that fragments are processed becauseit can only discard fragments which are hidden by thosealready processed A direct solution to the overshadingproblem would be for the application to sort the opaqueprimitives in a front-to-back order However many of thesesoftware-based approaches require building costly spatialhierarchical data structures to render the scene from anysingle viewpoint They are only effective on ldquowalkthroughrdquoapplications where the entire scene is static and only theviewer moves through it because the overheads can beamortized over a large number of frames Furthermore suchapplication-level sorting is often challenging due to cyclicoverlaps among objects or objects containing geometry thatoccludes parts of the same object

Some applications perform a preliminary depth pre-pass(either in hardware or in software) where some or all ofthe geometry is rendered using a simple shader that onlywrites into the Z Buffer After that the actual render pass isexecuted but now having perfect or near-perfect visibilityinformation in the Z Buffer which greatly increases thenumber of fragments discarded by the depth test Despitethe improved efficacy of the depth test the overhead ofthe additional render pass is very high and often offsets itspotential benefits

In this paper we propose to use the speculative visibilitydetermination mechanism described in Section III to dynam-ically reorder opaque primitives so as to render primitivesthat are likely to be occluded after primitives that are likelyto be visible without the need of an additional render passThe reordering is performed in the Polygon List Builderstage when primitives are sorted into tiles In the baselineconfiguration for each primitive the Parameter Buffer isupdated as follows the primitiversquos attributes are stored inmemory and a pointer to those attributes is written into theDisplay List of each tile Then whenever a tile is renderedits Display List is accessed and the pointers to primitivesare dereferenced to access their attributes to rasterize them

The proposed reordering mechanism divides the DisplayList of every tile into two lists Tiles are rendered by fetchinginitially all the primitives from the first list and then theprimitives from the second list Whenever a primitive issorted into a tile its attributes are stored into the ParameterBuffer the same way as in the baseline The pointer tothose attributes on the other hand is stored on one of thelists depending on the type of primitive and its predictedvisibility according to Algorithm 1 This algorithm only

Algorithm 1 Reordering Algorithm based on FVPif Primitive is WOZ then

if Predicted visible thenAppend into First List

elseAppend into Second List

end ifelse NWOZ Primitive

if Second List not empty thenMove Second List to the end of the First List

end ifAppend into First List

end if

reorders opaque WOZ primitives among themselves whilepreserving the order of NWOZ primitives against themselvesand against WOZ primitives Reordering WOZ primitivesdoes not incur in rendering errors NWOZ primitives arenot reordered and all WOZ primitives perform the depthtest as usual which maintains the correctness of the resultproduced by such primitives regardless of the order in which

they are rasterized

2nd Batch1st Batch 4th Batch 3rd Batch

WOZ Primitives Predicted Occluded WOZ Primitives Predicted VisibleNWOZ Primitives

(a) Primitives overlapping a tile divided into 4 batches according to theirprimitive type

1st Batch

List 1 List 2

2nd Batch

3rd Batch

4th Batch

(b) WOZ primitives that are predicted occluded are stored on the SecondList while all other primitives are stored in the First List

Figure 4 Reordering algorithm example

To illustrate Algorithm 1 let us consider Figure 4ashowing 4 different batches of primitives of a particular tileThe two WOZ batches include primitives that are predictedto be visible and primitives that are predicted to be occludedFigure 4b shows how they are reordered

The first processed batch is an NWOZ batch No actionsare performed with the second list since it is empty and allthe primitives in the batch are appended to the first list Nextthere is a WOZ batch whose primitives are appended to thefirst list if they are predicted to be visible in the tile andappended to the second list otherwise When the followingNWOZ batch arrives all the primitives in the second list aremoved to the end of the first list and then the primitives ofthe batch are appended to the first list Finally another WOZbatch is processed whose primitives are again appended tothe two lists according to their predicted visibility

This reordering technique is highly effective at reducingovershading because if the visibility prediction is correct theearly depth test is able to discard more fragments whichreduces the amount of computation and memory accessesdevoted to occluded fragments Note that this scheme doesnot introduce any error as commented above Visibilitymispredictions simply imply a loss of culling effectivenessin the Early Depth Test

B Rendering Elimination Improvement

Rendering Elimination [1] is a technique that detects tilesthat produce the same color across adjacent frames Todo so when primitives are sorted into tiles at the end ofthe Geometry Pipeline a signature per tile is incrementallycomputed on-the-fly with the attributes of all primitivesoverlapping each tile Then when the Raster Pipeline startsprocessing a tile its signature computed for the current

Table IVISIBILITY CASUISTRY

Scenario Frame i Frame i+1

A Visible VisibleB Visible OccludedC Occluded OccludedD Occluded Visible

frame is compared against the signature computed in theprevious frame if both signatures match the tile is notrendered since it will produce the same colors as in theprevious frame Rendering Elimination requires all attributesfrom all primitives of a tile to be exactly the same as inthe previous frame to detect redundancy However in thecase that only occluded primitives change their attributesthe tilersquos colors will be the same as for the precedingframe making Rendering Elimination not able to detect andeliminate such frame-to-frame redundancy In this paperwe also propose using the approximate visibility resolutionmechanism described in Section III to compute signaturesonly with visible primitives so as to improve the effective-ness of Rendering Eliminationrsquos tile redundancy detection

In the baseline operation of Rendering Elimination alookup table named Signature Buffer stores one CRC32per tile Whenever a primitive is sorted the CRC32 ofthe attributes of its vertices is computed Then for all thetiles that the primitive overlaps the corresponding SignatureBuffer entry is read and updated by combining the CRC32value of the entry with the CRC32 value of the sortedprimitive

Using the visibility prediction scheme proposed in Sec-tion III we propose to extend the Rendering Eliminationtechnique as follows For each sorted primitive its depthis compared against the depth of the FVP in the previousframe for each tile it overlaps If the primitive is predictedto be occluded in a tile the Signature Buffer entry forthat tile is not updated with the CRC32 of the primitiveAs it will be shown in the Results section utilizing theFVP depth allows for a significant increase in redundanttile detection Moreover the proposed optimization doesnot produce any rendering errors Table I presents the fourpossibilities regarding the resolved visibility of a primitive(either visible or occluded) across two consecutive frames

For scenarios A and B the optimization behaves likethe baseline Rendering Elimination since the primitive wasvisible in the tile in Frame i it is considered for the signatureof the tile in Frame i + 1 regardless of its final visibilityNote that in scenario B the primitive will be occluded andtherefore will not be considered in the signature in Framei+ 2 This is the case for scenarios C and D

Scenario C is the case that improves over the baselinesince the occluded primitive does not affect the final colorsof the tile not considering the primitive for the signature

enhances redundancy detection while not generating errorsFinally scenario D does not cause rendering errors be-

cause for a primitive P (occluded in Frame i) to be visiblein Frame i+1 at least one of the following two conditionsmust hold

i) P has moved closer to the camera than the farthestdepth of the tile in the previous frame In that case P will beadded to the signature of the tile Since it was not includedin the signature of the previous frame the signatures willdiffer and the tile will be rendered

ii) All the primitives that occluded P have moved (orare not rendered) so that in Frame i + 1 they do nottotally occlude P In that case the attributes of the occluderprimitives must have changed and the signature will bedifferent even if P is not considered for the signature thetile will be rendered

V IMPLEMENTATION

In this section we describe the extra hardware requiredto implement the proposed early visibility resolution mecha-nism which basically consists of additional units to computeand store the FVP (farthest visible point) for all the tiles inthe frame Figure 5 shows how they are integrated into aTBR GPU

PrimitiveAssembly

PrimitiveAssembly

RasterizerRasterizerFragmentProcessing

FragmentProcessing

EarlyDepth

EarlyDepth

CommandProcessor

CommandProcessor

VertexProcessing

VertexProcessing

VertexFetcher

VertexFetcher

ColorBuffer

ColorBuffer

DepthBuffer

DepthBufferTexturesTextures

Hardware

PolygonList

Builder

PolygonList

Builder

TileScheduler

TileScheduler

ParameterBuffer

ParameterBuffer

BlendingBlending

LayerBuffer

LayerBuffer

Memory New Buffer

FVPTable

FVPTable

LayerGenerator

LayerGenerator

Figure 5 Graphics Pipeline including the structures needed to implementFVP computation

A Layer Generator Table

As discussed in Section III layers are tracked to emulatedepth among NWOZ primitives Assigning a layer identifierto a primitive requires to address the following issues

First since the layer identifier is intended to count thenumber of objects (draw commands) whose primitives haveoverlapped a given tile so far each tile must have itsindependent layer counter Of course for a given tile allthe primitives of the same command are assigned the samelayer identifier although that layer may differ from one tileto another

Second since WOZ primitives update their depth into theZ Buffer layer identifiers do not provide any informationamong primitives in a WOZ batch the same identifier canbe assigned to all WOZ primitives in a batch for a giventile

We propose to employ a small on-chip LUT whichwe call Layer Generator Table in order to manage theassociation of layer identifiers to primitives This table hasone entry per tile and each entry contains three fields

1) Last identifier of a command that produced a primitivethat overlapped the tile

2) Last layer assigned to a primitive that overlapped thetile

3) Last type of primitive (WOZNWOZ) that overlappedthe tile

Using the Layer Generator Table (LGT) we can assign alayer to every primitive in all the tiles it overlaps during thePolygon List Builder stage Whenever a primitive is sortedinto a tile the LGT entry for that tile is checked If the storedcommand identifier is the same as the primitiversquos commandidentifier it means that the primitive belongs to the samelayer as the last primitive sorted into that tile Consequentlythe primitive is assigned the layer stored in the entry Aftersorting a primitive into a tile it updates the last type ofprimitive field in the LGT (a binary value NWOZ or WOZ)

On the other hand if the stored command identifieris different to the primitiversquos command the layer maybe increased depending on the type of primitive NWOZprimitives always increase the layer number whereas forWOZ primitives the layer is only increased if the previousprimitive was NWOZ Finally the LUT entry is updatedwith the new command identifier and the new layer value ifthey have changed

The layer identifier of a primitive is stored in the Param-eter Buffer as any other attribute This way layers can beassigned to all the fragments of the primitive at rasterizationtime

B Layer Buffer

The farthest visible layer of a tile can be obtained bycomputing the minimum visible layer of all its pixels Sincetiles are relatively small (eg 16x16 pixels) we can use anon-chip buffer to keep track of per-pixel information for anentire tile This buffer which we call the Layer Buffer hasone entry for every pixel of the tile being rendered (just asthe Z Buffer or the Color Buffer) that stores the visible layerfor that pixel

The Layer Buffer is updated during the Blending stagewhen the final fragment opacity is already determined Todetect opacity we use the same alpha value that fragmentsemploy to blend with colors previously written in the ColorBuffer If the alpha factor is exactly 1 the fragment is opaqueand its layer is written into the Layer Buffer Otherwise

since the fragment is translucent and does not completelyocclude layers behind it the Layer Buffer is not updated

During the blending stage each fragment of a WOZprimitive stores its layer identifier in a register named ZR sothat it identifies the layer of the last visible WOZ primitiveand may be used to distinguish at the end of rendering atile if its FVP corresponds to a WOZ or a NWOZ primitiveie the FVP-type of the tile The value of ZR is comparedto Lfar when the tile finishes rendering if the two valuesare equal the FVP-type of the tile is WOZ Otherwise it isNWOZ

C FVP Table

In order to predict if a primitive is likely to be visible ina tile we use the tilersquos FVP depth of the previous frame sothe entire set of per-tile FVP depths must be stored Suchinformation is maintained in a structure that we call FVPTable The FVP Table has one entry per tile with eachentry containing the previous framersquos FVP depth for that tileEach entry in the table also stores the FVP-type to indicatewhether the type of data stored is a Z or a layer identifier

Whenever a tile finishes rendering its FVP-type is de-termined If the FVP depth belongs to a NWOZ primitivethe FVP Table entry for the tile is updated with Lfar settingits FVP-type bit Otherwise the FPV entry for the tile isupdated with Zfar and the entryrsquos FVP-type bit is cleared

VI EVALUATION METHODOLOGY

A Simulator infrastructure

We employ the Teapot simulation framework [6] to eval-uate our proposal Teapot runs unmodified Android appli-cations for mobile platforms and obtains GPU performanceand energy consumption statistics Table II lists the parame-ters used in the simulations in order to model an architectureresembling the ARM Mali-450 GPU [2] the most widelyused GPU architecture nowadays with almost 20 of themobile GPU market [3]

The traces that feed the Teapot cycle-accurate simulatorare obtained via a two-step process First an Android appli-cation is run in the Android emulator [7] and every OpenGLcommand sent to the GPU is intercepted and stored in a fileSecond those OpenGL commands are fed to the softwarerenderer included in Gallium3D [8] which is instrumentedto generate a trace containing all the information neededto guide the cycle accurate execution such as vertex datashader instructions or memory addresses of the differentstages of the Graphics Pipeline For each application wesimulate 60 consecutive frames from the original applicationrun

McPAT [9] is used to estimate the energy consumptionof the GPU All the additional hardware required for theproposed technique (Layer Generator Table FVT tableLayer Buffer comparators and registers) is modelled usingMcPATrsquos components (SRAMs Registers MUXes XORs)

Table IIGPU SIMULATION PARAMETERS

Baseline GPU Parameters

Tech Specs 400 MHz 1 V 32 nmScreen Resolution 1196x768Tile Size 16x16 pixels

Main Memory

Latency 50-100 cyclesBandwidth 4 Bcycle (dual channel LPDDR3)Size 1 GB

Queues

Vertex (2x) 16 entries 136 bytesentryTriangle Tile 16 entries 388 bytesentryFragment 64 entries 233 bytesentry

Caches

Vertex Cache 64 bytesline 2-way associative4 KB 1 bank 1 cycle

Texture Caches (4x) 64 bytesline 2-way associative8 KB 1 bank 1 cycle

Tile Cache 64 bytesline 8-way associative128 KB 8 banks 1 cycle

L2 Cache 64 bytesline 8-way associative256 KB 8 banks 2 cycles

Color Buffer 64 bytesline 1-way associative1 KB 1 bank 1 cycle

Depth Buffer 64 bytesline 1-way associative1 KB 1 bank 1 cycle

Non-programmable stages

Primitive assembly 1 trianglecycleRasterizer 16 attributescycleEarly Z test 32 in-flight quad-fragments 1 Depth Buffer

Programmable stages

Vertex Processor 1 vertex processorFragment Processor 4 fragment processors

Additional hardware

Layer Generator Table 3600 entries 3 bytesentryFVP Table 3600 entries 4 bytesentryLayer Buffer 64 bytesline 1-way associative

1 KB 1 bank 1 cycle

Regarding system memory Teapot employs DRAMSim2[10]

B Benchmarks

Table III presents the benchmarks employed to test theproposed approach which correspond to twenty unmodifiedAndroid graphics applications All of these applicationshave millions of downloads according to Google Play [11]with some of them surpassing 500 million downloads Theset of benchmarks includes games of the most populargenres in the mobile segment [12] such as puzzle arcadeand simulation The benchmarks also contain a variety ofworkloads completely 2D scenes such as cde or wmwscenes with simple 3D models such as ata or tib) and

scenes with more sophisticated models such as 300 or mstApplications classified as 3D contain both WOZ and NWOZprimitives while applications classified as 2D only containNWOZ primitives

Table IIIBENCHMARK SUITE

Benchmark Alias Genre Type

300 Seize your glory 300 Action 3DAir Attack ata Arcade 3DCrazy Snowboard csn Arcade 3DModern Strike mst First Person Shooter 3DTemple Run ter Platform 3DTigerball tib Physics Puzzle 3DAngry Birds abi Puzzle 2DArmymen arm Strategy 2DAvenger Legends ale Strategy 2DCandy Crush Saga ccs Puzzle 2DCastle Defense cde Tower Defense 2DClash of Clans coc MMO Strategy 2DCut the Rope ctr Puzzle 2DDude Perfect dpe Puzzle 2DHayday hay Simulation 2DHopeless hop Action Survival 2DMagic Touch mto Arcade 2DRedsun red Strategy 2DWherersquos my water wmw Puzzle 2DWorld of goo wog Physics Puzzle 2D

VII EXPERIMENTAL RESULTS

Figure 6 shows the energy consumption of the GPU-Memory system normalized to the Baseline GPU for our setof benchmarks The proposed optimizations that leverage anearly prediction of the visibility achieve a 43 reduction ofenergy consumption on average Energy savings are obtainedin all benchmarks with maximums of more than 80(cde dpe) Figure 7 shows the execution time divided intoGeometry and Raster pipelines normalized to the baselineOn average the proposed techniques achieve 39 executiontime reduction with maximums of more than 70 (ccs cdedpe)

057

01

02

03

04

05

06

07

08

09

1

No

rmal

ize

d e

ne

rgy

con

sum

pti

on

Overhead by additional accesses Overhead by additional hardware

Figure 6 Energy consumption of our EVR proposal normalized to theBaseline GPU

The energy overheads are mainly due to additional writesto the Parameter Buffer to store the layer identifiers Thisoverhead is quite moderate 21 on average as it can be

061

0

01

02

03

04

05

06

07

08

09

1

No

rmal

ize

d e

xecu

tio

n t

ime

Geometry Geometry overhead Raster

Figure 7 Execution time of our EVR proposal normalized to the BaselineGPU

seen in Figure 6 Figure 6 also illustrates that the addi-tional hardware added by the proposed mechanism incursin only 12 energy consumption overhead on average thestructures needed to manage the FVP information (LayerGenerator Table Layer Buffer and FVP Table) generate05 additional static and dynamic energy consumptionwhile the LUTs needed to implement Rendering Elimina-tion contribute to an additional 07 energy consumptionThe computation of Rendering Eliminationrsquos tile signaturesincurs in time overhead in the Geometry Pipeline whenevera primitive overlaps a large number of tiles since thepipeline is stalled waiting for all signatures to be sequentiallyupdated Figure 7 reports such overheads in execution timewhich on average represents 05 of the total

300 ata csn mst ter tib Average

0

1

2

3

4

5

6

Shad

ed

fra

gme

nts

pe

r p

ixe

l

Baseline EVR Oracle

Figure 8 Comparison of the number of shaded fragments per pixel amongthe baseline GPU our EVR proposal and an oracle

These important reductions in energy consumption andexecution time are mainly produced by avoiding the process-ing of ineffectual fragments (fragments that are occluded orare the same as in the previous frame) Figure 8 shows thenumber of fragments shaded per pixel using the proposedearly visibility resolution mechanism to reorder primitives(EVR) compared to the baseline for our set of 3D bench-marks We also compare our scheme with an oracle approach(which ideally assumes that the Z Buffer is initialized withthe final visibility of the tile ndashthe final depth valuesndash beforeit is executed) EVR significantly reduces (20) the numberof vainly shaded fragments and its results are close to thoseobtained by an oracle approach EVR cannot reach the oraclebecause of its approximate nature First it uses visibilityinformation of the previous frame which may have changed

Second it estimates visibility at a primitive-level while theoracle resolves visibility at the finest possible granularityfragment level

Moreover a large fraction of tiles are detected to beredundant and its execution is completely bypassed avoidingnot only the Fragment Shader stage for all their fragmentsbut also the rest of the stages of the Raster Pipeline forthose tiles Figure 9 shows the percentage of detectedredundant tiles ndashproducing the same colors as the previousframendash for our set of benchmarks Results are shown for thebaseline Rendering Elimination (RE) the proposed EVR-aided Rendering Elimination (EVR) and an oracle setup thatcan perfectly identify all tiles of a frame that are equal tothose of the previous frame

0

10

20

30

40

50

60

70

80

90

100

Det

ect

ed

eq

ual

tile

s

EVR RE Oracle

Figure 9 Percentage of detected equal tiles by EVR compared to REand an oracle

On average EVR avoids the rendering of 54 of the tilesreducing 5 more tiles than the baseline RE Predicting oc-cluded primitives and not adding them to the tilersquos signatureallows the detection of equal tiles in benchmarks in whichRE was hardly effective such as 300 or mst The majorityof these tiles that are identified as redundant corresponds toportions of the screen in which WOZ primitives are coveredby NWOZ primitives in the form of a HUD In most casesthe scene contains objects that are in motion but completelyoccluded by NWOZ geometry The layer-based visibilityscheme allows EVR to identify additional redundant tilesin benchmarks with a high degree of redundancy detectedby RE such as cde or mto In some applications such as hayor wmw the additional tiles eliminated exceeds 10 witha maximum of 30

The additional redundant tiles detected results in anaverage 10 reduction of energy consumption comparedto the baseline RE as presented in Figure 10 The earlyvisibility resolution incurs in some overheads which aregrouped together in the figure In the Geometry Pipeline theLayer Generator and FVP tables are accessed to generate alayer identifier which is stored in the Parameter Buffer Inthe Raster Pipeline the layer identifiers are read and writteninto the Layer Buffer When a tile finishes its rendering itsFVP is computed by accessing the Z and Layer Buffers andthe result is stored in the FVP Table Although the required

09

02

03

04

05

06

07

08

09

1

Ener

gy c

on

sum

pti

on

no

rmal

ized

to

RE

Overhead by FVP Computation

Figure 10 Energy consumption of our EVR proposal normalized to RE

sequential check of the two tables for each primitive andeach tile to which it is mapped could incur in some timeoverhead it is more than offset by the reduction in numberof primitives that can skip the signature computation stepsince they are occluded This is shown in Figure 11 whichcompares execution time broken down into Geometry andRaster Pipelines for the Baseline GPU RE and our proposedEVR approach for early visibility resolution Note that REhas to read the temporary hashes held in the Signature Bufferfor all the tiles that a primitive overlaps shift them as manybytes as the size of the primitive and finally combine themwith the hash of the primitive to produce a new signature forthe tile This process is avoided in our scheme if a primitiveis determined to be occluded in a tile since EVR marks it notto be included into the tilersquos signature The only exceptionwhere our EVR scheme does not reduce Geometry cycles ishop a benchmark that has very few primitives concentratedin a reduced amount of tiles Consequently the averagenumber of primitives to combine into the signature of a tile issmall limiting the benefits of occluded primitive detectionOn average our EVR mechanism reduces the execution timein the Geometry Pipeline by 4 with respect to RE

Moreover Rendering Elimination may induce time andenergy overheads in benchmarks where not enough redun-dant tiles are detected to offset the signature computationsuch as 300 or mst On the other hand our scheme is moreeffective at detecting redundant tiles and for non-redundanttiles specially in 3D benchmarks the primitive reordering in-creases the efficiency of the Early Depth Test which reducesthe amount of computations in the fragment processors Thisresults in overall speedups for all benchmarks

VIII RELATED WORK

Occlusion culling is a fundamental problem in computergraphics with an extensive literature spanning more thanthree decades In this section we focus on the most influ-ential works and the ones most related to our proposal

The Z Buffer [4] is the de facto standard to resolvevisibility due to its effectiveness and low implementationcost The Hierarchical Z Buffer [13] is a variation of thebaseline technique in which a depth pyramid is used to testvisibility The base level of the pyramid is the Z Buffer

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

300 ata csn mst ter tib abi arm ale ccs cde coc ctr dpe hay hop mto red wmw wog AVG

0

02

04

06

08

1

No

rmal

ize

d e

xecu

tio

n t

ime

Geometry Raster

Figure 11 Execution time comparison of our EVR proposal and RE against the baseline GPU

and higher levels are constructed by combining the depthof four pixels at the next lower level typically by choosingthe farthest one Entire primitives can be discarded withoutaccessing the Z Buffer by comparing their nearest depthagainst the values in higher levels in the pyramid OurEVR proposal also compares the depth of primitives toa FVP depth which would correspond to the top of thepyramid of the Hierarchical Z Buffer However the FVPdepth contains final visibility information which allowsunlike the Z pyramid to detect primitives that will beoccluded by others processed later Moreover the FVP depthincludes more information than just the top of the Z pyramidallowing the detection of occluded NWOZ primitives that donot use the Z buffer

Z-Prepass [14] draws the scene in two steps first thegeometry is rendered using simple fragment shaders onlyto quickly fill the Z Buffer Later the geometry is renderedagain with proper shaders but now with perfect visibilityinformation in-place so that all occluded fragments can bediscarded This additional render pass incurs in significantoverheads which may not always be offset by the increase inthe fragments discarded in the Early Depth Test By workingat a coarser granularity (primitive instead of fragment) EVRdoes not need to perform the pre-pass but still achievesresults comparable to having complete visibility information

The concept of layers has been previously adopted inthe context of occlusion culling most notably in DepthPeeling [15] an algorithm that renders geometry multipletimes peeling off the surface layer at each pixel in eachpass Recently Andersson et al [16] leveraged a two-layer representation of depths to avoid bandwidth spent inupdating the Hierarchical Z Buffer while in the work ofScheckel and Kolb [17] layers are used in combinationwith the alpha parameter to completely cull transparentfragments Unlike EVR these approaches cannot combinevisibility information of both WOZ and NWOZ primitivesfor a better visibility determination

Computing visibility at a fragment level (known as image-precision [18]) is useful to solve certain problems suchas circular dependencies However resolving visibility ata coarser grain could reduce the number of computations

needed Hardware occlusion queries [19] are a feature thatallow the user to query simple geometry (such as thebounding volumes) against the current contents of the ZBuffer The query counts the number of fragments thatpass the Z Test and the result allows the application toavoid rendering entire objects at the expense of CPU-GPUsynchronization Furthermore as with the Early Depth Testin order for occlusion queries to perform well both objectsand queries must be sent in front-to-back order EVR istransparent to the application in both axis it does not requireneither synchronization nor ordering

Multiple works reduce overshading by means of reorder-ing the primitives that make up a scene Govindaraju et al[20] propose an algorithm to sort non-overlapping objectsin either front-to-back or back-to front order from a givenviewpoint In the work of Chen et al [21] static objectsare preprocessed in order to create a depth-sorted list ofprimitives for every possible viewpoint The approach ofHan and Sander [22] also preprocesses objects to createseveral sorted lists that are indexed at runtime to ensureoptimal order but they consider movement by taking intoaccount not only viewpoints but also several key framesWeber and Stamminger [23] use a graph representationof dependencies in animated scenes with a fixed camerato sort primitives accordingly and leverage frame-to-framecoherence to merge different graphs and keep the overallstructure manageable VRO [24] also takes advantage oftemporal coherence to reorder objects entirely in hardwareand reduce overshading Unlike these approaches EVR isapplied at a finer granularity (primitive instead of object)does not need to perform any preprocess and can also beemployed in interactive scenes not just animated ones

IX CONCLUSIONS

We have presented a mechanism to determine visibilityin early stages of the Graphics Pipeline based on exploitingframe coherence Since consecutive frames tend to be verysimilar we use the information of a frame to estimate thevisibility for the following one

The proposed technique collects the depth of the farthestvisible primitive of every tile whenever its rendering processis complete For each overlapped tile the depth of a primitive

is compared against the depth stored for that tile in thepreceding frame If it is farther the primitive is occluded

This paper demonstrates the benefits of early visibilityprediction to remove ineffectual computations by increasingthe effectiveness of the Early Z Test a commonly usedtechnique in contemporary GPUs and Rendering Elimina-tion a recently proposed technique to exploit redundantcomputations The former works at pixel granularity and thelatter works at tile granularity

Using the predicted visibility information opaque prim-itives whose visibility is resolved using the Z Buffer arereordered such that primitives predicted as visible are ren-dered first which avoids the shading of occluded fragmentsBesides primitives predicted to be occluded are not con-sidered when generating the signature used by RenderingElimination to identify tiles that are equal to the ones in theprevious frame That increases the number of tiles that areidentified as redundant and consequently whose renderingcan be avoided

Our technique provides average speedups of 39 andenergy savings of 43 for a set of commercial Android ap-plications The reorder mechanism achieves overshading re-ductions comparable to having a Z Buffer filled with perfectvisibility information without requiring any additional renderpass to compute depths On the other hand by improvingthe tile redundancy detection of Rendering Elimination theraster pipeline of the GPU skips the rendering of more thanhalf of the tiles on average

X ACKNOWLEDGEMENTS

This work has been partially supported by the Span-ish State Research Agency under grant TIN2016-75344-R (AEIFEDER EU) and by the Generalitat de Catalunyaunder the AGAUR-FI program

REFERENCES

[1] M Anglada E de Lucas J-M Parcerisa J L AragonP Marcuello and A Gonzalez ldquoRendering elimination Earlydiscard of redundant tiles in the graphics pipelinerdquo in Pro-ceedings of the 25th IEEE International Symposium on High-Performance Computer Architecture IEEE 2019

[2] ldquoArm mali-450 gpurdquo httpsdeveloperarmcomproductsgraphics-and-multimediamali-gpusmali-450-gpu accessedDecember 10 2018

[3] ldquoHardware gpu marketrdquo httphwstatsunity3dcommobilegpuhtml accessed December 10 2018

[4] E Catmull ldquoA subdivision algorithm for computer display ofcurved surfacesrdquo tech rep Utah University Salt Lake CitySchool of Computing 1974

[5] ldquoPainterrsquos algorithmrdquo httpswwwsiggraphorgeducationmaterialsHyperGraphscanlinevisibilitypainterhtmaccessed December 10 2018

[6] J-M Arnau J-M Parcerisa and P Xekalakis ldquoTeapot atoolset for evaluating performance power and image qualityon mobile graphics systemsrdquo in Proceedings of the 27thInternational ACM Conference on Supercomputing pp 37ndash46 ACM 2013

[7] ldquoAndroid studiordquo httpsdeveloperandroidcomstudioindexhtml accessed December 10 2018

[8] ldquoGallium3drdquo httpswwwfreedesktoporgwikiSoftwaregallium accessed December 10 2018

[9] S Li J H Ahn R D Strong J B Brockman D M Tullsenand N P Jouppi ldquoMcPAT An Integrated Power Area andTiming Modeling Framework for Multicore and ManycoreArchitecturesrdquo in Proceedings of the 42nd Annual IEEEACMInternational Symposium on Microarchitecture pp 469ndash4802009

[10] P Rosenfeld E Cooper-Balis and B Jacob ldquoDramsim2 Acycle accurate memory system simulatorrdquo IEEE ComputerArchitecture Letters vol 10 no 1 pp 16ndash19 2011

[11] ldquoGoogle playrdquo httpsplaygooglecom accessed December10 2018

[12] ldquoMobile game statisticsrdquo httpsmediumcomsm appintelnew-mobile-game-statistics-every-game-publisher-should-know-in-2016-f1f8eef64f66 accessed December 102018

[13] N Greene M Kass and G Miller ldquoHierarchical z-buffervisibilityrdquo in Proceedings of the 20th Annual Conference onComputer Graphics and Interactive Techniques pp 231ndash238ACM 1993

[14] ldquoEarly z rejectionrdquo httpssoftwareintelcomen-usarticlesearly-z-rejection-sample accessed December 10 2018

[15] C Everitt ldquoInteractive order-independent transparencyrdquoWhite paper NVIDIA vol 2 no 6 p 7 2001

[16] M Andersson J Hasselgren and T Akenine-MollerldquoMasked depth culling for graphics hardwarerdquo ACM Trans-actions on Graphics vol 34 no 6 p 188 2015

[17] S Scheckel and A Kolb ldquoMin-max mipmaps for efficient2d occlusion cullingrdquo in Conference on Computer GraphicsVisualization and Computer Vision 2016

[18] I E Sutherland R F Sproull and R A SchumackerldquoA characterization of ten hidden-surface algorithmsrdquo ACMComputing Surveys vol 6 no 1 pp 1ndash55 1974

[19] O Mattausch J Bittner and M Wimmer ldquoChc++ Coherenthierarchical culling revisitedrdquo in Computer Graphics Forumvol 27 pp 221ndash230 Wiley Online Library 2008

[20] N K Govindaraju M Henson M C Lin and D ManochaldquoInteractive visibility ordering and transparency computationsamong geometric primitives in complex environmentsrdquo inProceedings of the 2005 Symposium on Interactive 3D Graph-ics and Games pp 49ndash56 ACM 2005

[21] G Chen P V Sander D Nehab L Yang and L Hu ldquoDepth-presorted triangle listsrdquo ACM Transactions on Graphicsvol 31 no 6 p 160 2012

[22] S Han and P V Sander ldquoTriangle reordering for reducedoverdraw in animated scenesrdquo in Proceedings of the 20thACM SIGGRAPH Symposium on Interactive 3D Graphics andGames pp 23ndash27 ACM 2016

[23] C Weber and M Stamminger ldquoTopological triangle sortingfor predefined camera pathsrdquo in Proceedings of the Confer-ence on Vision Modeling and Visualization pp 153ndash160Eurographics Association 2016

[24] E De Lucas P Marcuello J-M Parcerisa and A GonzalezldquoVisibility rendering order Improving energy efficiency onmobile gpus through frame coherencerdquo IEEE Transactionson Parallel and Distributed Systems 2018

they are rasterized

2nd Batch1st Batch 4th Batch 3rd Batch

WOZ Primitives Predicted Occluded WOZ Primitives Predicted VisibleNWOZ Primitives

(a) Primitives overlapping a tile divided into 4 batches according to theirprimitive type

1st Batch

List 1 List 2

2nd Batch

3rd Batch

4th Batch

(b) WOZ primitives that are predicted occluded are stored on the SecondList while all other primitives are stored in the First List

Figure 4 Reordering algorithm example

To illustrate Algorithm 1 let us consider Figure 4ashowing 4 different batches of primitives of a particular tileThe two WOZ batches include primitives that are predictedto be visible and primitives that are predicted to be occludedFigure 4b shows how they are reordered

The first processed batch is an NWOZ batch No actionsare performed with the second list since it is empty and allthe primitives in the batch are appended to the first list Nextthere is a WOZ batch whose primitives are appended to thefirst list if they are predicted to be visible in the tile andappended to the second list otherwise When the followingNWOZ batch arrives all the primitives in the second list aremoved to the end of the first list and then the primitives ofthe batch are appended to the first list Finally another WOZbatch is processed whose primitives are again appended tothe two lists according to their predicted visibility

This reordering technique is highly effective at reducingovershading because if the visibility prediction is correct theearly depth test is able to discard more fragments whichreduces the amount of computation and memory accessesdevoted to occluded fragments Note that this scheme doesnot introduce any error as commented above Visibilitymispredictions simply imply a loss of culling effectivenessin the Early Depth Test

B Rendering Elimination Improvement

Rendering Elimination [1] is a technique that detects tilesthat produce the same color across adjacent frames Todo so when primitives are sorted into tiles at the end ofthe Geometry Pipeline a signature per tile is incrementallycomputed on-the-fly with the attributes of all primitivesoverlapping each tile Then when the Raster Pipeline startsprocessing a tile its signature computed for the current

Table IVISIBILITY CASUISTRY

Scenario Frame i Frame i+1

A Visible VisibleB Visible OccludedC Occluded OccludedD Occluded Visible

frame is compared against the signature computed in theprevious frame if both signatures match the tile is notrendered since it will produce the same colors as in theprevious frame Rendering Elimination requires all attributesfrom all primitives of a tile to be exactly the same as inthe previous frame to detect redundancy However in thecase that only occluded primitives change their attributesthe tilersquos colors will be the same as for the precedingframe making Rendering Elimination not able to detect andeliminate such frame-to-frame redundancy In this paperwe also propose using the approximate visibility resolutionmechanism described in Section III to compute signaturesonly with visible primitives so as to improve the effective-ness of Rendering Eliminationrsquos tile redundancy detection

In the baseline operation of Rendering Elimination alookup table named Signature Buffer stores one CRC32per tile Whenever a primitive is sorted the CRC32 ofthe attributes of its vertices is computed Then for all thetiles that the primitive overlaps the corresponding SignatureBuffer entry is read and updated by combining the CRC32value of the entry with the CRC32 value of the sortedprimitive

Using the visibility prediction scheme proposed in Sec-tion III we propose to extend the Rendering Eliminationtechnique as follows For each sorted primitive its depthis compared against the depth of the FVP in the previousframe for each tile it overlaps If the primitive is predictedto be occluded in a tile the Signature Buffer entry forthat tile is not updated with the CRC32 of the primitiveAs it will be shown in the Results section utilizing theFVP depth allows for a significant increase in redundanttile detection Moreover the proposed optimization doesnot produce any rendering errors Table I presents the fourpossibilities regarding the resolved visibility of a primitive(either visible or occluded) across two consecutive frames

For scenarios A and B the optimization behaves likethe baseline Rendering Elimination since the primitive wasvisible in the tile in Frame i it is considered for the signatureof the tile in Frame i + 1 regardless of its final visibilityNote that in scenario B the primitive will be occluded andtherefore will not be considered in the signature in Framei+ 2 This is the case for scenarios C and D

Scenario C is the case that improves over the baselinesince the occluded primitive does not affect the final colorsof the tile not considering the primitive for the signature

enhances redundancy detection while not generating errorsFinally scenario D does not cause rendering errors be-

cause for a primitive P (occluded in Frame i) to be visiblein Frame i+1 at least one of the following two conditionsmust hold

i) P has moved closer to the camera than the farthestdepth of the tile in the previous frame In that case P will beadded to the signature of the tile Since it was not includedin the signature of the previous frame the signatures willdiffer and the tile will be rendered

ii) All the primitives that occluded P have moved (orare not rendered) so that in Frame i + 1 they do nottotally occlude P In that case the attributes of the occluderprimitives must have changed and the signature will bedifferent even if P is not considered for the signature thetile will be rendered

V IMPLEMENTATION

In this section we describe the extra hardware requiredto implement the proposed early visibility resolution mecha-nism which basically consists of additional units to computeand store the FVP (farthest visible point) for all the tiles inthe frame Figure 5 shows how they are integrated into aTBR GPU

PrimitiveAssembly

PrimitiveAssembly

RasterizerRasterizerFragmentProcessing

FragmentProcessing

EarlyDepth

EarlyDepth

CommandProcessor

CommandProcessor

VertexProcessing

VertexProcessing

VertexFetcher

VertexFetcher

ColorBuffer

ColorBuffer

DepthBuffer

DepthBufferTexturesTextures

Hardware

PolygonList

Builder

PolygonList

Builder

TileScheduler

TileScheduler

ParameterBuffer

ParameterBuffer

BlendingBlending

LayerBuffer

LayerBuffer

Memory New Buffer

FVPTable

FVPTable

LayerGenerator

LayerGenerator

Figure 5 Graphics Pipeline including the structures needed to implementFVP computation

A Layer Generator Table

As discussed in Section III layers are tracked to emulatedepth among NWOZ primitives Assigning a layer identifierto a primitive requires to address the following issues

First since the layer identifier is intended to count thenumber of objects (draw commands) whose primitives haveoverlapped a given tile so far each tile must have itsindependent layer counter Of course for a given tile allthe primitives of the same command are assigned the samelayer identifier although that layer may differ from one tileto another

Second since WOZ primitives update their depth into theZ Buffer layer identifiers do not provide any informationamong primitives in a WOZ batch the same identifier canbe assigned to all WOZ primitives in a batch for a giventile

We propose to employ a small on-chip LUT whichwe call Layer Generator Table in order to manage theassociation of layer identifiers to primitives This table hasone entry per tile and each entry contains three fields

1) Last identifier of a command that produced a primitivethat overlapped the tile

2) Last layer assigned to a primitive that overlapped thetile

3) Last type of primitive (WOZNWOZ) that overlappedthe tile

Using the Layer Generator Table (LGT) we can assign alayer to every primitive in all the tiles it overlaps during thePolygon List Builder stage Whenever a primitive is sortedinto a tile the LGT entry for that tile is checked If the storedcommand identifier is the same as the primitiversquos commandidentifier it means that the primitive belongs to the samelayer as the last primitive sorted into that tile Consequentlythe primitive is assigned the layer stored in the entry Aftersorting a primitive into a tile it updates the last type ofprimitive field in the LGT (a binary value NWOZ or WOZ)

On the other hand if the stored command identifieris different to the primitiversquos command the layer maybe increased depending on the type of primitive NWOZprimitives always increase the layer number whereas forWOZ primitives the layer is only increased if the previousprimitive was NWOZ Finally the LUT entry is updatedwith the new command identifier and the new layer value ifthey have changed

The layer identifier of a primitive is stored in the Param-eter Buffer as any other attribute This way layers can beassigned to all the fragments of the primitive at rasterizationtime

B Layer Buffer

The farthest visible layer of a tile can be obtained bycomputing the minimum visible layer of all its pixels Sincetiles are relatively small (eg 16x16 pixels) we can use anon-chip buffer to keep track of per-pixel information for anentire tile This buffer which we call the Layer Buffer hasone entry for every pixel of the tile being rendered (just asthe Z Buffer or the Color Buffer) that stores the visible layerfor that pixel

The Layer Buffer is updated during the Blending stagewhen the final fragment opacity is already determined Todetect opacity we use the same alpha value that fragmentsemploy to blend with colors previously written in the ColorBuffer If the alpha factor is exactly 1 the fragment is opaqueand its layer is written into the Layer Buffer Otherwise

since the fragment is translucent and does not completelyocclude layers behind it the Layer Buffer is not updated

During the blending stage each fragment of a WOZprimitive stores its layer identifier in a register named ZR sothat it identifies the layer of the last visible WOZ primitiveand may be used to distinguish at the end of rendering atile if its FVP corresponds to a WOZ or a NWOZ primitiveie the FVP-type of the tile The value of ZR is comparedto Lfar when the tile finishes rendering if the two valuesare equal the FVP-type of the tile is WOZ Otherwise it isNWOZ

C FVP Table

In order to predict if a primitive is likely to be visible ina tile we use the tilersquos FVP depth of the previous frame sothe entire set of per-tile FVP depths must be stored Suchinformation is maintained in a structure that we call FVPTable The FVP Table has one entry per tile with eachentry containing the previous framersquos FVP depth for that tileEach entry in the table also stores the FVP-type to indicatewhether the type of data stored is a Z or a layer identifier

Whenever a tile finishes rendering its FVP-type is de-termined If the FVP depth belongs to a NWOZ primitivethe FVP Table entry for the tile is updated with Lfar settingits FVP-type bit Otherwise the FPV entry for the tile isupdated with Zfar and the entryrsquos FVP-type bit is cleared

VI EVALUATION METHODOLOGY

A Simulator infrastructure

We employ the Teapot simulation framework [6] to eval-uate our proposal Teapot runs unmodified Android appli-cations for mobile platforms and obtains GPU performanceand energy consumption statistics Table II lists the parame-ters used in the simulations in order to model an architectureresembling the ARM Mali-450 GPU [2] the most widelyused GPU architecture nowadays with almost 20 of themobile GPU market [3]

The traces that feed the Teapot cycle-accurate simulatorare obtained via a two-step process First an Android appli-cation is run in the Android emulator [7] and every OpenGLcommand sent to the GPU is intercepted and stored in a fileSecond those OpenGL commands are fed to the softwarerenderer included in Gallium3D [8] which is instrumentedto generate a trace containing all the information neededto guide the cycle accurate execution such as vertex datashader instructions or memory addresses of the differentstages of the Graphics Pipeline For each application wesimulate 60 consecutive frames from the original applicationrun

McPAT [9] is used to estimate the energy consumptionof the GPU All the additional hardware required for theproposed technique (Layer Generator Table FVT tableLayer Buffer comparators and registers) is modelled usingMcPATrsquos components (SRAMs Registers MUXes XORs)

Table IIGPU SIMULATION PARAMETERS

Baseline GPU Parameters

Tech Specs 400 MHz 1 V 32 nmScreen Resolution 1196x768Tile Size 16x16 pixels

Main Memory

Latency 50-100 cyclesBandwidth 4 Bcycle (dual channel LPDDR3)Size 1 GB

Queues

Vertex (2x) 16 entries 136 bytesentryTriangle Tile 16 entries 388 bytesentryFragment 64 entries 233 bytesentry

Caches

Vertex Cache 64 bytesline 2-way associative4 KB 1 bank 1 cycle

Texture Caches (4x) 64 bytesline 2-way associative8 KB 1 bank 1 cycle

Tile Cache 64 bytesline 8-way associative128 KB 8 banks 1 cycle

L2 Cache 64 bytesline 8-way associative256 KB 8 banks 2 cycles

Color Buffer 64 bytesline 1-way associative1 KB 1 bank 1 cycle

Depth Buffer 64 bytesline 1-way associative1 KB 1 bank 1 cycle

Non-programmable stages

Primitive assembly 1 trianglecycleRasterizer 16 attributescycleEarly Z test 32 in-flight quad-fragments 1 Depth Buffer

Programmable stages

Vertex Processor 1 vertex processorFragment Processor 4 fragment processors

Additional hardware

Layer Generator Table 3600 entries 3 bytesentryFVP Table 3600 entries 4 bytesentryLayer Buffer 64 bytesline 1-way associative

1 KB 1 bank 1 cycle

Regarding system memory Teapot employs DRAMSim2[10]

B Benchmarks

Table III presents the benchmarks employed to test theproposed approach which correspond to twenty unmodifiedAndroid graphics applications All of these applicationshave millions of downloads according to Google Play [11]with some of them surpassing 500 million downloads Theset of benchmarks includes games of the most populargenres in the mobile segment [12] such as puzzle arcadeand simulation The benchmarks also contain a variety ofworkloads completely 2D scenes such as cde or wmwscenes with simple 3D models such as ata or tib) and

scenes with more sophisticated models such as 300 or mstApplications classified as 3D contain both WOZ and NWOZprimitives while applications classified as 2D only containNWOZ primitives

Table IIIBENCHMARK SUITE

Benchmark Alias Genre Type

300 Seize your glory 300 Action 3DAir Attack ata Arcade 3DCrazy Snowboard csn Arcade 3DModern Strike mst First Person Shooter 3DTemple Run ter Platform 3DTigerball tib Physics Puzzle 3DAngry Birds abi Puzzle 2DArmymen arm Strategy 2DAvenger Legends ale Strategy 2DCandy Crush Saga ccs Puzzle 2DCastle Defense cde Tower Defense 2DClash of Clans coc MMO Strategy 2DCut the Rope ctr Puzzle 2DDude Perfect dpe Puzzle 2DHayday hay Simulation 2DHopeless hop Action Survival 2DMagic Touch mto Arcade 2DRedsun red Strategy 2DWherersquos my water wmw Puzzle 2DWorld of goo wog Physics Puzzle 2D

VII EXPERIMENTAL RESULTS

Figure 6 shows the energy consumption of the GPU-Memory system normalized to the Baseline GPU for our setof benchmarks The proposed optimizations that leverage anearly prediction of the visibility achieve a 43 reduction ofenergy consumption on average Energy savings are obtainedin all benchmarks with maximums of more than 80(cde dpe) Figure 7 shows the execution time divided intoGeometry and Raster pipelines normalized to the baselineOn average the proposed techniques achieve 39 executiontime reduction with maximums of more than 70 (ccs cdedpe)

057

01

02

03

04

05

06

07

08

09

1

No

rmal

ize

d e

ne

rgy

con

sum

pti

on

Overhead by additional accesses Overhead by additional hardware

Figure 6 Energy consumption of our EVR proposal normalized to theBaseline GPU

The energy overheads are mainly due to additional writesto the Parameter Buffer to store the layer identifiers Thisoverhead is quite moderate 21 on average as it can be

061

0

01

02

03

04

05

06

07

08

09

1

No

rmal

ize

d e

xecu

tio

n t

ime

Geometry Geometry overhead Raster

Figure 7 Execution time of our EVR proposal normalized to the BaselineGPU

seen in Figure 6 Figure 6 also illustrates that the addi-tional hardware added by the proposed mechanism incursin only 12 energy consumption overhead on average thestructures needed to manage the FVP information (LayerGenerator Table Layer Buffer and FVP Table) generate05 additional static and dynamic energy consumptionwhile the LUTs needed to implement Rendering Elimina-tion contribute to an additional 07 energy consumptionThe computation of Rendering Eliminationrsquos tile signaturesincurs in time overhead in the Geometry Pipeline whenevera primitive overlaps a large number of tiles since thepipeline is stalled waiting for all signatures to be sequentiallyupdated Figure 7 reports such overheads in execution timewhich on average represents 05 of the total

300 ata csn mst ter tib Average

0

1

2

3

4

5

6

Shad

ed

fra

gme

nts

pe

r p

ixe

l

Baseline EVR Oracle

Figure 8 Comparison of the number of shaded fragments per pixel amongthe baseline GPU our EVR proposal and an oracle

These important reductions in energy consumption andexecution time are mainly produced by avoiding the process-ing of ineffectual fragments (fragments that are occluded orare the same as in the previous frame) Figure 8 shows thenumber of fragments shaded per pixel using the proposedearly visibility resolution mechanism to reorder primitives(EVR) compared to the baseline for our set of 3D bench-marks We also compare our scheme with an oracle approach(which ideally assumes that the Z Buffer is initialized withthe final visibility of the tile ndashthe final depth valuesndash beforeit is executed) EVR significantly reduces (20) the numberof vainly shaded fragments and its results are close to thoseobtained by an oracle approach EVR cannot reach the oraclebecause of its approximate nature First it uses visibilityinformation of the previous frame which may have changed

Second it estimates visibility at a primitive-level while theoracle resolves visibility at the finest possible granularityfragment level

Moreover a large fraction of tiles are detected to beredundant and its execution is completely bypassed avoidingnot only the Fragment Shader stage for all their fragmentsbut also the rest of the stages of the Raster Pipeline forthose tiles Figure 9 shows the percentage of detectedredundant tiles ndashproducing the same colors as the previousframendash for our set of benchmarks Results are shown for thebaseline Rendering Elimination (RE) the proposed EVR-aided Rendering Elimination (EVR) and an oracle setup thatcan perfectly identify all tiles of a frame that are equal tothose of the previous frame

0

10

20

30

40

50

60

70

80

90

100

Det

ect

ed

eq

ual

tile

s

EVR RE Oracle

Figure 9 Percentage of detected equal tiles by EVR compared to REand an oracle

On average EVR avoids the rendering of 54 of the tilesreducing 5 more tiles than the baseline RE Predicting oc-cluded primitives and not adding them to the tilersquos signatureallows the detection of equal tiles in benchmarks in whichRE was hardly effective such as 300 or mst The majorityof these tiles that are identified as redundant corresponds toportions of the screen in which WOZ primitives are coveredby NWOZ primitives in the form of a HUD In most casesthe scene contains objects that are in motion but completelyoccluded by NWOZ geometry The layer-based visibilityscheme allows EVR to identify additional redundant tilesin benchmarks with a high degree of redundancy detectedby RE such as cde or mto In some applications such as hayor wmw the additional tiles eliminated exceeds 10 witha maximum of 30

The additional redundant tiles detected results in anaverage 10 reduction of energy consumption comparedto the baseline RE as presented in Figure 10 The earlyvisibility resolution incurs in some overheads which aregrouped together in the figure In the Geometry Pipeline theLayer Generator and FVP tables are accessed to generate alayer identifier which is stored in the Parameter Buffer Inthe Raster Pipeline the layer identifiers are read and writteninto the Layer Buffer When a tile finishes its rendering itsFVP is computed by accessing the Z and Layer Buffers andthe result is stored in the FVP Table Although the required

09

02

03

04

05

06

07

08

09

1

Ener

gy c

on

sum

pti

on

no

rmal

ized

to

RE

Overhead by FVP Computation

Figure 10 Energy consumption of our EVR proposal normalized to RE

sequential check of the two tables for each primitive andeach tile to which it is mapped could incur in some timeoverhead it is more than offset by the reduction in numberof primitives that can skip the signature computation stepsince they are occluded This is shown in Figure 11 whichcompares execution time broken down into Geometry andRaster Pipelines for the Baseline GPU RE and our proposedEVR approach for early visibility resolution Note that REhas to read the temporary hashes held in the Signature Bufferfor all the tiles that a primitive overlaps shift them as manybytes as the size of the primitive and finally combine themwith the hash of the primitive to produce a new signature forthe tile This process is avoided in our scheme if a primitiveis determined to be occluded in a tile since EVR marks it notto be included into the tilersquos signature The only exceptionwhere our EVR scheme does not reduce Geometry cycles ishop a benchmark that has very few primitives concentratedin a reduced amount of tiles Consequently the averagenumber of primitives to combine into the signature of a tile issmall limiting the benefits of occluded primitive detectionOn average our EVR mechanism reduces the execution timein the Geometry Pipeline by 4 with respect to RE

Moreover Rendering Elimination may induce time andenergy overheads in benchmarks where not enough redun-dant tiles are detected to offset the signature computationsuch as 300 or mst On the other hand our scheme is moreeffective at detecting redundant tiles and for non-redundanttiles specially in 3D benchmarks the primitive reordering in-creases the efficiency of the Early Depth Test which reducesthe amount of computations in the fragment processors Thisresults in overall speedups for all benchmarks

VIII RELATED WORK

Occlusion culling is a fundamental problem in computergraphics with an extensive literature spanning more thanthree decades In this section we focus on the most influ-ential works and the ones most related to our proposal

The Z Buffer [4] is the de facto standard to resolvevisibility due to its effectiveness and low implementationcost The Hierarchical Z Buffer [13] is a variation of thebaseline technique in which a depth pyramid is used to testvisibility The base level of the pyramid is the Z Buffer

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

300 ata csn mst ter tib abi arm ale ccs cde coc ctr dpe hay hop mto red wmw wog AVG

0

02

04

06

08

1

No

rmal

ize

d e

xecu

tio

n t

ime

Geometry Raster

Figure 11 Execution time comparison of our EVR proposal and RE against the baseline GPU

and higher levels are constructed by combining the depthof four pixels at the next lower level typically by choosingthe farthest one Entire primitives can be discarded withoutaccessing the Z Buffer by comparing their nearest depthagainst the values in higher levels in the pyramid OurEVR proposal also compares the depth of primitives toa FVP depth which would correspond to the top of thepyramid of the Hierarchical Z Buffer However the FVPdepth contains final visibility information which allowsunlike the Z pyramid to detect primitives that will beoccluded by others processed later Moreover the FVP depthincludes more information than just the top of the Z pyramidallowing the detection of occluded NWOZ primitives that donot use the Z buffer

Z-Prepass [14] draws the scene in two steps first thegeometry is rendered using simple fragment shaders onlyto quickly fill the Z Buffer Later the geometry is renderedagain with proper shaders but now with perfect visibilityinformation in-place so that all occluded fragments can bediscarded This additional render pass incurs in significantoverheads which may not always be offset by the increase inthe fragments discarded in the Early Depth Test By workingat a coarser granularity (primitive instead of fragment) EVRdoes not need to perform the pre-pass but still achievesresults comparable to having complete visibility information

The concept of layers has been previously adopted inthe context of occlusion culling most notably in DepthPeeling [15] an algorithm that renders geometry multipletimes peeling off the surface layer at each pixel in eachpass Recently Andersson et al [16] leveraged a two-layer representation of depths to avoid bandwidth spent inupdating the Hierarchical Z Buffer while in the work ofScheckel and Kolb [17] layers are used in combinationwith the alpha parameter to completely cull transparentfragments Unlike EVR these approaches cannot combinevisibility information of both WOZ and NWOZ primitivesfor a better visibility determination

Computing visibility at a fragment level (known as image-precision [18]) is useful to solve certain problems suchas circular dependencies However resolving visibility ata coarser grain could reduce the number of computations

needed Hardware occlusion queries [19] are a feature thatallow the user to query simple geometry (such as thebounding volumes) against the current contents of the ZBuffer The query counts the number of fragments thatpass the Z Test and the result allows the application toavoid rendering entire objects at the expense of CPU-GPUsynchronization Furthermore as with the Early Depth Testin order for occlusion queries to perform well both objectsand queries must be sent in front-to-back order EVR istransparent to the application in both axis it does not requireneither synchronization nor ordering

Multiple works reduce overshading by means of reorder-ing the primitives that make up a scene Govindaraju et al[20] propose an algorithm to sort non-overlapping objectsin either front-to-back or back-to front order from a givenviewpoint In the work of Chen et al [21] static objectsare preprocessed in order to create a depth-sorted list ofprimitives for every possible viewpoint The approach ofHan and Sander [22] also preprocesses objects to createseveral sorted lists that are indexed at runtime to ensureoptimal order but they consider movement by taking intoaccount not only viewpoints but also several key framesWeber and Stamminger [23] use a graph representationof dependencies in animated scenes with a fixed camerato sort primitives accordingly and leverage frame-to-framecoherence to merge different graphs and keep the overallstructure manageable VRO [24] also takes advantage oftemporal coherence to reorder objects entirely in hardwareand reduce overshading Unlike these approaches EVR isapplied at a finer granularity (primitive instead of object)does not need to perform any preprocess and can also beemployed in interactive scenes not just animated ones

IX CONCLUSIONS

We have presented a mechanism to determine visibilityin early stages of the Graphics Pipeline based on exploitingframe coherence Since consecutive frames tend to be verysimilar we use the information of a frame to estimate thevisibility for the following one

The proposed technique collects the depth of the farthestvisible primitive of every tile whenever its rendering processis complete For each overlapped tile the depth of a primitive

is compared against the depth stored for that tile in thepreceding frame If it is farther the primitive is occluded

This paper demonstrates the benefits of early visibilityprediction to remove ineffectual computations by increasingthe effectiveness of the Early Z Test a commonly usedtechnique in contemporary GPUs and Rendering Elimina-tion a recently proposed technique to exploit redundantcomputations The former works at pixel granularity and thelatter works at tile granularity

Using the predicted visibility information opaque prim-itives whose visibility is resolved using the Z Buffer arereordered such that primitives predicted as visible are ren-dered first which avoids the shading of occluded fragmentsBesides primitives predicted to be occluded are not con-sidered when generating the signature used by RenderingElimination to identify tiles that are equal to the ones in theprevious frame That increases the number of tiles that areidentified as redundant and consequently whose renderingcan be avoided

Our technique provides average speedups of 39 andenergy savings of 43 for a set of commercial Android ap-plications The reorder mechanism achieves overshading re-ductions comparable to having a Z Buffer filled with perfectvisibility information without requiring any additional renderpass to compute depths On the other hand by improvingthe tile redundancy detection of Rendering Elimination theraster pipeline of the GPU skips the rendering of more thanhalf of the tiles on average

X ACKNOWLEDGEMENTS

This work has been partially supported by the Span-ish State Research Agency under grant TIN2016-75344-R (AEIFEDER EU) and by the Generalitat de Catalunyaunder the AGAUR-FI program

REFERENCES

[1] M Anglada E de Lucas J-M Parcerisa J L AragonP Marcuello and A Gonzalez ldquoRendering elimination Earlydiscard of redundant tiles in the graphics pipelinerdquo in Pro-ceedings of the 25th IEEE International Symposium on High-Performance Computer Architecture IEEE 2019

[2] ldquoArm mali-450 gpurdquo httpsdeveloperarmcomproductsgraphics-and-multimediamali-gpusmali-450-gpu accessedDecember 10 2018

[3] ldquoHardware gpu marketrdquo httphwstatsunity3dcommobilegpuhtml accessed December 10 2018

[4] E Catmull ldquoA subdivision algorithm for computer display ofcurved surfacesrdquo tech rep Utah University Salt Lake CitySchool of Computing 1974

[5] ldquoPainterrsquos algorithmrdquo httpswwwsiggraphorgeducationmaterialsHyperGraphscanlinevisibilitypainterhtmaccessed December 10 2018

[6] J-M Arnau J-M Parcerisa and P Xekalakis ldquoTeapot atoolset for evaluating performance power and image qualityon mobile graphics systemsrdquo in Proceedings of the 27thInternational ACM Conference on Supercomputing pp 37ndash46 ACM 2013

[7] ldquoAndroid studiordquo httpsdeveloperandroidcomstudioindexhtml accessed December 10 2018

[8] ldquoGallium3drdquo httpswwwfreedesktoporgwikiSoftwaregallium accessed December 10 2018

[9] S Li J H Ahn R D Strong J B Brockman D M Tullsenand N P Jouppi ldquoMcPAT An Integrated Power Area andTiming Modeling Framework for Multicore and ManycoreArchitecturesrdquo in Proceedings of the 42nd Annual IEEEACMInternational Symposium on Microarchitecture pp 469ndash4802009

[10] P Rosenfeld E Cooper-Balis and B Jacob ldquoDramsim2 Acycle accurate memory system simulatorrdquo IEEE ComputerArchitecture Letters vol 10 no 1 pp 16ndash19 2011

[11] ldquoGoogle playrdquo httpsplaygooglecom accessed December10 2018

[12] ldquoMobile game statisticsrdquo httpsmediumcomsm appintelnew-mobile-game-statistics-every-game-publisher-should-know-in-2016-f1f8eef64f66 accessed December 102018

[13] N Greene M Kass and G Miller ldquoHierarchical z-buffervisibilityrdquo in Proceedings of the 20th Annual Conference onComputer Graphics and Interactive Techniques pp 231ndash238ACM 1993

[14] ldquoEarly z rejectionrdquo httpssoftwareintelcomen-usarticlesearly-z-rejection-sample accessed December 10 2018

[15] C Everitt ldquoInteractive order-independent transparencyrdquoWhite paper NVIDIA vol 2 no 6 p 7 2001

[16] M Andersson J Hasselgren and T Akenine-MollerldquoMasked depth culling for graphics hardwarerdquo ACM Trans-actions on Graphics vol 34 no 6 p 188 2015

[17] S Scheckel and A Kolb ldquoMin-max mipmaps for efficient2d occlusion cullingrdquo in Conference on Computer GraphicsVisualization and Computer Vision 2016

[18] I E Sutherland R F Sproull and R A SchumackerldquoA characterization of ten hidden-surface algorithmsrdquo ACMComputing Surveys vol 6 no 1 pp 1ndash55 1974

[19] O Mattausch J Bittner and M Wimmer ldquoChc++ Coherenthierarchical culling revisitedrdquo in Computer Graphics Forumvol 27 pp 221ndash230 Wiley Online Library 2008

[20] N K Govindaraju M Henson M C Lin and D ManochaldquoInteractive visibility ordering and transparency computationsamong geometric primitives in complex environmentsrdquo inProceedings of the 2005 Symposium on Interactive 3D Graph-ics and Games pp 49ndash56 ACM 2005

[21] G Chen P V Sander D Nehab L Yang and L Hu ldquoDepth-presorted triangle listsrdquo ACM Transactions on Graphicsvol 31 no 6 p 160 2012

[22] S Han and P V Sander ldquoTriangle reordering for reducedoverdraw in animated scenesrdquo in Proceedings of the 20thACM SIGGRAPH Symposium on Interactive 3D Graphics andGames pp 23ndash27 ACM 2016

[23] C Weber and M Stamminger ldquoTopological triangle sortingfor predefined camera pathsrdquo in Proceedings of the Confer-ence on Vision Modeling and Visualization pp 153ndash160Eurographics Association 2016

[24] E De Lucas P Marcuello J-M Parcerisa and A GonzalezldquoVisibility rendering order Improving energy efficiency onmobile gpus through frame coherencerdquo IEEE Transactionson Parallel and Distributed Systems 2018

enhances redundancy detection while not generating errorsFinally scenario D does not cause rendering errors be-

cause for a primitive P (occluded in Frame i) to be visiblein Frame i+1 at least one of the following two conditionsmust hold

i) P has moved closer to the camera than the farthestdepth of the tile in the previous frame In that case P will beadded to the signature of the tile Since it was not includedin the signature of the previous frame the signatures willdiffer and the tile will be rendered

ii) All the primitives that occluded P have moved (orare not rendered) so that in Frame i + 1 they do nottotally occlude P In that case the attributes of the occluderprimitives must have changed and the signature will bedifferent even if P is not considered for the signature thetile will be rendered

V IMPLEMENTATION

In this section we describe the extra hardware requiredto implement the proposed early visibility resolution mecha-nism which basically consists of additional units to computeand store the FVP (farthest visible point) for all the tiles inthe frame Figure 5 shows how they are integrated into aTBR GPU

PrimitiveAssembly

PrimitiveAssembly

RasterizerRasterizerFragmentProcessing

FragmentProcessing

EarlyDepth

EarlyDepth

CommandProcessor

CommandProcessor

VertexProcessing

VertexProcessing

VertexFetcher

VertexFetcher

ColorBuffer

ColorBuffer

DepthBuffer

DepthBufferTexturesTextures

Hardware

PolygonList

Builder

PolygonList

Builder

TileScheduler

TileScheduler

ParameterBuffer

ParameterBuffer

BlendingBlending

LayerBuffer

LayerBuffer

Memory New Buffer

FVPTable

FVPTable

LayerGenerator

LayerGenerator

Figure 5 Graphics Pipeline including the structures needed to implementFVP computation

A Layer Generator Table

As discussed in Section III layers are tracked to emulatedepth among NWOZ primitives Assigning a layer identifierto a primitive requires to address the following issues

First since the layer identifier is intended to count thenumber of objects (draw commands) whose primitives haveoverlapped a given tile so far each tile must have itsindependent layer counter Of course for a given tile allthe primitives of the same command are assigned the samelayer identifier although that layer may differ from one tileto another

Second since WOZ primitives update their depth into theZ Buffer layer identifiers do not provide any informationamong primitives in a WOZ batch the same identifier canbe assigned to all WOZ primitives in a batch for a giventile

We propose to employ a small on-chip LUT whichwe call Layer Generator Table in order to manage theassociation of layer identifiers to primitives This table hasone entry per tile and each entry contains three fields

1) Last identifier of a command that produced a primitivethat overlapped the tile

2) Last layer assigned to a primitive that overlapped thetile

3) Last type of primitive (WOZNWOZ) that overlappedthe tile

Using the Layer Generator Table (LGT) we can assign alayer to every primitive in all the tiles it overlaps during thePolygon List Builder stage Whenever a primitive is sortedinto a tile the LGT entry for that tile is checked If the storedcommand identifier is the same as the primitiversquos commandidentifier it means that the primitive belongs to the samelayer as the last primitive sorted into that tile Consequentlythe primitive is assigned the layer stored in the entry Aftersorting a primitive into a tile it updates the last type ofprimitive field in the LGT (a binary value NWOZ or WOZ)

On the other hand if the stored command identifieris different to the primitiversquos command the layer maybe increased depending on the type of primitive NWOZprimitives always increase the layer number whereas forWOZ primitives the layer is only increased if the previousprimitive was NWOZ Finally the LUT entry is updatedwith the new command identifier and the new layer value ifthey have changed

The layer identifier of a primitive is stored in the Param-eter Buffer as any other attribute This way layers can beassigned to all the fragments of the primitive at rasterizationtime

B Layer Buffer

The farthest visible layer of a tile can be obtained bycomputing the minimum visible layer of all its pixels Sincetiles are relatively small (eg 16x16 pixels) we can use anon-chip buffer to keep track of per-pixel information for anentire tile This buffer which we call the Layer Buffer hasone entry for every pixel of the tile being rendered (just asthe Z Buffer or the Color Buffer) that stores the visible layerfor that pixel

The Layer Buffer is updated during the Blending stagewhen the final fragment opacity is already determined Todetect opacity we use the same alpha value that fragmentsemploy to blend with colors previously written in the ColorBuffer If the alpha factor is exactly 1 the fragment is opaqueand its layer is written into the Layer Buffer Otherwise

since the fragment is translucent and does not completelyocclude layers behind it the Layer Buffer is not updated

During the blending stage each fragment of a WOZprimitive stores its layer identifier in a register named ZR sothat it identifies the layer of the last visible WOZ primitiveand may be used to distinguish at the end of rendering atile if its FVP corresponds to a WOZ or a NWOZ primitiveie the FVP-type of the tile The value of ZR is comparedto Lfar when the tile finishes rendering if the two valuesare equal the FVP-type of the tile is WOZ Otherwise it isNWOZ

C FVP Table

In order to predict if a primitive is likely to be visible ina tile we use the tilersquos FVP depth of the previous frame sothe entire set of per-tile FVP depths must be stored Suchinformation is maintained in a structure that we call FVPTable The FVP Table has one entry per tile with eachentry containing the previous framersquos FVP depth for that tileEach entry in the table also stores the FVP-type to indicatewhether the type of data stored is a Z or a layer identifier

Whenever a tile finishes rendering its FVP-type is de-termined If the FVP depth belongs to a NWOZ primitivethe FVP Table entry for the tile is updated with Lfar settingits FVP-type bit Otherwise the FPV entry for the tile isupdated with Zfar and the entryrsquos FVP-type bit is cleared

VI EVALUATION METHODOLOGY

A Simulator infrastructure

We employ the Teapot simulation framework [6] to eval-uate our proposal Teapot runs unmodified Android appli-cations for mobile platforms and obtains GPU performanceand energy consumption statistics Table II lists the parame-ters used in the simulations in order to model an architectureresembling the ARM Mali-450 GPU [2] the most widelyused GPU architecture nowadays with almost 20 of themobile GPU market [3]

The traces that feed the Teapot cycle-accurate simulatorare obtained via a two-step process First an Android appli-cation is run in the Android emulator [7] and every OpenGLcommand sent to the GPU is intercepted and stored in a fileSecond those OpenGL commands are fed to the softwarerenderer included in Gallium3D [8] which is instrumentedto generate a trace containing all the information neededto guide the cycle accurate execution such as vertex datashader instructions or memory addresses of the differentstages of the Graphics Pipeline For each application wesimulate 60 consecutive frames from the original applicationrun

McPAT [9] is used to estimate the energy consumptionof the GPU All the additional hardware required for theproposed technique (Layer Generator Table FVT tableLayer Buffer comparators and registers) is modelled usingMcPATrsquos components (SRAMs Registers MUXes XORs)

Table IIGPU SIMULATION PARAMETERS

Baseline GPU Parameters

Tech Specs 400 MHz 1 V 32 nmScreen Resolution 1196x768Tile Size 16x16 pixels

Main Memory

Latency 50-100 cyclesBandwidth 4 Bcycle (dual channel LPDDR3)Size 1 GB

Queues

Vertex (2x) 16 entries 136 bytesentryTriangle Tile 16 entries 388 bytesentryFragment 64 entries 233 bytesentry

Caches

Vertex Cache 64 bytesline 2-way associative4 KB 1 bank 1 cycle

Texture Caches (4x) 64 bytesline 2-way associative8 KB 1 bank 1 cycle

Tile Cache 64 bytesline 8-way associative128 KB 8 banks 1 cycle

L2 Cache 64 bytesline 8-way associative256 KB 8 banks 2 cycles

Color Buffer 64 bytesline 1-way associative1 KB 1 bank 1 cycle

Depth Buffer 64 bytesline 1-way associative1 KB 1 bank 1 cycle

Non-programmable stages

Primitive assembly 1 trianglecycleRasterizer 16 attributescycleEarly Z test 32 in-flight quad-fragments 1 Depth Buffer

Programmable stages

Vertex Processor 1 vertex processorFragment Processor 4 fragment processors

Additional hardware

Layer Generator Table 3600 entries 3 bytesentryFVP Table 3600 entries 4 bytesentryLayer Buffer 64 bytesline 1-way associative

1 KB 1 bank 1 cycle

Regarding system memory Teapot employs DRAMSim2[10]

B Benchmarks

Table III presents the benchmarks employed to test theproposed approach which correspond to twenty unmodifiedAndroid graphics applications All of these applicationshave millions of downloads according to Google Play [11]with some of them surpassing 500 million downloads Theset of benchmarks includes games of the most populargenres in the mobile segment [12] such as puzzle arcadeand simulation The benchmarks also contain a variety ofworkloads completely 2D scenes such as cde or wmwscenes with simple 3D models such as ata or tib) and

scenes with more sophisticated models such as 300 or mstApplications classified as 3D contain both WOZ and NWOZprimitives while applications classified as 2D only containNWOZ primitives

Table IIIBENCHMARK SUITE

Benchmark Alias Genre Type

300 Seize your glory 300 Action 3DAir Attack ata Arcade 3DCrazy Snowboard csn Arcade 3DModern Strike mst First Person Shooter 3DTemple Run ter Platform 3DTigerball tib Physics Puzzle 3DAngry Birds abi Puzzle 2DArmymen arm Strategy 2DAvenger Legends ale Strategy 2DCandy Crush Saga ccs Puzzle 2DCastle Defense cde Tower Defense 2DClash of Clans coc MMO Strategy 2DCut the Rope ctr Puzzle 2DDude Perfect dpe Puzzle 2DHayday hay Simulation 2DHopeless hop Action Survival 2DMagic Touch mto Arcade 2DRedsun red Strategy 2DWherersquos my water wmw Puzzle 2DWorld of goo wog Physics Puzzle 2D

VII EXPERIMENTAL RESULTS

Figure 6 shows the energy consumption of the GPU-Memory system normalized to the Baseline GPU for our setof benchmarks The proposed optimizations that leverage anearly prediction of the visibility achieve a 43 reduction ofenergy consumption on average Energy savings are obtainedin all benchmarks with maximums of more than 80(cde dpe) Figure 7 shows the execution time divided intoGeometry and Raster pipelines normalized to the baselineOn average the proposed techniques achieve 39 executiontime reduction with maximums of more than 70 (ccs cdedpe)

057

01

02

03

04

05

06

07

08

09

1

No

rmal

ize

d e

ne

rgy

con

sum

pti

on

Overhead by additional accesses Overhead by additional hardware

Figure 6 Energy consumption of our EVR proposal normalized to theBaseline GPU

The energy overheads are mainly due to additional writesto the Parameter Buffer to store the layer identifiers Thisoverhead is quite moderate 21 on average as it can be

061

0

01

02

03

04

05

06

07

08

09

1

No

rmal

ize

d e

xecu

tio

n t

ime

Geometry Geometry overhead Raster

Figure 7 Execution time of our EVR proposal normalized to the BaselineGPU

seen in Figure 6 Figure 6 also illustrates that the addi-tional hardware added by the proposed mechanism incursin only 12 energy consumption overhead on average thestructures needed to manage the FVP information (LayerGenerator Table Layer Buffer and FVP Table) generate05 additional static and dynamic energy consumptionwhile the LUTs needed to implement Rendering Elimina-tion contribute to an additional 07 energy consumptionThe computation of Rendering Eliminationrsquos tile signaturesincurs in time overhead in the Geometry Pipeline whenevera primitive overlaps a large number of tiles since thepipeline is stalled waiting for all signatures to be sequentiallyupdated Figure 7 reports such overheads in execution timewhich on average represents 05 of the total

300 ata csn mst ter tib Average

0

1

2

3

4

5

6

Shad

ed

fra

gme

nts

pe

r p

ixe

l

Baseline EVR Oracle

Figure 8 Comparison of the number of shaded fragments per pixel amongthe baseline GPU our EVR proposal and an oracle

These important reductions in energy consumption andexecution time are mainly produced by avoiding the process-ing of ineffectual fragments (fragments that are occluded orare the same as in the previous frame) Figure 8 shows thenumber of fragments shaded per pixel using the proposedearly visibility resolution mechanism to reorder primitives(EVR) compared to the baseline for our set of 3D bench-marks We also compare our scheme with an oracle approach(which ideally assumes that the Z Buffer is initialized withthe final visibility of the tile ndashthe final depth valuesndash beforeit is executed) EVR significantly reduces (20) the numberof vainly shaded fragments and its results are close to thoseobtained by an oracle approach EVR cannot reach the oraclebecause of its approximate nature First it uses visibilityinformation of the previous frame which may have changed

Second it estimates visibility at a primitive-level while theoracle resolves visibility at the finest possible granularityfragment level

Moreover a large fraction of tiles are detected to beredundant and its execution is completely bypassed avoidingnot only the Fragment Shader stage for all their fragmentsbut also the rest of the stages of the Raster Pipeline forthose tiles Figure 9 shows the percentage of detectedredundant tiles ndashproducing the same colors as the previousframendash for our set of benchmarks Results are shown for thebaseline Rendering Elimination (RE) the proposed EVR-aided Rendering Elimination (EVR) and an oracle setup thatcan perfectly identify all tiles of a frame that are equal tothose of the previous frame

0

10

20

30

40

50

60

70

80

90

100

Det

ect

ed

eq

ual

tile

s

EVR RE Oracle

Figure 9 Percentage of detected equal tiles by EVR compared to REand an oracle

On average EVR avoids the rendering of 54 of the tilesreducing 5 more tiles than the baseline RE Predicting oc-cluded primitives and not adding them to the tilersquos signatureallows the detection of equal tiles in benchmarks in whichRE was hardly effective such as 300 or mst The majorityof these tiles that are identified as redundant corresponds toportions of the screen in which WOZ primitives are coveredby NWOZ primitives in the form of a HUD In most casesthe scene contains objects that are in motion but completelyoccluded by NWOZ geometry The layer-based visibilityscheme allows EVR to identify additional redundant tilesin benchmarks with a high degree of redundancy detectedby RE such as cde or mto In some applications such as hayor wmw the additional tiles eliminated exceeds 10 witha maximum of 30

The additional redundant tiles detected results in anaverage 10 reduction of energy consumption comparedto the baseline RE as presented in Figure 10 The earlyvisibility resolution incurs in some overheads which aregrouped together in the figure In the Geometry Pipeline theLayer Generator and FVP tables are accessed to generate alayer identifier which is stored in the Parameter Buffer Inthe Raster Pipeline the layer identifiers are read and writteninto the Layer Buffer When a tile finishes its rendering itsFVP is computed by accessing the Z and Layer Buffers andthe result is stored in the FVP Table Although the required

09

02

03

04

05

06

07

08

09

1

Ener

gy c

on

sum

pti

on

no

rmal

ized

to

RE

Overhead by FVP Computation

Figure 10 Energy consumption of our EVR proposal normalized to RE

sequential check of the two tables for each primitive andeach tile to which it is mapped could incur in some timeoverhead it is more than offset by the reduction in numberof primitives that can skip the signature computation stepsince they are occluded This is shown in Figure 11 whichcompares execution time broken down into Geometry andRaster Pipelines for the Baseline GPU RE and our proposedEVR approach for early visibility resolution Note that REhas to read the temporary hashes held in the Signature Bufferfor all the tiles that a primitive overlaps shift them as manybytes as the size of the primitive and finally combine themwith the hash of the primitive to produce a new signature forthe tile This process is avoided in our scheme if a primitiveis determined to be occluded in a tile since EVR marks it notto be included into the tilersquos signature The only exceptionwhere our EVR scheme does not reduce Geometry cycles ishop a benchmark that has very few primitives concentratedin a reduced amount of tiles Consequently the averagenumber of primitives to combine into the signature of a tile issmall limiting the benefits of occluded primitive detectionOn average our EVR mechanism reduces the execution timein the Geometry Pipeline by 4 with respect to RE

Moreover Rendering Elimination may induce time andenergy overheads in benchmarks where not enough redun-dant tiles are detected to offset the signature computationsuch as 300 or mst On the other hand our scheme is moreeffective at detecting redundant tiles and for non-redundanttiles specially in 3D benchmarks the primitive reordering in-creases the efficiency of the Early Depth Test which reducesthe amount of computations in the fragment processors Thisresults in overall speedups for all benchmarks

VIII RELATED WORK

Occlusion culling is a fundamental problem in computergraphics with an extensive literature spanning more thanthree decades In this section we focus on the most influ-ential works and the ones most related to our proposal

The Z Buffer [4] is the de facto standard to resolvevisibility due to its effectiveness and low implementationcost The Hierarchical Z Buffer [13] is a variation of thebaseline technique in which a depth pyramid is used to testvisibility The base level of the pyramid is the Z Buffer

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

300 ata csn mst ter tib abi arm ale ccs cde coc ctr dpe hay hop mto red wmw wog AVG

0

02

04

06

08

1

No

rmal

ize

d e

xecu

tio

n t

ime

Geometry Raster

Figure 11 Execution time comparison of our EVR proposal and RE against the baseline GPU

and higher levels are constructed by combining the depthof four pixels at the next lower level typically by choosingthe farthest one Entire primitives can be discarded withoutaccessing the Z Buffer by comparing their nearest depthagainst the values in higher levels in the pyramid OurEVR proposal also compares the depth of primitives toa FVP depth which would correspond to the top of thepyramid of the Hierarchical Z Buffer However the FVPdepth contains final visibility information which allowsunlike the Z pyramid to detect primitives that will beoccluded by others processed later Moreover the FVP depthincludes more information than just the top of the Z pyramidallowing the detection of occluded NWOZ primitives that donot use the Z buffer

Z-Prepass [14] draws the scene in two steps first thegeometry is rendered using simple fragment shaders onlyto quickly fill the Z Buffer Later the geometry is renderedagain with proper shaders but now with perfect visibilityinformation in-place so that all occluded fragments can bediscarded This additional render pass incurs in significantoverheads which may not always be offset by the increase inthe fragments discarded in the Early Depth Test By workingat a coarser granularity (primitive instead of fragment) EVRdoes not need to perform the pre-pass but still achievesresults comparable to having complete visibility information

The concept of layers has been previously adopted inthe context of occlusion culling most notably in DepthPeeling [15] an algorithm that renders geometry multipletimes peeling off the surface layer at each pixel in eachpass Recently Andersson et al [16] leveraged a two-layer representation of depths to avoid bandwidth spent inupdating the Hierarchical Z Buffer while in the work ofScheckel and Kolb [17] layers are used in combinationwith the alpha parameter to completely cull transparentfragments Unlike EVR these approaches cannot combinevisibility information of both WOZ and NWOZ primitivesfor a better visibility determination

Computing visibility at a fragment level (known as image-precision [18]) is useful to solve certain problems suchas circular dependencies However resolving visibility ata coarser grain could reduce the number of computations

needed Hardware occlusion queries [19] are a feature thatallow the user to query simple geometry (such as thebounding volumes) against the current contents of the ZBuffer The query counts the number of fragments thatpass the Z Test and the result allows the application toavoid rendering entire objects at the expense of CPU-GPUsynchronization Furthermore as with the Early Depth Testin order for occlusion queries to perform well both objectsand queries must be sent in front-to-back order EVR istransparent to the application in both axis it does not requireneither synchronization nor ordering

Multiple works reduce overshading by means of reorder-ing the primitives that make up a scene Govindaraju et al[20] propose an algorithm to sort non-overlapping objectsin either front-to-back or back-to front order from a givenviewpoint In the work of Chen et al [21] static objectsare preprocessed in order to create a depth-sorted list ofprimitives for every possible viewpoint The approach ofHan and Sander [22] also preprocesses objects to createseveral sorted lists that are indexed at runtime to ensureoptimal order but they consider movement by taking intoaccount not only viewpoints but also several key framesWeber and Stamminger [23] use a graph representationof dependencies in animated scenes with a fixed camerato sort primitives accordingly and leverage frame-to-framecoherence to merge different graphs and keep the overallstructure manageable VRO [24] also takes advantage oftemporal coherence to reorder objects entirely in hardwareand reduce overshading Unlike these approaches EVR isapplied at a finer granularity (primitive instead of object)does not need to perform any preprocess and can also beemployed in interactive scenes not just animated ones

IX CONCLUSIONS

We have presented a mechanism to determine visibilityin early stages of the Graphics Pipeline based on exploitingframe coherence Since consecutive frames tend to be verysimilar we use the information of a frame to estimate thevisibility for the following one

The proposed technique collects the depth of the farthestvisible primitive of every tile whenever its rendering processis complete For each overlapped tile the depth of a primitive

is compared against the depth stored for that tile in thepreceding frame If it is farther the primitive is occluded

This paper demonstrates the benefits of early visibilityprediction to remove ineffectual computations by increasingthe effectiveness of the Early Z Test a commonly usedtechnique in contemporary GPUs and Rendering Elimina-tion a recently proposed technique to exploit redundantcomputations The former works at pixel granularity and thelatter works at tile granularity

Using the predicted visibility information opaque prim-itives whose visibility is resolved using the Z Buffer arereordered such that primitives predicted as visible are ren-dered first which avoids the shading of occluded fragmentsBesides primitives predicted to be occluded are not con-sidered when generating the signature used by RenderingElimination to identify tiles that are equal to the ones in theprevious frame That increases the number of tiles that areidentified as redundant and consequently whose renderingcan be avoided

Our technique provides average speedups of 39 andenergy savings of 43 for a set of commercial Android ap-plications The reorder mechanism achieves overshading re-ductions comparable to having a Z Buffer filled with perfectvisibility information without requiring any additional renderpass to compute depths On the other hand by improvingthe tile redundancy detection of Rendering Elimination theraster pipeline of the GPU skips the rendering of more thanhalf of the tiles on average

X ACKNOWLEDGEMENTS

This work has been partially supported by the Span-ish State Research Agency under grant TIN2016-75344-R (AEIFEDER EU) and by the Generalitat de Catalunyaunder the AGAUR-FI program

REFERENCES

[1] M Anglada E de Lucas J-M Parcerisa J L AragonP Marcuello and A Gonzalez ldquoRendering elimination Earlydiscard of redundant tiles in the graphics pipelinerdquo in Pro-ceedings of the 25th IEEE International Symposium on High-Performance Computer Architecture IEEE 2019

[2] ldquoArm mali-450 gpurdquo httpsdeveloperarmcomproductsgraphics-and-multimediamali-gpusmali-450-gpu accessedDecember 10 2018

[3] ldquoHardware gpu marketrdquo httphwstatsunity3dcommobilegpuhtml accessed December 10 2018

[4] E Catmull ldquoA subdivision algorithm for computer display ofcurved surfacesrdquo tech rep Utah University Salt Lake CitySchool of Computing 1974

[5] ldquoPainterrsquos algorithmrdquo httpswwwsiggraphorgeducationmaterialsHyperGraphscanlinevisibilitypainterhtmaccessed December 10 2018

[6] J-M Arnau J-M Parcerisa and P Xekalakis ldquoTeapot atoolset for evaluating performance power and image qualityon mobile graphics systemsrdquo in Proceedings of the 27thInternational ACM Conference on Supercomputing pp 37ndash46 ACM 2013

[7] ldquoAndroid studiordquo httpsdeveloperandroidcomstudioindexhtml accessed December 10 2018

[8] ldquoGallium3drdquo httpswwwfreedesktoporgwikiSoftwaregallium accessed December 10 2018

[9] S Li J H Ahn R D Strong J B Brockman D M Tullsenand N P Jouppi ldquoMcPAT An Integrated Power Area andTiming Modeling Framework for Multicore and ManycoreArchitecturesrdquo in Proceedings of the 42nd Annual IEEEACMInternational Symposium on Microarchitecture pp 469ndash4802009

[10] P Rosenfeld E Cooper-Balis and B Jacob ldquoDramsim2 Acycle accurate memory system simulatorrdquo IEEE ComputerArchitecture Letters vol 10 no 1 pp 16ndash19 2011

[11] ldquoGoogle playrdquo httpsplaygooglecom accessed December10 2018

[12] ldquoMobile game statisticsrdquo httpsmediumcomsm appintelnew-mobile-game-statistics-every-game-publisher-should-know-in-2016-f1f8eef64f66 accessed December 102018

[13] N Greene M Kass and G Miller ldquoHierarchical z-buffervisibilityrdquo in Proceedings of the 20th Annual Conference onComputer Graphics and Interactive Techniques pp 231ndash238ACM 1993

[14] ldquoEarly z rejectionrdquo httpssoftwareintelcomen-usarticlesearly-z-rejection-sample accessed December 10 2018

[15] C Everitt ldquoInteractive order-independent transparencyrdquoWhite paper NVIDIA vol 2 no 6 p 7 2001

[16] M Andersson J Hasselgren and T Akenine-MollerldquoMasked depth culling for graphics hardwarerdquo ACM Trans-actions on Graphics vol 34 no 6 p 188 2015

[17] S Scheckel and A Kolb ldquoMin-max mipmaps for efficient2d occlusion cullingrdquo in Conference on Computer GraphicsVisualization and Computer Vision 2016

[18] I E Sutherland R F Sproull and R A SchumackerldquoA characterization of ten hidden-surface algorithmsrdquo ACMComputing Surveys vol 6 no 1 pp 1ndash55 1974

[19] O Mattausch J Bittner and M Wimmer ldquoChc++ Coherenthierarchical culling revisitedrdquo in Computer Graphics Forumvol 27 pp 221ndash230 Wiley Online Library 2008

[20] N K Govindaraju M Henson M C Lin and D ManochaldquoInteractive visibility ordering and transparency computationsamong geometric primitives in complex environmentsrdquo inProceedings of the 2005 Symposium on Interactive 3D Graph-ics and Games pp 49ndash56 ACM 2005

[21] G Chen P V Sander D Nehab L Yang and L Hu ldquoDepth-presorted triangle listsrdquo ACM Transactions on Graphicsvol 31 no 6 p 160 2012

[22] S Han and P V Sander ldquoTriangle reordering for reducedoverdraw in animated scenesrdquo in Proceedings of the 20thACM SIGGRAPH Symposium on Interactive 3D Graphics andGames pp 23ndash27 ACM 2016

[23] C Weber and M Stamminger ldquoTopological triangle sortingfor predefined camera pathsrdquo in Proceedings of the Confer-ence on Vision Modeling and Visualization pp 153ndash160Eurographics Association 2016

[24] E De Lucas P Marcuello J-M Parcerisa and A GonzalezldquoVisibility rendering order Improving energy efficiency onmobile gpus through frame coherencerdquo IEEE Transactionson Parallel and Distributed Systems 2018

since the fragment is translucent and does not completelyocclude layers behind it the Layer Buffer is not updated

During the blending stage each fragment of a WOZprimitive stores its layer identifier in a register named ZR sothat it identifies the layer of the last visible WOZ primitiveand may be used to distinguish at the end of rendering atile if its FVP corresponds to a WOZ or a NWOZ primitiveie the FVP-type of the tile The value of ZR is comparedto Lfar when the tile finishes rendering if the two valuesare equal the FVP-type of the tile is WOZ Otherwise it isNWOZ

C FVP Table

In order to predict if a primitive is likely to be visible ina tile we use the tilersquos FVP depth of the previous frame sothe entire set of per-tile FVP depths must be stored Suchinformation is maintained in a structure that we call FVPTable The FVP Table has one entry per tile with eachentry containing the previous framersquos FVP depth for that tileEach entry in the table also stores the FVP-type to indicatewhether the type of data stored is a Z or a layer identifier

Whenever a tile finishes rendering its FVP-type is de-termined If the FVP depth belongs to a NWOZ primitivethe FVP Table entry for the tile is updated with Lfar settingits FVP-type bit Otherwise the FPV entry for the tile isupdated with Zfar and the entryrsquos FVP-type bit is cleared

VI EVALUATION METHODOLOGY

A Simulator infrastructure

We employ the Teapot simulation framework [6] to eval-uate our proposal Teapot runs unmodified Android appli-cations for mobile platforms and obtains GPU performanceand energy consumption statistics Table II lists the parame-ters used in the simulations in order to model an architectureresembling the ARM Mali-450 GPU [2] the most widelyused GPU architecture nowadays with almost 20 of themobile GPU market [3]

The traces that feed the Teapot cycle-accurate simulatorare obtained via a two-step process First an Android appli-cation is run in the Android emulator [7] and every OpenGLcommand sent to the GPU is intercepted and stored in a fileSecond those OpenGL commands are fed to the softwarerenderer included in Gallium3D [8] which is instrumentedto generate a trace containing all the information neededto guide the cycle accurate execution such as vertex datashader instructions or memory addresses of the differentstages of the Graphics Pipeline For each application wesimulate 60 consecutive frames from the original applicationrun

McPAT [9] is used to estimate the energy consumptionof the GPU All the additional hardware required for theproposed technique (Layer Generator Table FVT tableLayer Buffer comparators and registers) is modelled usingMcPATrsquos components (SRAMs Registers MUXes XORs)

Table IIGPU SIMULATION PARAMETERS

Baseline GPU Parameters

Tech Specs 400 MHz 1 V 32 nmScreen Resolution 1196x768Tile Size 16x16 pixels

Main Memory

Latency 50-100 cyclesBandwidth 4 Bcycle (dual channel LPDDR3)Size 1 GB

Queues

Vertex (2x) 16 entries 136 bytesentryTriangle Tile 16 entries 388 bytesentryFragment 64 entries 233 bytesentry

Caches

Vertex Cache 64 bytesline 2-way associative4 KB 1 bank 1 cycle

Texture Caches (4x) 64 bytesline 2-way associative8 KB 1 bank 1 cycle

Tile Cache 64 bytesline 8-way associative128 KB 8 banks 1 cycle

L2 Cache 64 bytesline 8-way associative256 KB 8 banks 2 cycles

Color Buffer 64 bytesline 1-way associative1 KB 1 bank 1 cycle

Depth Buffer 64 bytesline 1-way associative1 KB 1 bank 1 cycle

Non-programmable stages

Primitive assembly 1 trianglecycleRasterizer 16 attributescycleEarly Z test 32 in-flight quad-fragments 1 Depth Buffer

Programmable stages

Vertex Processor 1 vertex processorFragment Processor 4 fragment processors

Additional hardware

Layer Generator Table 3600 entries 3 bytesentryFVP Table 3600 entries 4 bytesentryLayer Buffer 64 bytesline 1-way associative

1 KB 1 bank 1 cycle

Regarding system memory Teapot employs DRAMSim2[10]

B Benchmarks

Table III presents the benchmarks employed to test theproposed approach which correspond to twenty unmodifiedAndroid graphics applications All of these applicationshave millions of downloads according to Google Play [11]with some of them surpassing 500 million downloads Theset of benchmarks includes games of the most populargenres in the mobile segment [12] such as puzzle arcadeand simulation The benchmarks also contain a variety ofworkloads completely 2D scenes such as cde or wmwscenes with simple 3D models such as ata or tib) and

scenes with more sophisticated models such as 300 or mstApplications classified as 3D contain both WOZ and NWOZprimitives while applications classified as 2D only containNWOZ primitives

Table IIIBENCHMARK SUITE

Benchmark Alias Genre Type

300 Seize your glory 300 Action 3DAir Attack ata Arcade 3DCrazy Snowboard csn Arcade 3DModern Strike mst First Person Shooter 3DTemple Run ter Platform 3DTigerball tib Physics Puzzle 3DAngry Birds abi Puzzle 2DArmymen arm Strategy 2DAvenger Legends ale Strategy 2DCandy Crush Saga ccs Puzzle 2DCastle Defense cde Tower Defense 2DClash of Clans coc MMO Strategy 2DCut the Rope ctr Puzzle 2DDude Perfect dpe Puzzle 2DHayday hay Simulation 2DHopeless hop Action Survival 2DMagic Touch mto Arcade 2DRedsun red Strategy 2DWherersquos my water wmw Puzzle 2DWorld of goo wog Physics Puzzle 2D

VII EXPERIMENTAL RESULTS

Figure 6 shows the energy consumption of the GPU-Memory system normalized to the Baseline GPU for our setof benchmarks The proposed optimizations that leverage anearly prediction of the visibility achieve a 43 reduction ofenergy consumption on average Energy savings are obtainedin all benchmarks with maximums of more than 80(cde dpe) Figure 7 shows the execution time divided intoGeometry and Raster pipelines normalized to the baselineOn average the proposed techniques achieve 39 executiontime reduction with maximums of more than 70 (ccs cdedpe)

057

01

02

03

04

05

06

07

08

09

1

No

rmal

ize

d e

ne

rgy

con

sum

pti

on

Overhead by additional accesses Overhead by additional hardware

Figure 6 Energy consumption of our EVR proposal normalized to theBaseline GPU

The energy overheads are mainly due to additional writesto the Parameter Buffer to store the layer identifiers Thisoverhead is quite moderate 21 on average as it can be

061

0

01

02

03

04

05

06

07

08

09

1

No

rmal

ize

d e

xecu

tio

n t

ime

Geometry Geometry overhead Raster

Figure 7 Execution time of our EVR proposal normalized to the BaselineGPU

seen in Figure 6 Figure 6 also illustrates that the addi-tional hardware added by the proposed mechanism incursin only 12 energy consumption overhead on average thestructures needed to manage the FVP information (LayerGenerator Table Layer Buffer and FVP Table) generate05 additional static and dynamic energy consumptionwhile the LUTs needed to implement Rendering Elimina-tion contribute to an additional 07 energy consumptionThe computation of Rendering Eliminationrsquos tile signaturesincurs in time overhead in the Geometry Pipeline whenevera primitive overlaps a large number of tiles since thepipeline is stalled waiting for all signatures to be sequentiallyupdated Figure 7 reports such overheads in execution timewhich on average represents 05 of the total

300 ata csn mst ter tib Average

0

1

2

3

4

5

6

Shad

ed

fra

gme

nts

pe

r p

ixe

l

Baseline EVR Oracle

Figure 8 Comparison of the number of shaded fragments per pixel amongthe baseline GPU our EVR proposal and an oracle

These important reductions in energy consumption andexecution time are mainly produced by avoiding the process-ing of ineffectual fragments (fragments that are occluded orare the same as in the previous frame) Figure 8 shows thenumber of fragments shaded per pixel using the proposedearly visibility resolution mechanism to reorder primitives(EVR) compared to the baseline for our set of 3D bench-marks We also compare our scheme with an oracle approach(which ideally assumes that the Z Buffer is initialized withthe final visibility of the tile ndashthe final depth valuesndash beforeit is executed) EVR significantly reduces (20) the numberof vainly shaded fragments and its results are close to thoseobtained by an oracle approach EVR cannot reach the oraclebecause of its approximate nature First it uses visibilityinformation of the previous frame which may have changed

Second it estimates visibility at a primitive-level while theoracle resolves visibility at the finest possible granularityfragment level

Moreover a large fraction of tiles are detected to beredundant and its execution is completely bypassed avoidingnot only the Fragment Shader stage for all their fragmentsbut also the rest of the stages of the Raster Pipeline forthose tiles Figure 9 shows the percentage of detectedredundant tiles ndashproducing the same colors as the previousframendash for our set of benchmarks Results are shown for thebaseline Rendering Elimination (RE) the proposed EVR-aided Rendering Elimination (EVR) and an oracle setup thatcan perfectly identify all tiles of a frame that are equal tothose of the previous frame

0

10

20

30

40

50

60

70

80

90

100

Det

ect

ed

eq

ual

tile

s

EVR RE Oracle

Figure 9 Percentage of detected equal tiles by EVR compared to REand an oracle

On average EVR avoids the rendering of 54 of the tilesreducing 5 more tiles than the baseline RE Predicting oc-cluded primitives and not adding them to the tilersquos signatureallows the detection of equal tiles in benchmarks in whichRE was hardly effective such as 300 or mst The majorityof these tiles that are identified as redundant corresponds toportions of the screen in which WOZ primitives are coveredby NWOZ primitives in the form of a HUD In most casesthe scene contains objects that are in motion but completelyoccluded by NWOZ geometry The layer-based visibilityscheme allows EVR to identify additional redundant tilesin benchmarks with a high degree of redundancy detectedby RE such as cde or mto In some applications such as hayor wmw the additional tiles eliminated exceeds 10 witha maximum of 30

The additional redundant tiles detected results in anaverage 10 reduction of energy consumption comparedto the baseline RE as presented in Figure 10 The earlyvisibility resolution incurs in some overheads which aregrouped together in the figure In the Geometry Pipeline theLayer Generator and FVP tables are accessed to generate alayer identifier which is stored in the Parameter Buffer Inthe Raster Pipeline the layer identifiers are read and writteninto the Layer Buffer When a tile finishes its rendering itsFVP is computed by accessing the Z and Layer Buffers andthe result is stored in the FVP Table Although the required

09

02

03

04

05

06

07

08

09

1

Ener

gy c

on

sum

pti

on

no

rmal

ized

to

RE

Overhead by FVP Computation

Figure 10 Energy consumption of our EVR proposal normalized to RE

sequential check of the two tables for each primitive andeach tile to which it is mapped could incur in some timeoverhead it is more than offset by the reduction in numberof primitives that can skip the signature computation stepsince they are occluded This is shown in Figure 11 whichcompares execution time broken down into Geometry andRaster Pipelines for the Baseline GPU RE and our proposedEVR approach for early visibility resolution Note that REhas to read the temporary hashes held in the Signature Bufferfor all the tiles that a primitive overlaps shift them as manybytes as the size of the primitive and finally combine themwith the hash of the primitive to produce a new signature forthe tile This process is avoided in our scheme if a primitiveis determined to be occluded in a tile since EVR marks it notto be included into the tilersquos signature The only exceptionwhere our EVR scheme does not reduce Geometry cycles ishop a benchmark that has very few primitives concentratedin a reduced amount of tiles Consequently the averagenumber of primitives to combine into the signature of a tile issmall limiting the benefits of occluded primitive detectionOn average our EVR mechanism reduces the execution timein the Geometry Pipeline by 4 with respect to RE

Moreover Rendering Elimination may induce time andenergy overheads in benchmarks where not enough redun-dant tiles are detected to offset the signature computationsuch as 300 or mst On the other hand our scheme is moreeffective at detecting redundant tiles and for non-redundanttiles specially in 3D benchmarks the primitive reordering in-creases the efficiency of the Early Depth Test which reducesthe amount of computations in the fragment processors Thisresults in overall speedups for all benchmarks

VIII RELATED WORK

Occlusion culling is a fundamental problem in computergraphics with an extensive literature spanning more thanthree decades In this section we focus on the most influ-ential works and the ones most related to our proposal

The Z Buffer [4] is the de facto standard to resolvevisibility due to its effectiveness and low implementationcost The Hierarchical Z Buffer [13] is a variation of thebaseline technique in which a depth pyramid is used to testvisibility The base level of the pyramid is the Z Buffer

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

300 ata csn mst ter tib abi arm ale ccs cde coc ctr dpe hay hop mto red wmw wog AVG

0

02

04

06

08

1

No

rmal

ize

d e

xecu

tio

n t

ime

Geometry Raster

Figure 11 Execution time comparison of our EVR proposal and RE against the baseline GPU

and higher levels are constructed by combining the depthof four pixels at the next lower level typically by choosingthe farthest one Entire primitives can be discarded withoutaccessing the Z Buffer by comparing their nearest depthagainst the values in higher levels in the pyramid OurEVR proposal also compares the depth of primitives toa FVP depth which would correspond to the top of thepyramid of the Hierarchical Z Buffer However the FVPdepth contains final visibility information which allowsunlike the Z pyramid to detect primitives that will beoccluded by others processed later Moreover the FVP depthincludes more information than just the top of the Z pyramidallowing the detection of occluded NWOZ primitives that donot use the Z buffer

Z-Prepass [14] draws the scene in two steps first thegeometry is rendered using simple fragment shaders onlyto quickly fill the Z Buffer Later the geometry is renderedagain with proper shaders but now with perfect visibilityinformation in-place so that all occluded fragments can bediscarded This additional render pass incurs in significantoverheads which may not always be offset by the increase inthe fragments discarded in the Early Depth Test By workingat a coarser granularity (primitive instead of fragment) EVRdoes not need to perform the pre-pass but still achievesresults comparable to having complete visibility information

The concept of layers has been previously adopted inthe context of occlusion culling most notably in DepthPeeling [15] an algorithm that renders geometry multipletimes peeling off the surface layer at each pixel in eachpass Recently Andersson et al [16] leveraged a two-layer representation of depths to avoid bandwidth spent inupdating the Hierarchical Z Buffer while in the work ofScheckel and Kolb [17] layers are used in combinationwith the alpha parameter to completely cull transparentfragments Unlike EVR these approaches cannot combinevisibility information of both WOZ and NWOZ primitivesfor a better visibility determination

Computing visibility at a fragment level (known as image-precision [18]) is useful to solve certain problems suchas circular dependencies However resolving visibility ata coarser grain could reduce the number of computations

needed Hardware occlusion queries [19] are a feature thatallow the user to query simple geometry (such as thebounding volumes) against the current contents of the ZBuffer The query counts the number of fragments thatpass the Z Test and the result allows the application toavoid rendering entire objects at the expense of CPU-GPUsynchronization Furthermore as with the Early Depth Testin order for occlusion queries to perform well both objectsand queries must be sent in front-to-back order EVR istransparent to the application in both axis it does not requireneither synchronization nor ordering

Multiple works reduce overshading by means of reorder-ing the primitives that make up a scene Govindaraju et al[20] propose an algorithm to sort non-overlapping objectsin either front-to-back or back-to front order from a givenviewpoint In the work of Chen et al [21] static objectsare preprocessed in order to create a depth-sorted list ofprimitives for every possible viewpoint The approach ofHan and Sander [22] also preprocesses objects to createseveral sorted lists that are indexed at runtime to ensureoptimal order but they consider movement by taking intoaccount not only viewpoints but also several key framesWeber and Stamminger [23] use a graph representationof dependencies in animated scenes with a fixed camerato sort primitives accordingly and leverage frame-to-framecoherence to merge different graphs and keep the overallstructure manageable VRO [24] also takes advantage oftemporal coherence to reorder objects entirely in hardwareand reduce overshading Unlike these approaches EVR isapplied at a finer granularity (primitive instead of object)does not need to perform any preprocess and can also beemployed in interactive scenes not just animated ones

IX CONCLUSIONS

We have presented a mechanism to determine visibilityin early stages of the Graphics Pipeline based on exploitingframe coherence Since consecutive frames tend to be verysimilar we use the information of a frame to estimate thevisibility for the following one

The proposed technique collects the depth of the farthestvisible primitive of every tile whenever its rendering processis complete For each overlapped tile the depth of a primitive

is compared against the depth stored for that tile in thepreceding frame If it is farther the primitive is occluded

This paper demonstrates the benefits of early visibilityprediction to remove ineffectual computations by increasingthe effectiveness of the Early Z Test a commonly usedtechnique in contemporary GPUs and Rendering Elimina-tion a recently proposed technique to exploit redundantcomputations The former works at pixel granularity and thelatter works at tile granularity

Using the predicted visibility information opaque prim-itives whose visibility is resolved using the Z Buffer arereordered such that primitives predicted as visible are ren-dered first which avoids the shading of occluded fragmentsBesides primitives predicted to be occluded are not con-sidered when generating the signature used by RenderingElimination to identify tiles that are equal to the ones in theprevious frame That increases the number of tiles that areidentified as redundant and consequently whose renderingcan be avoided

Our technique provides average speedups of 39 andenergy savings of 43 for a set of commercial Android ap-plications The reorder mechanism achieves overshading re-ductions comparable to having a Z Buffer filled with perfectvisibility information without requiring any additional renderpass to compute depths On the other hand by improvingthe tile redundancy detection of Rendering Elimination theraster pipeline of the GPU skips the rendering of more thanhalf of the tiles on average

X ACKNOWLEDGEMENTS

This work has been partially supported by the Span-ish State Research Agency under grant TIN2016-75344-R (AEIFEDER EU) and by the Generalitat de Catalunyaunder the AGAUR-FI program

REFERENCES

[1] M Anglada E de Lucas J-M Parcerisa J L AragonP Marcuello and A Gonzalez ldquoRendering elimination Earlydiscard of redundant tiles in the graphics pipelinerdquo in Pro-ceedings of the 25th IEEE International Symposium on High-Performance Computer Architecture IEEE 2019

[2] ldquoArm mali-450 gpurdquo httpsdeveloperarmcomproductsgraphics-and-multimediamali-gpusmali-450-gpu accessedDecember 10 2018

[3] ldquoHardware gpu marketrdquo httphwstatsunity3dcommobilegpuhtml accessed December 10 2018

[4] E Catmull ldquoA subdivision algorithm for computer display ofcurved surfacesrdquo tech rep Utah University Salt Lake CitySchool of Computing 1974

[5] ldquoPainterrsquos algorithmrdquo httpswwwsiggraphorgeducationmaterialsHyperGraphscanlinevisibilitypainterhtmaccessed December 10 2018

[6] J-M Arnau J-M Parcerisa and P Xekalakis ldquoTeapot atoolset for evaluating performance power and image qualityon mobile graphics systemsrdquo in Proceedings of the 27thInternational ACM Conference on Supercomputing pp 37ndash46 ACM 2013

[7] ldquoAndroid studiordquo httpsdeveloperandroidcomstudioindexhtml accessed December 10 2018

[8] ldquoGallium3drdquo httpswwwfreedesktoporgwikiSoftwaregallium accessed December 10 2018

[9] S Li J H Ahn R D Strong J B Brockman D M Tullsenand N P Jouppi ldquoMcPAT An Integrated Power Area andTiming Modeling Framework for Multicore and ManycoreArchitecturesrdquo in Proceedings of the 42nd Annual IEEEACMInternational Symposium on Microarchitecture pp 469ndash4802009

[10] P Rosenfeld E Cooper-Balis and B Jacob ldquoDramsim2 Acycle accurate memory system simulatorrdquo IEEE ComputerArchitecture Letters vol 10 no 1 pp 16ndash19 2011

[11] ldquoGoogle playrdquo httpsplaygooglecom accessed December10 2018

[12] ldquoMobile game statisticsrdquo httpsmediumcomsm appintelnew-mobile-game-statistics-every-game-publisher-should-know-in-2016-f1f8eef64f66 accessed December 102018

[13] N Greene M Kass and G Miller ldquoHierarchical z-buffervisibilityrdquo in Proceedings of the 20th Annual Conference onComputer Graphics and Interactive Techniques pp 231ndash238ACM 1993

[14] ldquoEarly z rejectionrdquo httpssoftwareintelcomen-usarticlesearly-z-rejection-sample accessed December 10 2018

[15] C Everitt ldquoInteractive order-independent transparencyrdquoWhite paper NVIDIA vol 2 no 6 p 7 2001

[16] M Andersson J Hasselgren and T Akenine-MollerldquoMasked depth culling for graphics hardwarerdquo ACM Trans-actions on Graphics vol 34 no 6 p 188 2015

[17] S Scheckel and A Kolb ldquoMin-max mipmaps for efficient2d occlusion cullingrdquo in Conference on Computer GraphicsVisualization and Computer Vision 2016

[18] I E Sutherland R F Sproull and R A SchumackerldquoA characterization of ten hidden-surface algorithmsrdquo ACMComputing Surveys vol 6 no 1 pp 1ndash55 1974

[19] O Mattausch J Bittner and M Wimmer ldquoChc++ Coherenthierarchical culling revisitedrdquo in Computer Graphics Forumvol 27 pp 221ndash230 Wiley Online Library 2008

[20] N K Govindaraju M Henson M C Lin and D ManochaldquoInteractive visibility ordering and transparency computationsamong geometric primitives in complex environmentsrdquo inProceedings of the 2005 Symposium on Interactive 3D Graph-ics and Games pp 49ndash56 ACM 2005

[21] G Chen P V Sander D Nehab L Yang and L Hu ldquoDepth-presorted triangle listsrdquo ACM Transactions on Graphicsvol 31 no 6 p 160 2012

[22] S Han and P V Sander ldquoTriangle reordering for reducedoverdraw in animated scenesrdquo in Proceedings of the 20thACM SIGGRAPH Symposium on Interactive 3D Graphics andGames pp 23ndash27 ACM 2016

[23] C Weber and M Stamminger ldquoTopological triangle sortingfor predefined camera pathsrdquo in Proceedings of the Confer-ence on Vision Modeling and Visualization pp 153ndash160Eurographics Association 2016

[24] E De Lucas P Marcuello J-M Parcerisa and A GonzalezldquoVisibility rendering order Improving energy efficiency onmobile gpus through frame coherencerdquo IEEE Transactionson Parallel and Distributed Systems 2018

scenes with more sophisticated models such as 300 or mstApplications classified as 3D contain both WOZ and NWOZprimitives while applications classified as 2D only containNWOZ primitives

Table IIIBENCHMARK SUITE

Benchmark Alias Genre Type

300 Seize your glory 300 Action 3DAir Attack ata Arcade 3DCrazy Snowboard csn Arcade 3DModern Strike mst First Person Shooter 3DTemple Run ter Platform 3DTigerball tib Physics Puzzle 3DAngry Birds abi Puzzle 2DArmymen arm Strategy 2DAvenger Legends ale Strategy 2DCandy Crush Saga ccs Puzzle 2DCastle Defense cde Tower Defense 2DClash of Clans coc MMO Strategy 2DCut the Rope ctr Puzzle 2DDude Perfect dpe Puzzle 2DHayday hay Simulation 2DHopeless hop Action Survival 2DMagic Touch mto Arcade 2DRedsun red Strategy 2DWherersquos my water wmw Puzzle 2DWorld of goo wog Physics Puzzle 2D

VII EXPERIMENTAL RESULTS

Figure 6 shows the energy consumption of the GPU-Memory system normalized to the Baseline GPU for our setof benchmarks The proposed optimizations that leverage anearly prediction of the visibility achieve a 43 reduction ofenergy consumption on average Energy savings are obtainedin all benchmarks with maximums of more than 80(cde dpe) Figure 7 shows the execution time divided intoGeometry and Raster pipelines normalized to the baselineOn average the proposed techniques achieve 39 executiontime reduction with maximums of more than 70 (ccs cdedpe)

057

01

02

03

04

05

06

07

08

09

1

No

rmal

ize

d e

ne

rgy

con

sum

pti

on

Overhead by additional accesses Overhead by additional hardware

Figure 6 Energy consumption of our EVR proposal normalized to theBaseline GPU

The energy overheads are mainly due to additional writesto the Parameter Buffer to store the layer identifiers Thisoverhead is quite moderate 21 on average as it can be

061

0

01

02

03

04

05

06

07

08

09

1

No

rmal

ize

d e

xecu

tio

n t

ime

Geometry Geometry overhead Raster

Figure 7 Execution time of our EVR proposal normalized to the BaselineGPU

seen in Figure 6 Figure 6 also illustrates that the addi-tional hardware added by the proposed mechanism incursin only 12 energy consumption overhead on average thestructures needed to manage the FVP information (LayerGenerator Table Layer Buffer and FVP Table) generate05 additional static and dynamic energy consumptionwhile the LUTs needed to implement Rendering Elimina-tion contribute to an additional 07 energy consumptionThe computation of Rendering Eliminationrsquos tile signaturesincurs in time overhead in the Geometry Pipeline whenevera primitive overlaps a large number of tiles since thepipeline is stalled waiting for all signatures to be sequentiallyupdated Figure 7 reports such overheads in execution timewhich on average represents 05 of the total

300 ata csn mst ter tib Average

0

1

2

3

4

5

6

Shad

ed

fra

gme

nts

pe

r p

ixe

l

Baseline EVR Oracle

Figure 8 Comparison of the number of shaded fragments per pixel amongthe baseline GPU our EVR proposal and an oracle

These important reductions in energy consumption andexecution time are mainly produced by avoiding the process-ing of ineffectual fragments (fragments that are occluded orare the same as in the previous frame) Figure 8 shows thenumber of fragments shaded per pixel using the proposedearly visibility resolution mechanism to reorder primitives(EVR) compared to the baseline for our set of 3D bench-marks We also compare our scheme with an oracle approach(which ideally assumes that the Z Buffer is initialized withthe final visibility of the tile ndashthe final depth valuesndash beforeit is executed) EVR significantly reduces (20) the numberof vainly shaded fragments and its results are close to thoseobtained by an oracle approach EVR cannot reach the oraclebecause of its approximate nature First it uses visibilityinformation of the previous frame which may have changed

Second it estimates visibility at a primitive-level while theoracle resolves visibility at the finest possible granularityfragment level

Moreover a large fraction of tiles are detected to beredundant and its execution is completely bypassed avoidingnot only the Fragment Shader stage for all their fragmentsbut also the rest of the stages of the Raster Pipeline forthose tiles Figure 9 shows the percentage of detectedredundant tiles ndashproducing the same colors as the previousframendash for our set of benchmarks Results are shown for thebaseline Rendering Elimination (RE) the proposed EVR-aided Rendering Elimination (EVR) and an oracle setup thatcan perfectly identify all tiles of a frame that are equal tothose of the previous frame

0

10

20

30

40

50

60

70

80

90

100

Det

ect

ed

eq

ual

tile

s

EVR RE Oracle

Figure 9 Percentage of detected equal tiles by EVR compared to REand an oracle

On average EVR avoids the rendering of 54 of the tilesreducing 5 more tiles than the baseline RE Predicting oc-cluded primitives and not adding them to the tilersquos signatureallows the detection of equal tiles in benchmarks in whichRE was hardly effective such as 300 or mst The majorityof these tiles that are identified as redundant corresponds toportions of the screen in which WOZ primitives are coveredby NWOZ primitives in the form of a HUD In most casesthe scene contains objects that are in motion but completelyoccluded by NWOZ geometry The layer-based visibilityscheme allows EVR to identify additional redundant tilesin benchmarks with a high degree of redundancy detectedby RE such as cde or mto In some applications such as hayor wmw the additional tiles eliminated exceeds 10 witha maximum of 30

The additional redundant tiles detected results in anaverage 10 reduction of energy consumption comparedto the baseline RE as presented in Figure 10 The earlyvisibility resolution incurs in some overheads which aregrouped together in the figure In the Geometry Pipeline theLayer Generator and FVP tables are accessed to generate alayer identifier which is stored in the Parameter Buffer Inthe Raster Pipeline the layer identifiers are read and writteninto the Layer Buffer When a tile finishes its rendering itsFVP is computed by accessing the Z and Layer Buffers andthe result is stored in the FVP Table Although the required

09

02

03

04

05

06

07

08

09

1

Ener

gy c

on

sum

pti

on

no

rmal

ized

to

RE

Overhead by FVP Computation

Figure 10 Energy consumption of our EVR proposal normalized to RE

sequential check of the two tables for each primitive andeach tile to which it is mapped could incur in some timeoverhead it is more than offset by the reduction in numberof primitives that can skip the signature computation stepsince they are occluded This is shown in Figure 11 whichcompares execution time broken down into Geometry andRaster Pipelines for the Baseline GPU RE and our proposedEVR approach for early visibility resolution Note that REhas to read the temporary hashes held in the Signature Bufferfor all the tiles that a primitive overlaps shift them as manybytes as the size of the primitive and finally combine themwith the hash of the primitive to produce a new signature forthe tile This process is avoided in our scheme if a primitiveis determined to be occluded in a tile since EVR marks it notto be included into the tilersquos signature The only exceptionwhere our EVR scheme does not reduce Geometry cycles ishop a benchmark that has very few primitives concentratedin a reduced amount of tiles Consequently the averagenumber of primitives to combine into the signature of a tile issmall limiting the benefits of occluded primitive detectionOn average our EVR mechanism reduces the execution timein the Geometry Pipeline by 4 with respect to RE

Moreover Rendering Elimination may induce time andenergy overheads in benchmarks where not enough redun-dant tiles are detected to offset the signature computationsuch as 300 or mst On the other hand our scheme is moreeffective at detecting redundant tiles and for non-redundanttiles specially in 3D benchmarks the primitive reordering in-creases the efficiency of the Early Depth Test which reducesthe amount of computations in the fragment processors Thisresults in overall speedups for all benchmarks

VIII RELATED WORK

Occlusion culling is a fundamental problem in computergraphics with an extensive literature spanning more thanthree decades In this section we focus on the most influ-ential works and the ones most related to our proposal

The Z Buffer [4] is the de facto standard to resolvevisibility due to its effectiveness and low implementationcost The Hierarchical Z Buffer [13] is a variation of thebaseline technique in which a depth pyramid is used to testvisibility The base level of the pyramid is the Z Buffer

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

300 ata csn mst ter tib abi arm ale ccs cde coc ctr dpe hay hop mto red wmw wog AVG

0

02

04

06

08

1

No

rmal

ize

d e

xecu

tio

n t

ime

Geometry Raster

Figure 11 Execution time comparison of our EVR proposal and RE against the baseline GPU

and higher levels are constructed by combining the depthof four pixels at the next lower level typically by choosingthe farthest one Entire primitives can be discarded withoutaccessing the Z Buffer by comparing their nearest depthagainst the values in higher levels in the pyramid OurEVR proposal also compares the depth of primitives toa FVP depth which would correspond to the top of thepyramid of the Hierarchical Z Buffer However the FVPdepth contains final visibility information which allowsunlike the Z pyramid to detect primitives that will beoccluded by others processed later Moreover the FVP depthincludes more information than just the top of the Z pyramidallowing the detection of occluded NWOZ primitives that donot use the Z buffer

Z-Prepass [14] draws the scene in two steps first thegeometry is rendered using simple fragment shaders onlyto quickly fill the Z Buffer Later the geometry is renderedagain with proper shaders but now with perfect visibilityinformation in-place so that all occluded fragments can bediscarded This additional render pass incurs in significantoverheads which may not always be offset by the increase inthe fragments discarded in the Early Depth Test By workingat a coarser granularity (primitive instead of fragment) EVRdoes not need to perform the pre-pass but still achievesresults comparable to having complete visibility information

The concept of layers has been previously adopted inthe context of occlusion culling most notably in DepthPeeling [15] an algorithm that renders geometry multipletimes peeling off the surface layer at each pixel in eachpass Recently Andersson et al [16] leveraged a two-layer representation of depths to avoid bandwidth spent inupdating the Hierarchical Z Buffer while in the work ofScheckel and Kolb [17] layers are used in combinationwith the alpha parameter to completely cull transparentfragments Unlike EVR these approaches cannot combinevisibility information of both WOZ and NWOZ primitivesfor a better visibility determination

Computing visibility at a fragment level (known as image-precision [18]) is useful to solve certain problems suchas circular dependencies However resolving visibility ata coarser grain could reduce the number of computations

needed Hardware occlusion queries [19] are a feature thatallow the user to query simple geometry (such as thebounding volumes) against the current contents of the ZBuffer The query counts the number of fragments thatpass the Z Test and the result allows the application toavoid rendering entire objects at the expense of CPU-GPUsynchronization Furthermore as with the Early Depth Testin order for occlusion queries to perform well both objectsand queries must be sent in front-to-back order EVR istransparent to the application in both axis it does not requireneither synchronization nor ordering

Multiple works reduce overshading by means of reorder-ing the primitives that make up a scene Govindaraju et al[20] propose an algorithm to sort non-overlapping objectsin either front-to-back or back-to front order from a givenviewpoint In the work of Chen et al [21] static objectsare preprocessed in order to create a depth-sorted list ofprimitives for every possible viewpoint The approach ofHan and Sander [22] also preprocesses objects to createseveral sorted lists that are indexed at runtime to ensureoptimal order but they consider movement by taking intoaccount not only viewpoints but also several key framesWeber and Stamminger [23] use a graph representationof dependencies in animated scenes with a fixed camerato sort primitives accordingly and leverage frame-to-framecoherence to merge different graphs and keep the overallstructure manageable VRO [24] also takes advantage oftemporal coherence to reorder objects entirely in hardwareand reduce overshading Unlike these approaches EVR isapplied at a finer granularity (primitive instead of object)does not need to perform any preprocess and can also beemployed in interactive scenes not just animated ones

IX CONCLUSIONS

We have presented a mechanism to determine visibilityin early stages of the Graphics Pipeline based on exploitingframe coherence Since consecutive frames tend to be verysimilar we use the information of a frame to estimate thevisibility for the following one

The proposed technique collects the depth of the farthestvisible primitive of every tile whenever its rendering processis complete For each overlapped tile the depth of a primitive

is compared against the depth stored for that tile in thepreceding frame If it is farther the primitive is occluded

This paper demonstrates the benefits of early visibilityprediction to remove ineffectual computations by increasingthe effectiveness of the Early Z Test a commonly usedtechnique in contemporary GPUs and Rendering Elimina-tion a recently proposed technique to exploit redundantcomputations The former works at pixel granularity and thelatter works at tile granularity

Using the predicted visibility information opaque prim-itives whose visibility is resolved using the Z Buffer arereordered such that primitives predicted as visible are ren-dered first which avoids the shading of occluded fragmentsBesides primitives predicted to be occluded are not con-sidered when generating the signature used by RenderingElimination to identify tiles that are equal to the ones in theprevious frame That increases the number of tiles that areidentified as redundant and consequently whose renderingcan be avoided

Our technique provides average speedups of 39 andenergy savings of 43 for a set of commercial Android ap-plications The reorder mechanism achieves overshading re-ductions comparable to having a Z Buffer filled with perfectvisibility information without requiring any additional renderpass to compute depths On the other hand by improvingthe tile redundancy detection of Rendering Elimination theraster pipeline of the GPU skips the rendering of more thanhalf of the tiles on average

X ACKNOWLEDGEMENTS

This work has been partially supported by the Span-ish State Research Agency under grant TIN2016-75344-R (AEIFEDER EU) and by the Generalitat de Catalunyaunder the AGAUR-FI program

REFERENCES

[1] M Anglada E de Lucas J-M Parcerisa J L AragonP Marcuello and A Gonzalez ldquoRendering elimination Earlydiscard of redundant tiles in the graphics pipelinerdquo in Pro-ceedings of the 25th IEEE International Symposium on High-Performance Computer Architecture IEEE 2019

[2] ldquoArm mali-450 gpurdquo httpsdeveloperarmcomproductsgraphics-and-multimediamali-gpusmali-450-gpu accessedDecember 10 2018

[3] ldquoHardware gpu marketrdquo httphwstatsunity3dcommobilegpuhtml accessed December 10 2018

[4] E Catmull ldquoA subdivision algorithm for computer display ofcurved surfacesrdquo tech rep Utah University Salt Lake CitySchool of Computing 1974

[5] ldquoPainterrsquos algorithmrdquo httpswwwsiggraphorgeducationmaterialsHyperGraphscanlinevisibilitypainterhtmaccessed December 10 2018

[6] J-M Arnau J-M Parcerisa and P Xekalakis ldquoTeapot atoolset for evaluating performance power and image qualityon mobile graphics systemsrdquo in Proceedings of the 27thInternational ACM Conference on Supercomputing pp 37ndash46 ACM 2013

[7] ldquoAndroid studiordquo httpsdeveloperandroidcomstudioindexhtml accessed December 10 2018

[8] ldquoGallium3drdquo httpswwwfreedesktoporgwikiSoftwaregallium accessed December 10 2018

[9] S Li J H Ahn R D Strong J B Brockman D M Tullsenand N P Jouppi ldquoMcPAT An Integrated Power Area andTiming Modeling Framework for Multicore and ManycoreArchitecturesrdquo in Proceedings of the 42nd Annual IEEEACMInternational Symposium on Microarchitecture pp 469ndash4802009

[10] P Rosenfeld E Cooper-Balis and B Jacob ldquoDramsim2 Acycle accurate memory system simulatorrdquo IEEE ComputerArchitecture Letters vol 10 no 1 pp 16ndash19 2011

[11] ldquoGoogle playrdquo httpsplaygooglecom accessed December10 2018

[12] ldquoMobile game statisticsrdquo httpsmediumcomsm appintelnew-mobile-game-statistics-every-game-publisher-should-know-in-2016-f1f8eef64f66 accessed December 102018

[13] N Greene M Kass and G Miller ldquoHierarchical z-buffervisibilityrdquo in Proceedings of the 20th Annual Conference onComputer Graphics and Interactive Techniques pp 231ndash238ACM 1993

[14] ldquoEarly z rejectionrdquo httpssoftwareintelcomen-usarticlesearly-z-rejection-sample accessed December 10 2018

[15] C Everitt ldquoInteractive order-independent transparencyrdquoWhite paper NVIDIA vol 2 no 6 p 7 2001

[16] M Andersson J Hasselgren and T Akenine-MollerldquoMasked depth culling for graphics hardwarerdquo ACM Trans-actions on Graphics vol 34 no 6 p 188 2015

[17] S Scheckel and A Kolb ldquoMin-max mipmaps for efficient2d occlusion cullingrdquo in Conference on Computer GraphicsVisualization and Computer Vision 2016

[18] I E Sutherland R F Sproull and R A SchumackerldquoA characterization of ten hidden-surface algorithmsrdquo ACMComputing Surveys vol 6 no 1 pp 1ndash55 1974

[19] O Mattausch J Bittner and M Wimmer ldquoChc++ Coherenthierarchical culling revisitedrdquo in Computer Graphics Forumvol 27 pp 221ndash230 Wiley Online Library 2008

[20] N K Govindaraju M Henson M C Lin and D ManochaldquoInteractive visibility ordering and transparency computationsamong geometric primitives in complex environmentsrdquo inProceedings of the 2005 Symposium on Interactive 3D Graph-ics and Games pp 49ndash56 ACM 2005

[21] G Chen P V Sander D Nehab L Yang and L Hu ldquoDepth-presorted triangle listsrdquo ACM Transactions on Graphicsvol 31 no 6 p 160 2012

[22] S Han and P V Sander ldquoTriangle reordering for reducedoverdraw in animated scenesrdquo in Proceedings of the 20thACM SIGGRAPH Symposium on Interactive 3D Graphics andGames pp 23ndash27 ACM 2016

[23] C Weber and M Stamminger ldquoTopological triangle sortingfor predefined camera pathsrdquo in Proceedings of the Confer-ence on Vision Modeling and Visualization pp 153ndash160Eurographics Association 2016

[24] E De Lucas P Marcuello J-M Parcerisa and A GonzalezldquoVisibility rendering order Improving energy efficiency onmobile gpus through frame coherencerdquo IEEE Transactionson Parallel and Distributed Systems 2018

Second it estimates visibility at a primitive-level while theoracle resolves visibility at the finest possible granularityfragment level

Moreover a large fraction of tiles are detected to beredundant and its execution is completely bypassed avoidingnot only the Fragment Shader stage for all their fragmentsbut also the rest of the stages of the Raster Pipeline forthose tiles Figure 9 shows the percentage of detectedredundant tiles ndashproducing the same colors as the previousframendash for our set of benchmarks Results are shown for thebaseline Rendering Elimination (RE) the proposed EVR-aided Rendering Elimination (EVR) and an oracle setup thatcan perfectly identify all tiles of a frame that are equal tothose of the previous frame

0

10

20

30

40

50

60

70

80

90

100

Det

ect

ed

eq

ual

tile

s

EVR RE Oracle

Figure 9 Percentage of detected equal tiles by EVR compared to REand an oracle

On average EVR avoids the rendering of 54 of the tilesreducing 5 more tiles than the baseline RE Predicting oc-cluded primitives and not adding them to the tilersquos signatureallows the detection of equal tiles in benchmarks in whichRE was hardly effective such as 300 or mst The majorityof these tiles that are identified as redundant corresponds toportions of the screen in which WOZ primitives are coveredby NWOZ primitives in the form of a HUD In most casesthe scene contains objects that are in motion but completelyoccluded by NWOZ geometry The layer-based visibilityscheme allows EVR to identify additional redundant tilesin benchmarks with a high degree of redundancy detectedby RE such as cde or mto In some applications such as hayor wmw the additional tiles eliminated exceeds 10 witha maximum of 30

The additional redundant tiles detected results in anaverage 10 reduction of energy consumption comparedto the baseline RE as presented in Figure 10 The earlyvisibility resolution incurs in some overheads which aregrouped together in the figure In the Geometry Pipeline theLayer Generator and FVP tables are accessed to generate alayer identifier which is stored in the Parameter Buffer Inthe Raster Pipeline the layer identifiers are read and writteninto the Layer Buffer When a tile finishes its rendering itsFVP is computed by accessing the Z and Layer Buffers andthe result is stored in the FVP Table Although the required

09

02

03

04

05

06

07

08

09

1

Ener

gy c

on

sum

pti

on

no

rmal

ized

to

RE

Overhead by FVP Computation

Figure 10 Energy consumption of our EVR proposal normalized to RE

sequential check of the two tables for each primitive andeach tile to which it is mapped could incur in some timeoverhead it is more than offset by the reduction in numberof primitives that can skip the signature computation stepsince they are occluded This is shown in Figure 11 whichcompares execution time broken down into Geometry andRaster Pipelines for the Baseline GPU RE and our proposedEVR approach for early visibility resolution Note that REhas to read the temporary hashes held in the Signature Bufferfor all the tiles that a primitive overlaps shift them as manybytes as the size of the primitive and finally combine themwith the hash of the primitive to produce a new signature forthe tile This process is avoided in our scheme if a primitiveis determined to be occluded in a tile since EVR marks it notto be included into the tilersquos signature The only exceptionwhere our EVR scheme does not reduce Geometry cycles ishop a benchmark that has very few primitives concentratedin a reduced amount of tiles Consequently the averagenumber of primitives to combine into the signature of a tile issmall limiting the benefits of occluded primitive detectionOn average our EVR mechanism reduces the execution timein the Geometry Pipeline by 4 with respect to RE

Moreover Rendering Elimination may induce time andenergy overheads in benchmarks where not enough redun-dant tiles are detected to offset the signature computationsuch as 300 or mst On the other hand our scheme is moreeffective at detecting redundant tiles and for non-redundanttiles specially in 3D benchmarks the primitive reordering in-creases the efficiency of the Early Depth Test which reducesthe amount of computations in the fragment processors Thisresults in overall speedups for all benchmarks

VIII RELATED WORK

Occlusion culling is a fundamental problem in computergraphics with an extensive literature spanning more thanthree decades In this section we focus on the most influ-ential works and the ones most related to our proposal

The Z Buffer [4] is the de facto standard to resolvevisibility due to its effectiveness and low implementationcost The Hierarchical Z Buffer [13] is a variation of thebaseline technique in which a depth pyramid is used to testvisibility The base level of the pyramid is the Z Buffer

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

300 ata csn mst ter tib abi arm ale ccs cde coc ctr dpe hay hop mto red wmw wog AVG

0

02

04

06

08

1

No

rmal

ize

d e

xecu

tio

n t

ime

Geometry Raster

Figure 11 Execution time comparison of our EVR proposal and RE against the baseline GPU

and higher levels are constructed by combining the depthof four pixels at the next lower level typically by choosingthe farthest one Entire primitives can be discarded withoutaccessing the Z Buffer by comparing their nearest depthagainst the values in higher levels in the pyramid OurEVR proposal also compares the depth of primitives toa FVP depth which would correspond to the top of thepyramid of the Hierarchical Z Buffer However the FVPdepth contains final visibility information which allowsunlike the Z pyramid to detect primitives that will beoccluded by others processed later Moreover the FVP depthincludes more information than just the top of the Z pyramidallowing the detection of occluded NWOZ primitives that donot use the Z buffer

Z-Prepass [14] draws the scene in two steps first thegeometry is rendered using simple fragment shaders onlyto quickly fill the Z Buffer Later the geometry is renderedagain with proper shaders but now with perfect visibilityinformation in-place so that all occluded fragments can bediscarded This additional render pass incurs in significantoverheads which may not always be offset by the increase inthe fragments discarded in the Early Depth Test By workingat a coarser granularity (primitive instead of fragment) EVRdoes not need to perform the pre-pass but still achievesresults comparable to having complete visibility information

The concept of layers has been previously adopted inthe context of occlusion culling most notably in DepthPeeling [15] an algorithm that renders geometry multipletimes peeling off the surface layer at each pixel in eachpass Recently Andersson et al [16] leveraged a two-layer representation of depths to avoid bandwidth spent inupdating the Hierarchical Z Buffer while in the work ofScheckel and Kolb [17] layers are used in combinationwith the alpha parameter to completely cull transparentfragments Unlike EVR these approaches cannot combinevisibility information of both WOZ and NWOZ primitivesfor a better visibility determination

Computing visibility at a fragment level (known as image-precision [18]) is useful to solve certain problems suchas circular dependencies However resolving visibility ata coarser grain could reduce the number of computations

needed Hardware occlusion queries [19] are a feature thatallow the user to query simple geometry (such as thebounding volumes) against the current contents of the ZBuffer The query counts the number of fragments thatpass the Z Test and the result allows the application toavoid rendering entire objects at the expense of CPU-GPUsynchronization Furthermore as with the Early Depth Testin order for occlusion queries to perform well both objectsand queries must be sent in front-to-back order EVR istransparent to the application in both axis it does not requireneither synchronization nor ordering

Multiple works reduce overshading by means of reorder-ing the primitives that make up a scene Govindaraju et al[20] propose an algorithm to sort non-overlapping objectsin either front-to-back or back-to front order from a givenviewpoint In the work of Chen et al [21] static objectsare preprocessed in order to create a depth-sorted list ofprimitives for every possible viewpoint The approach ofHan and Sander [22] also preprocesses objects to createseveral sorted lists that are indexed at runtime to ensureoptimal order but they consider movement by taking intoaccount not only viewpoints but also several key framesWeber and Stamminger [23] use a graph representationof dependencies in animated scenes with a fixed camerato sort primitives accordingly and leverage frame-to-framecoherence to merge different graphs and keep the overallstructure manageable VRO [24] also takes advantage oftemporal coherence to reorder objects entirely in hardwareand reduce overshading Unlike these approaches EVR isapplied at a finer granularity (primitive instead of object)does not need to perform any preprocess and can also beemployed in interactive scenes not just animated ones

IX CONCLUSIONS

We have presented a mechanism to determine visibilityin early stages of the Graphics Pipeline based on exploitingframe coherence Since consecutive frames tend to be verysimilar we use the information of a frame to estimate thevisibility for the following one

The proposed technique collects the depth of the farthestvisible primitive of every tile whenever its rendering processis complete For each overlapped tile the depth of a primitive

is compared against the depth stored for that tile in thepreceding frame If it is farther the primitive is occluded

This paper demonstrates the benefits of early visibilityprediction to remove ineffectual computations by increasingthe effectiveness of the Early Z Test a commonly usedtechnique in contemporary GPUs and Rendering Elimina-tion a recently proposed technique to exploit redundantcomputations The former works at pixel granularity and thelatter works at tile granularity

Using the predicted visibility information opaque prim-itives whose visibility is resolved using the Z Buffer arereordered such that primitives predicted as visible are ren-dered first which avoids the shading of occluded fragmentsBesides primitives predicted to be occluded are not con-sidered when generating the signature used by RenderingElimination to identify tiles that are equal to the ones in theprevious frame That increases the number of tiles that areidentified as redundant and consequently whose renderingcan be avoided

Our technique provides average speedups of 39 andenergy savings of 43 for a set of commercial Android ap-plications The reorder mechanism achieves overshading re-ductions comparable to having a Z Buffer filled with perfectvisibility information without requiring any additional renderpass to compute depths On the other hand by improvingthe tile redundancy detection of Rendering Elimination theraster pipeline of the GPU skips the rendering of more thanhalf of the tiles on average

X ACKNOWLEDGEMENTS

This work has been partially supported by the Span-ish State Research Agency under grant TIN2016-75344-R (AEIFEDER EU) and by the Generalitat de Catalunyaunder the AGAUR-FI program

REFERENCES

[1] M Anglada E de Lucas J-M Parcerisa J L AragonP Marcuello and A Gonzalez ldquoRendering elimination Earlydiscard of redundant tiles in the graphics pipelinerdquo in Pro-ceedings of the 25th IEEE International Symposium on High-Performance Computer Architecture IEEE 2019

[2] ldquoArm mali-450 gpurdquo httpsdeveloperarmcomproductsgraphics-and-multimediamali-gpusmali-450-gpu accessedDecember 10 2018

[3] ldquoHardware gpu marketrdquo httphwstatsunity3dcommobilegpuhtml accessed December 10 2018

[4] E Catmull ldquoA subdivision algorithm for computer display ofcurved surfacesrdquo tech rep Utah University Salt Lake CitySchool of Computing 1974

[5] ldquoPainterrsquos algorithmrdquo httpswwwsiggraphorgeducationmaterialsHyperGraphscanlinevisibilitypainterhtmaccessed December 10 2018

[6] J-M Arnau J-M Parcerisa and P Xekalakis ldquoTeapot atoolset for evaluating performance power and image qualityon mobile graphics systemsrdquo in Proceedings of the 27thInternational ACM Conference on Supercomputing pp 37ndash46 ACM 2013

[7] ldquoAndroid studiordquo httpsdeveloperandroidcomstudioindexhtml accessed December 10 2018

[8] ldquoGallium3drdquo httpswwwfreedesktoporgwikiSoftwaregallium accessed December 10 2018

[9] S Li J H Ahn R D Strong J B Brockman D M Tullsenand N P Jouppi ldquoMcPAT An Integrated Power Area andTiming Modeling Framework for Multicore and ManycoreArchitecturesrdquo in Proceedings of the 42nd Annual IEEEACMInternational Symposium on Microarchitecture pp 469ndash4802009

[10] P Rosenfeld E Cooper-Balis and B Jacob ldquoDramsim2 Acycle accurate memory system simulatorrdquo IEEE ComputerArchitecture Letters vol 10 no 1 pp 16ndash19 2011

[11] ldquoGoogle playrdquo httpsplaygooglecom accessed December10 2018

[12] ldquoMobile game statisticsrdquo httpsmediumcomsm appintelnew-mobile-game-statistics-every-game-publisher-should-know-in-2016-f1f8eef64f66 accessed December 102018

[13] N Greene M Kass and G Miller ldquoHierarchical z-buffervisibilityrdquo in Proceedings of the 20th Annual Conference onComputer Graphics and Interactive Techniques pp 231ndash238ACM 1993

[14] ldquoEarly z rejectionrdquo httpssoftwareintelcomen-usarticlesearly-z-rejection-sample accessed December 10 2018

[15] C Everitt ldquoInteractive order-independent transparencyrdquoWhite paper NVIDIA vol 2 no 6 p 7 2001

[16] M Andersson J Hasselgren and T Akenine-MollerldquoMasked depth culling for graphics hardwarerdquo ACM Trans-actions on Graphics vol 34 no 6 p 188 2015

[17] S Scheckel and A Kolb ldquoMin-max mipmaps for efficient2d occlusion cullingrdquo in Conference on Computer GraphicsVisualization and Computer Vision 2016

[18] I E Sutherland R F Sproull and R A SchumackerldquoA characterization of ten hidden-surface algorithmsrdquo ACMComputing Surveys vol 6 no 1 pp 1ndash55 1974

[19] O Mattausch J Bittner and M Wimmer ldquoChc++ Coherenthierarchical culling revisitedrdquo in Computer Graphics Forumvol 27 pp 221ndash230 Wiley Online Library 2008

[20] N K Govindaraju M Henson M C Lin and D ManochaldquoInteractive visibility ordering and transparency computationsamong geometric primitives in complex environmentsrdquo inProceedings of the 2005 Symposium on Interactive 3D Graph-ics and Games pp 49ndash56 ACM 2005

[21] G Chen P V Sander D Nehab L Yang and L Hu ldquoDepth-presorted triangle listsrdquo ACM Transactions on Graphicsvol 31 no 6 p 160 2012

[22] S Han and P V Sander ldquoTriangle reordering for reducedoverdraw in animated scenesrdquo in Proceedings of the 20thACM SIGGRAPH Symposium on Interactive 3D Graphics andGames pp 23ndash27 ACM 2016

[23] C Weber and M Stamminger ldquoTopological triangle sortingfor predefined camera pathsrdquo in Proceedings of the Confer-ence on Vision Modeling and Visualization pp 153ndash160Eurographics Association 2016

[24] E De Lucas P Marcuello J-M Parcerisa and A GonzalezldquoVisibility rendering order Improving energy efficiency onmobile gpus through frame coherencerdquo IEEE Transactionson Parallel and Distributed Systems 2018

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

Bas

eR

EEV

R

300 ata csn mst ter tib abi arm ale ccs cde coc ctr dpe hay hop mto red wmw wog AVG

0

02

04

06

08

1

No

rmal

ize

d e

xecu

tio

n t

ime

Geometry Raster

Figure 11 Execution time comparison of our EVR proposal and RE against the baseline GPU

and higher levels are constructed by combining the depthof four pixels at the next lower level typically by choosingthe farthest one Entire primitives can be discarded withoutaccessing the Z Buffer by comparing their nearest depthagainst the values in higher levels in the pyramid OurEVR proposal also compares the depth of primitives toa FVP depth which would correspond to the top of thepyramid of the Hierarchical Z Buffer However the FVPdepth contains final visibility information which allowsunlike the Z pyramid to detect primitives that will beoccluded by others processed later Moreover the FVP depthincludes more information than just the top of the Z pyramidallowing the detection of occluded NWOZ primitives that donot use the Z buffer

Z-Prepass [14] draws the scene in two steps first thegeometry is rendered using simple fragment shaders onlyto quickly fill the Z Buffer Later the geometry is renderedagain with proper shaders but now with perfect visibilityinformation in-place so that all occluded fragments can bediscarded This additional render pass incurs in significantoverheads which may not always be offset by the increase inthe fragments discarded in the Early Depth Test By workingat a coarser granularity (primitive instead of fragment) EVRdoes not need to perform the pre-pass but still achievesresults comparable to having complete visibility information

The concept of layers has been previously adopted inthe context of occlusion culling most notably in DepthPeeling [15] an algorithm that renders geometry multipletimes peeling off the surface layer at each pixel in eachpass Recently Andersson et al [16] leveraged a two-layer representation of depths to avoid bandwidth spent inupdating the Hierarchical Z Buffer while in the work ofScheckel and Kolb [17] layers are used in combinationwith the alpha parameter to completely cull transparentfragments Unlike EVR these approaches cannot combinevisibility information of both WOZ and NWOZ primitivesfor a better visibility determination

Computing visibility at a fragment level (known as image-precision [18]) is useful to solve certain problems suchas circular dependencies However resolving visibility ata coarser grain could reduce the number of computations

needed Hardware occlusion queries [19] are a feature thatallow the user to query simple geometry (such as thebounding volumes) against the current contents of the ZBuffer The query counts the number of fragments thatpass the Z Test and the result allows the application toavoid rendering entire objects at the expense of CPU-GPUsynchronization Furthermore as with the Early Depth Testin order for occlusion queries to perform well both objectsand queries must be sent in front-to-back order EVR istransparent to the application in both axis it does not requireneither synchronization nor ordering

Multiple works reduce overshading by means of reorder-ing the primitives that make up a scene Govindaraju et al[20] propose an algorithm to sort non-overlapping objectsin either front-to-back or back-to front order from a givenviewpoint In the work of Chen et al [21] static objectsare preprocessed in order to create a depth-sorted list ofprimitives for every possible viewpoint The approach ofHan and Sander [22] also preprocesses objects to createseveral sorted lists that are indexed at runtime to ensureoptimal order but they consider movement by taking intoaccount not only viewpoints but also several key framesWeber and Stamminger [23] use a graph representationof dependencies in animated scenes with a fixed camerato sort primitives accordingly and leverage frame-to-framecoherence to merge different graphs and keep the overallstructure manageable VRO [24] also takes advantage oftemporal coherence to reorder objects entirely in hardwareand reduce overshading Unlike these approaches EVR isapplied at a finer granularity (primitive instead of object)does not need to perform any preprocess and can also beemployed in interactive scenes not just animated ones

IX CONCLUSIONS

We have presented a mechanism to determine visibilityin early stages of the Graphics Pipeline based on exploitingframe coherence Since consecutive frames tend to be verysimilar we use the information of a frame to estimate thevisibility for the following one

The proposed technique collects the depth of the farthestvisible primitive of every tile whenever its rendering processis complete For each overlapped tile the depth of a primitive

is compared against the depth stored for that tile in thepreceding frame If it is farther the primitive is occluded

This paper demonstrates the benefits of early visibilityprediction to remove ineffectual computations by increasingthe effectiveness of the Early Z Test a commonly usedtechnique in contemporary GPUs and Rendering Elimina-tion a recently proposed technique to exploit redundantcomputations The former works at pixel granularity and thelatter works at tile granularity

Using the predicted visibility information opaque prim-itives whose visibility is resolved using the Z Buffer arereordered such that primitives predicted as visible are ren-dered first which avoids the shading of occluded fragmentsBesides primitives predicted to be occluded are not con-sidered when generating the signature used by RenderingElimination to identify tiles that are equal to the ones in theprevious frame That increases the number of tiles that areidentified as redundant and consequently whose renderingcan be avoided

Our technique provides average speedups of 39 andenergy savings of 43 for a set of commercial Android ap-plications The reorder mechanism achieves overshading re-ductions comparable to having a Z Buffer filled with perfectvisibility information without requiring any additional renderpass to compute depths On the other hand by improvingthe tile redundancy detection of Rendering Elimination theraster pipeline of the GPU skips the rendering of more thanhalf of the tiles on average

X ACKNOWLEDGEMENTS

This work has been partially supported by the Span-ish State Research Agency under grant TIN2016-75344-R (AEIFEDER EU) and by the Generalitat de Catalunyaunder the AGAUR-FI program

REFERENCES

[1] M Anglada E de Lucas J-M Parcerisa J L AragonP Marcuello and A Gonzalez ldquoRendering elimination Earlydiscard of redundant tiles in the graphics pipelinerdquo in Pro-ceedings of the 25th IEEE International Symposium on High-Performance Computer Architecture IEEE 2019

[2] ldquoArm mali-450 gpurdquo httpsdeveloperarmcomproductsgraphics-and-multimediamali-gpusmali-450-gpu accessedDecember 10 2018

[3] ldquoHardware gpu marketrdquo httphwstatsunity3dcommobilegpuhtml accessed December 10 2018

[4] E Catmull ldquoA subdivision algorithm for computer display ofcurved surfacesrdquo tech rep Utah University Salt Lake CitySchool of Computing 1974

[5] ldquoPainterrsquos algorithmrdquo httpswwwsiggraphorgeducationmaterialsHyperGraphscanlinevisibilitypainterhtmaccessed December 10 2018

[6] J-M Arnau J-M Parcerisa and P Xekalakis ldquoTeapot atoolset for evaluating performance power and image qualityon mobile graphics systemsrdquo in Proceedings of the 27thInternational ACM Conference on Supercomputing pp 37ndash46 ACM 2013

[7] ldquoAndroid studiordquo httpsdeveloperandroidcomstudioindexhtml accessed December 10 2018

[8] ldquoGallium3drdquo httpswwwfreedesktoporgwikiSoftwaregallium accessed December 10 2018

[9] S Li J H Ahn R D Strong J B Brockman D M Tullsenand N P Jouppi ldquoMcPAT An Integrated Power Area andTiming Modeling Framework for Multicore and ManycoreArchitecturesrdquo in Proceedings of the 42nd Annual IEEEACMInternational Symposium on Microarchitecture pp 469ndash4802009

[10] P Rosenfeld E Cooper-Balis and B Jacob ldquoDramsim2 Acycle accurate memory system simulatorrdquo IEEE ComputerArchitecture Letters vol 10 no 1 pp 16ndash19 2011

[11] ldquoGoogle playrdquo httpsplaygooglecom accessed December10 2018

[12] ldquoMobile game statisticsrdquo httpsmediumcomsm appintelnew-mobile-game-statistics-every-game-publisher-should-know-in-2016-f1f8eef64f66 accessed December 102018

[13] N Greene M Kass and G Miller ldquoHierarchical z-buffervisibilityrdquo in Proceedings of the 20th Annual Conference onComputer Graphics and Interactive Techniques pp 231ndash238ACM 1993

[14] ldquoEarly z rejectionrdquo httpssoftwareintelcomen-usarticlesearly-z-rejection-sample accessed December 10 2018

[15] C Everitt ldquoInteractive order-independent transparencyrdquoWhite paper NVIDIA vol 2 no 6 p 7 2001

[16] M Andersson J Hasselgren and T Akenine-MollerldquoMasked depth culling for graphics hardwarerdquo ACM Trans-actions on Graphics vol 34 no 6 p 188 2015

[17] S Scheckel and A Kolb ldquoMin-max mipmaps for efficient2d occlusion cullingrdquo in Conference on Computer GraphicsVisualization and Computer Vision 2016

[18] I E Sutherland R F Sproull and R A SchumackerldquoA characterization of ten hidden-surface algorithmsrdquo ACMComputing Surveys vol 6 no 1 pp 1ndash55 1974

[19] O Mattausch J Bittner and M Wimmer ldquoChc++ Coherenthierarchical culling revisitedrdquo in Computer Graphics Forumvol 27 pp 221ndash230 Wiley Online Library 2008

[20] N K Govindaraju M Henson M C Lin and D ManochaldquoInteractive visibility ordering and transparency computationsamong geometric primitives in complex environmentsrdquo inProceedings of the 2005 Symposium on Interactive 3D Graph-ics and Games pp 49ndash56 ACM 2005

[21] G Chen P V Sander D Nehab L Yang and L Hu ldquoDepth-presorted triangle listsrdquo ACM Transactions on Graphicsvol 31 no 6 p 160 2012

[22] S Han and P V Sander ldquoTriangle reordering for reducedoverdraw in animated scenesrdquo in Proceedings of the 20thACM SIGGRAPH Symposium on Interactive 3D Graphics andGames pp 23ndash27 ACM 2016

[23] C Weber and M Stamminger ldquoTopological triangle sortingfor predefined camera pathsrdquo in Proceedings of the Confer-ence on Vision Modeling and Visualization pp 153ndash160Eurographics Association 2016

[24] E De Lucas P Marcuello J-M Parcerisa and A GonzalezldquoVisibility rendering order Improving energy efficiency onmobile gpus through frame coherencerdquo IEEE Transactionson Parallel and Distributed Systems 2018

is compared against the depth stored for that tile in thepreceding frame If it is farther the primitive is occluded

This paper demonstrates the benefits of early visibilityprediction to remove ineffectual computations by increasingthe effectiveness of the Early Z Test a commonly usedtechnique in contemporary GPUs and Rendering Elimina-tion a recently proposed technique to exploit redundantcomputations The former works at pixel granularity and thelatter works at tile granularity

Using the predicted visibility information opaque prim-itives whose visibility is resolved using the Z Buffer arereordered such that primitives predicted as visible are ren-dered first which avoids the shading of occluded fragmentsBesides primitives predicted to be occluded are not con-sidered when generating the signature used by RenderingElimination to identify tiles that are equal to the ones in theprevious frame That increases the number of tiles that areidentified as redundant and consequently whose renderingcan be avoided

Our technique provides average speedups of 39 andenergy savings of 43 for a set of commercial Android ap-plications The reorder mechanism achieves overshading re-ductions comparable to having a Z Buffer filled with perfectvisibility information without requiring any additional renderpass to compute depths On the other hand by improvingthe tile redundancy detection of Rendering Elimination theraster pipeline of the GPU skips the rendering of more thanhalf of the tiles on average

X ACKNOWLEDGEMENTS

This work has been partially supported by the Span-ish State Research Agency under grant TIN2016-75344-R (AEIFEDER EU) and by the Generalitat de Catalunyaunder the AGAUR-FI program

REFERENCES

[1] M Anglada E de Lucas J-M Parcerisa J L AragonP Marcuello and A Gonzalez ldquoRendering elimination Earlydiscard of redundant tiles in the graphics pipelinerdquo in Pro-ceedings of the 25th IEEE International Symposium on High-Performance Computer Architecture IEEE 2019

[2] ldquoArm mali-450 gpurdquo httpsdeveloperarmcomproductsgraphics-and-multimediamali-gpusmali-450-gpu accessedDecember 10 2018

[3] ldquoHardware gpu marketrdquo httphwstatsunity3dcommobilegpuhtml accessed December 10 2018

[4] E Catmull ldquoA subdivision algorithm for computer display ofcurved surfacesrdquo tech rep Utah University Salt Lake CitySchool of Computing 1974

[5] ldquoPainterrsquos algorithmrdquo httpswwwsiggraphorgeducationmaterialsHyperGraphscanlinevisibilitypainterhtmaccessed December 10 2018

[6] J-M Arnau J-M Parcerisa and P Xekalakis ldquoTeapot atoolset for evaluating performance power and image qualityon mobile graphics systemsrdquo in Proceedings of the 27thInternational ACM Conference on Supercomputing pp 37ndash46 ACM 2013

[7] ldquoAndroid studiordquo httpsdeveloperandroidcomstudioindexhtml accessed December 10 2018

[8] ldquoGallium3drdquo httpswwwfreedesktoporgwikiSoftwaregallium accessed December 10 2018

[9] S Li J H Ahn R D Strong J B Brockman D M Tullsenand N P Jouppi ldquoMcPAT An Integrated Power Area andTiming Modeling Framework for Multicore and ManycoreArchitecturesrdquo in Proceedings of the 42nd Annual IEEEACMInternational Symposium on Microarchitecture pp 469ndash4802009

[10] P Rosenfeld E Cooper-Balis and B Jacob ldquoDramsim2 Acycle accurate memory system simulatorrdquo IEEE ComputerArchitecture Letters vol 10 no 1 pp 16ndash19 2011

[11] ldquoGoogle playrdquo httpsplaygooglecom accessed December10 2018

[12] ldquoMobile game statisticsrdquo httpsmediumcomsm appintelnew-mobile-game-statistics-every-game-publisher-should-know-in-2016-f1f8eef64f66 accessed December 102018

[13] N Greene M Kass and G Miller ldquoHierarchical z-buffervisibilityrdquo in Proceedings of the 20th Annual Conference onComputer Graphics and Interactive Techniques pp 231ndash238ACM 1993

[14] ldquoEarly z rejectionrdquo httpssoftwareintelcomen-usarticlesearly-z-rejection-sample accessed December 10 2018

[15] C Everitt ldquoInteractive order-independent transparencyrdquoWhite paper NVIDIA vol 2 no 6 p 7 2001

[16] M Andersson J Hasselgren and T Akenine-MollerldquoMasked depth culling for graphics hardwarerdquo ACM Trans-actions on Graphics vol 34 no 6 p 188 2015

[17] S Scheckel and A Kolb ldquoMin-max mipmaps for efficient2d occlusion cullingrdquo in Conference on Computer GraphicsVisualization and Computer Vision 2016

[18] I E Sutherland R F Sproull and R A SchumackerldquoA characterization of ten hidden-surface algorithmsrdquo ACMComputing Surveys vol 6 no 1 pp 1ndash55 1974

[19] O Mattausch J Bittner and M Wimmer ldquoChc++ Coherenthierarchical culling revisitedrdquo in Computer Graphics Forumvol 27 pp 221ndash230 Wiley Online Library 2008

[20] N K Govindaraju M Henson M C Lin and D ManochaldquoInteractive visibility ordering and transparency computationsamong geometric primitives in complex environmentsrdquo inProceedings of the 2005 Symposium on Interactive 3D Graph-ics and Games pp 49ndash56 ACM 2005

[21] G Chen P V Sander D Nehab L Yang and L Hu ldquoDepth-presorted triangle listsrdquo ACM Transactions on Graphicsvol 31 no 6 p 160 2012

[22] S Han and P V Sander ldquoTriangle reordering for reducedoverdraw in animated scenesrdquo in Proceedings of the 20thACM SIGGRAPH Symposium on Interactive 3D Graphics andGames pp 23ndash27 ACM 2016

[23] C Weber and M Stamminger ldquoTopological triangle sortingfor predefined camera pathsrdquo in Proceedings of the Confer-ence on Vision Modeling and Visualization pp 153ndash160Eurographics Association 2016

[24] E De Lucas P Marcuello J-M Parcerisa and A GonzalezldquoVisibility rendering order Improving energy efficiency onmobile gpus through frame coherencerdquo IEEE Transactionson Parallel and Distributed Systems 2018