Performance issues on Android when enabling config.useGL30 about libgdx HOT 7 OPEN

Yup, I think this is completely unnecessary as sprite batch indices never change from construction. Will be a nice little performance boost. Will do some further testing, and if its good in all scenarios will make the change

from libgdx.

We had some similar issue here a while back.
#3916

Its probably worth dialling it in to make sure it can be isolated to just VertexArray vs VBOwithVAO directly with a Mesh. SpriteBatch here shouldn't be important. tests/gdx-tests/src/com/badlogic/gdx/tests/VBOWithVAOPerformanceTest.java has a test for regressions, we can probably make one duplicate for comparing VBOWithVAO against the vertex array.

That said, I wonder if VertexArray may before better in rendering very tiny mesh in your test scenario.

What kind of throughput were you doing with your 3D work? Were you uploading lots of vertices per frame?

from libgdx.

Hi, thank you for your fast response. The VAO thing sounds related since that's what differentiates the SpriteBatch implementation when using gles3 instead of gles2.

I did some more thorough testing by basically replacing the SpriteBatch with a model batch and came to the conclusion that meshes are actually not affected by this. The reason I thought otherwise in my project before is likely related to the UI having such a huge impact. The meshes in my project are static.

For the SpriteBatch I tried different VertexDataTypes:

• VertexArray: Only works with GLES2
• VertexBufferObjectWithVAO: This is the default for GLES3 atm. Shows the described performance issues.
• VertexBufferObject: Noticable better performance, not on par with GLES2 though
• VertexBufferObjectSubData: same as VertexBufferObjectWithVAO

from libgdx.

I made an interesting observation. Commenting out the following three lines in SpriteBatch.flush() fixes the performance issues completely regardless of which VertexDataType is used:

                Buffer indicesBuffer = (Buffer)mesh.getIndicesBuffer(true);
                indicesBuffer.position(0);
                indicesBuffer.limit(count);

https://github.com/libgdx/libgdx/blob/7bed7d3666d3b343aebeb1c3f733eae63380dd10/gdx/src/com/badlogic/gdx/graphics/g2d/SpriteBatch.java#L959C1-L961C30

No idea how this is connected to VAO, though. Either way, I wonder why the index buffer is touched at all in flush() since it does not actually change so we don't have to re-upload it, right?

from libgdx.

Yes that is strange. That is marking it as dirty and the buffer data is going to be uploaded every frame when the mesh is bound.

Can you try changing to just mesh.getIndeicesBuffer(false) and keeping the rest of the code?

from libgdx.

Indeed, not marking the buffer as changed also fixes the issue.

from libgdx.

Seems to be no regressions in behaviour. I want to make some more sophisticated tests to check the behaviours under different types of load. On desktop I can't really see anything noticeable yet, but probably have to hit it with a very high draw call app. Even then I don't think my GPUs have little bandwidth to encounter this as a bottleneck. Many draw calls with a full batch should be the best stress test I think, since it will be uploading a full index buffer every flush. Will try that on android asap.

Overall I makes sense to just upload at the start though, it just means that the memory usage is going to be increased to the max size of your batch from the get go, instead of previous behaviour of - it depends how well you are utilizing the batch.

from libgdx.