Game Development Reference
In-Depth Information
for (size_t i = 0; i <VertexFormat. size (); ++i)
{
glBindVertexArray( VertexFormat[i]. Name );
for (size_t j = 0; j <Mesh.size (); ++j)
glDrawElementBaseVertex(
Mesh[j].Mode , Mesh[j].Count , Mesh[j].Type ,
Mesh[j].Offset , Mesh[j].BaseVertex);
}
Listing 2.1. Ecient draws submissions.
The test should not be CPU bound.
The test should not be primitive limited.
The test should not be shading limited.
The test should not be blending limited.
Our tests render a single quad (two triangles) per draw. The quad we render is
only 16 pixels to ensure that the GPU or the drivers do not discard the draws.
Rendering a slightly larger number of pixels doesn't affect the frame rate, which
confirms that shading or blending is not the bottleneck.
We create three tests. The first one uses instancing so that only a single draw
call is performed while multiple draws are submitted. Instancing ensures that the
GPU command processor [AMD 12] does the draw submission, which guarantees
that we are not CPU bound. Hence, we use this test to evaluate the constant GPU
cost for a draw submission. In a second test (Listing 2.1), we render different
meshes of identical vertex formats using a shared vertex array object (VAO),
utilizing the base vertex parameter to avoid state changes [Romanick 08]. In this
test we evaluate the constant CPU cost for a draw call. Finally in a third test
(Listing 2.2), we bind a different VAO [Koch 09] for every draw call to evaluate
the cost of switching a single resource.
We observe from the results of our tests ( Figures 2.3 and 2.4 ) that the GPU
is extremely ecient at processing draws. For example, Figure 2.3 shows that
for (size_t i = 0; i <Mesh.size(); ++i)
{
glBindVertexArray(Mesh[i].Name);
glDrawElement(Mesh[i].Mode, Mesh[i].Count, Mesh[i].Type, Mesh[i].Offset);
}
Listing 2.2. Intensive resource switching approach to submit draws.
 
Search Nedrilad ::




Custom Search