Unexpected and Inefficient ComputeBuffer behavior in OpenGL

Hello folks!

My team is encountering some unexpected behavior when utilizing Compute Buffers specifically when using OpenGL. This behavior works as expected when building for DirectX.

Here is the specific issue as I understand it (I'm a Unity Engineer, this was discovered by our Graphics Engineer). For some context, this is being used while rendering a large amount of mesh data using a ComputeBuffer and DrawProcedural.

• We are using a single 256MB Buffer to store our mesh data, split into 64kb chunks (pages).
• Each frame we may write new data to some number of these pages in the buffer. This is currently done using the ComputeBuffer.SetData() function.
• We are using the mesh data for two purposes each frame:
  • 1. As an input to a compute shader to perform culling
  • 2. As an input to a vertex shader to actually render the mesh data.
• On D3D11, this is working fine.
• On OpenGL, the rendering doesn't work as expected.
• In RenderDoc with OpenGL, we observe the following:
  • In our code, we only create one buffer to store mesh data, but in RenderDoc, it looks like a different buffer object can be used in different frames. This seems to suggest that Unity is creating multiple buffer objects.
    
  • We noticed a glUnmapBuffer() function call. The mapped range appears to be the entire length of the buffer i.e. 256 MB. There's nothing in our code where we try to write data to the entire range of the buffer all at once, so we're not entirely sure what Unity is trying to do here.
  • After unmapping the buffer, the buffer appears to contain all zeros i.e. no valid data.
• Based on the above observations in RenderDoc, our Graphics Engineer speculates that Unity is trying to perform some sort of synchronization by creating multiple buffer objects and copying data between them (hence the glUnmapBuffer). Copying 256 MB of data would of course not be very efficient, and clearly it's not working either, as the buffer contains all zeros after unmapping.
• A fix appears to be to use ComputeBufferMode.SubUpdates and ComputeBuffer.BeginWrite() rather than SetData(). However, this has the disadvantage that it is completely unsynchronized and so we would likely have to write manual sync code to ensure we avoid visual artifacts.
  

This is the best description we have of the issue, so hopefully someone from Unity can chime in and may have an immediate answer. If not, it should be possible for us to abstract this behavior into a demo project, but it would take some time.

Thanks!

 

Thank you for your response!

We will put together a small project for the OpenGL bug and submit a report.

Thank you for the detail on the *why* of the situation as well, I can see how this functionality would work well for the average use case. We are definitely outside the bounds of average use case, so it's understandable we'd have to do some extra work in some areas like this. The tip about async readback is helpful as well, so we'll investigate that route.

Thanks again!

 

Interesting, I'm doing something similar (procedural drawing with geometry data being read from structured buffers in the vertex shader) and facing several issues on Switch (including GPU crashes), and this gives me some ideas.

Unfortunately I'm on an older Unity, so no BeginWrite for me. I'm thinking of refactoring so the CPU never directly writes into the buffers I need to modify. Instead, I write the modified data to a smaller buffer, and use a compute shader to perform the place the data in the target indices.

It's a shame there's no ComputeBuffer.CopyData(), would make my life easier. I have some data produced by compute shaders which would benefit from being stored in constant buffers to be consumed by other shaders, and in DX11 you cannot create a buffer that is both constant and structured. Maybe a native plugin can work around that.