How to reuse vertices across primitives in OpenGL

Question

I am using OpenGL in C++ (technically EGL, on a Jetson Nano.)

Let's say I want to draw N Quads. Imagine just a list of colored rectangles. There may be a few thousand such rectangles in the frame.

I want to use two vertex buffers:

1. One that defines the geometry of each quad.
2. One that defines the properties common to each quad.

The first vertex buffer should define the geometry of each quad. It should have only 4 vertices in it and its data would be just the corners of a quad. Something like:

0, 0, // top left
1, 0, // top right
0, 1, // bottom left
1, 1, // bottom right

Then the second vertex buffer should have just the x,y,width,height of all the rectangles.

x1, y1, width1, height1, color1,
x2, y2, width2, height2, color2,
x3, y3, width3, height3, color3,
x4, y4, width4, height4, color4,
x5, y5, width5, height5, color5,
x6, y6, width6, height6, color6,
... etc.

The thing is that each one of the items in my rectangle buffer should apply to 4 vertices in the vertex buffer.

Is there a way to set this up so that it keeps reusing the same 4 quad vertices over and over for each rectangle and applies the same rectangle properties to 4 vertices at a time?

I'm imagining there's something I can do so that I say that the first vertex buffer should use one element per vertex and wraps around, but the second vertex buffer uses one element per every four vertices or something like that.

How do I set this up?

What I do now:

Right now I need one vertex buffer that just has the quad vertices repeated over and over as many times as I have instances.

0, 0, // (1) top left
1, 0, // 
0, 1, // 
1, 1  // 
0, 0, // (2) top left
1, 0, // 
0, 1, // 
1, 1, // 
0, 0, // (3) top left
1, 0, // 
0, 1, // 
1, 1, // 
... etc

And my second buffer duplicates its data for each vertex:

x1, y1, width1, height1, color1,
x1, y1, width1, height1, color1,
x1, y1, width1, height1, color1,
x1, y1, width1, height1, color1,
x2, y2, width2, height2, color2,
x2, y2, width2, height2, color2,
x2, y2, width2, height2, color2,
x2, y2, width2, height2, color2,
x3, y3, width3, height3, color3,
x3, y3, width3, height3, color3,
x3, y3, width3, height3, color3,
x3, y3, width3, height3, color3,
x4, y4, width4, height4, color4,
x4, y4, width4, height4, color4,
x4, y4, width4, height4, color4,
x4, y4, width4, height4, color4,
x5, y5, width5, height5, color5,
x5, y5, width5, height5, color5,
x5, y5, width5, height5, color5,
x5, y5, width5, height5, color5,
x6, y6, width6, height6, color6,
x6, y6, width6, height6, color6,
x6, y6, width6, height6, color6,
x6, y6, width6, height6, color6,
... etc.

This seems really inefficient and I just want to specify the first 4 vertices once and have it keep reusing them somehow rather than duplicating these 4 vertices N times to have a total of 4*N vertices in my first buffer. And I only want to specify the x,y,width,height,color attributes once for each quad for a total of N vertices, and not once for each overall vertex for a total of 4*N vertices.

What do I do?

Answer 1

Generally speaking, the most efficient way to render a series of quads is to... render a series of quads. You don't send width/height or other per-instance information; you compute the actual positions of the 4 vertices on the CPU and you write them to GPU memory using appropriate buffer object streaming techniques. Specifically, avoid trying to change only a few quads; if your data isn't static, it's probably going to be better to re-upload all of it (to a different/invalidated buffer) rather than modify only a few bytes in-situ.

Your hypothetical alternative would only perform better in two scenarios: if the bandwidth of writing data to the GPU is your current bottleneck (whether due to quads or some other transfers you're doing) or if the bandwidth of reading data for rendering is the current bottleneck.

You can mitigate this issue by reducing the size of the vertex data. Since we're talking 2D quads, you could very well use shorts for the XY position of each vertex. Or 16-bit floats. Either way, this means that each vertex (position + color) only takes up 8 bytes, which means a quad is just 32-bytes of data. Obviously 12 bytes is less than 32 (12 being the per-instance cost if you use similar compression), but it's still a 33% reduction over the 48 bytes that full float positions would use.

---

If you have done your profiling homework and have determined that 32-bytes-per-quad is too much, vertex instancing is still a bad idea. It is well known that, on some hardware, extremely small instances can kill your VS performance. Therefore, it should be avoided.

In this case, it may be best to forgo all vertex attribute usage (your VAO should have all arrays disable and your VS should have no in values defined). Instead, you should fetch instance data directly from SSBOs.

The gl_VertexID input value tells you what vertex index is being rendered. Given that you're rendering quads, the current instance would be gl_VertexID / 4. And the current vertex within the quad is gl_VertexID % 4. So your VS would look something like this:

struct instance
{
  vec2 position;
  vec2 size;
  uint color; //Packed as 4 bytes; unpack with unpackUnorm4x8
  uint padding; //Padding needed due to alignment/stride of 8 bytes.
};

layout(binding = 0, std430) buffer instance_data
{
  instance instances[];
};

vec2[4] vertex_table =
{
  vec2{0, 0},
  vec2{1, 0},
  vec2{0, 1},
  vec2{1, 1},
};

void main()
{
    instance curr_instance = instances[gl_VertexID / 4];
    vec2 vertex = vertex_table[gl_VertexID % 4];

    vertex = curr_instance.position + (curr_instance.size * vertex);
    gl_Position = vec4(vertex.xy, 0.0, 1.0);
}

How fast this sort of thing will be depends entirely on how well your GPU handles these kinds of global memory reads. Note that it is at least hypothetically possible to reduce the size of the per-instance data back to 12. You can pack the position and size into two 16-bit shorts or half-floats, using unpackUnorm2x16 or unpackHalf2x16 to unpack these values, respectively. If you do this, then your instance struct is just 3 uint values, and there is no need for padding.