I have a C++ and GLSL code that computes Marching Cubes. It's slow as hell, and the biggest problem is that it calculates the right number of triangles, but not the right vertices.

The C++ code is large, and it's at: https://github.com/sjhalayka/julia4d3/blob/a933ca3d2a7129db93140d858c9ecf24f55f43af/js_state_machine.h#L236​

The GLSL code is also large, and it's at: https://github.com/sjhalayka/julia4d3/blob/a933ca3d2a7129db93140d858c9ecf24f55f43af/Release/mc.cs.glsl#L1​

When I read the output data, it tells me the right number of triangles, but the rest of the output data is like, overwritten with zeros. Am I making some kind of silly mistake? :(

I ran into an issue on Intel – it only supports 8 texture units at one time. AMD… 64 of them!

In any case, the solution to this problem is likely better suited for geometry shaders.

@taby In the other thread, i quoted you AMD. Merge as many textures as you can into one single texture. And access the different textures by an offset/index.

The more things are binded separately, the slower it runs.

That's an interesting approach. Thank you for that!

Try putting these tables not in LDS, but in an Uniform Buffer Object.

Then compare the performance. Because UBO must be slightly slower to access than LDS. And you read it from a loop. Worth a try. Worth a try a lot!

Right now it seems, you declare your tables once per thread. You can not add a “shared” to the tables, because if you do, you would be not able to initialize them at compile time.

So just put these tables inside an Uniform Buffer Object.

Other thing you can do is to declare the tables as shared empty arrays and fill them from the code. But it is more civilized to use a UBO.