Discussion on sending many small buffers to gpu per frame

[JMDowns]

TL;DR The engine that I am working on sends 45,290 buffers to the gpu in a degenerate scenario, and I was curious what other people had to say about sending many small buffers to the gpu.

I was working on a voxel rendering engine, and I allow for config-defined chunk sizes. One of the degenerate cases I've noticed is where the chunk size = 1 and the amount of chunks in view is sufficiently large (4529 for me), and this case caused 45,290 buffers (half of the buffers are four vertices, half of the buffers are six indices) to be sent to the GPU every frame. Lag followed. Sending so many buffers is something that I'm not too worried about, since I don't plan on allowing this case in the final product, but I thought it was an interesting point of discussion.

Have other people encountered an issue like this? Is there a way of mitigating the lag besides just sending less buffers? What are the general thoughts and patterns that you all could apply to this situation, to restructure code? Any two cents on the matter in general?

[kpreid]

In the big picture, just about any renderer will have some kind of input that it's asked to render for which it will turn out to be very slow. That's just one of the things we have to accept in computer graphics; you have to pick two out of three of

1. accepts as input an arbitrary scene
2. finishes in reasonable time
3. draws the scene correctly, without any compromises

But in your particular case, this isn't even about the scene input, but a performance tradeoff parameter; the entire point of chunked voxel rendering is to have fewer draw calls than one per voxel. So, setting the chunk size to 1 is just not something that is useful to support; it's deliberately defeating the rendering architecture. (An exception would be if you want to render a very small scene, like a preview of just a few blocks. Then, the benefits of not needing to construct or update a combined chunk mesh might exceed the cost of the additional buffers and draw calls.)

All that said, it sounds like you could do a little better with your buffer handling. Just because you want to conditionally draw 6 faces doesn't mean that you need 6 separate buffers; you can put all 6 sets in one buffer, but draw different ranges of that buffer.

Also, what exactly do you mean by “sent to the GPU”? You shouldn't need to write every buffer every frame. It's true that you don't want to have too many separate draw calls, though.

[JMDowns]

In the big picture, just about any renderer will have some kind of input that it's asked to render for which it will turn out to be very slow. That's just one of the things we have to accept in computer graphics; you have to pick two out of three of

accepts as input an arbitrary scene
finishes in reasonable time
draws the scene correctly, without any compromises

Noted, thanks for the trichotomy. New to graphics dev here, so learning new conventions is always good!

But in your particular case, this isn't even about the scene input, but a performance tradeoff parameter; the entire point of chunked voxel rendering is to have fewer draw calls than one per voxel. So, setting the chunk size to 1 is just not something that is useful to support; it's deliberately defeating the rendering architecture. (An exception would be if you want to render a very small scene, like a preview of just a few blocks. Then, the benefits of not needing to construct or update a combined chunk mesh might exceed the cost of the additional buffers and draw calls.)

Oh yeah, I'm not planning on keeping the 1 voxel chunk size when I finish stuff up. And with how fast a mesher is, I'm not even sure there would be much of a performance degradation with a larger mesh for smaller scenes. Thanks again for the wisdom!

All that said, it sounds like you could do a little better with your buffer handling. Just because you want to conditionally draw 6 faces doesn't mean that you need 6 separate buffers; you can put all 6 sets in one buffer, but draw different ranges of that buffer.

That is a very true point. Would drawing different ranges of the same buffer lead to a performance increase? It feels to me like I'm still making the same amount of draw calls, since I would do multiple set vertex/index buffer commands for the slices. To be honest though my method of drawing is set_vertex_buffer, set_index_buffer, draw_indexed, so if there's any improvements there, please let me know.

Also, what exactly do you mean by “sent to the GPU”? You shouldn't need to write every buffer every frame. It's true that you don't want to have too many separate draw calls, though.

Sorry for the vague wording. By 'sent to the GPU', I mean the vertex buffer is set, the index buffer is set, and a draw_indexed call is made. I'm not writing to the vertex/index buffers every frame by any means.

[kpreid]

Would drawing different ranges of the same buffer lead to a performance increase? It feels to me like I'm still making the same amount of draw calls,

The benefit here is not at draw time but that you don't have to manage so many buffers, which will speed up chunk meshing and updates. Also, you can combine two or three draw calls into one if the ranges happen to be contiguous.

[JMDowns]

The benefit here is not at draw time but that you don't have to manage so many buffers, which will speed up chunk meshing and updates. Also, you can combine two or three draw calls into one if the ranges happen to be contiguous.

That is definitely fair. I haven't gotten to chunk updates yet so that hadn't crossed my mind, and the contiguous slices would allow for less draw calls to be made.