[Qt5-feedback] vertex buffer object usage in scene graph

[gunnar.sletta at nokia.com]

On May 26, 2011, at 7:57 PM, ext Albertine Blum wrote:

> Hi
> 
> I poked a little bit in the scene graph code and stumbled over:
> 
> glVertexAttribPointer(0, a->tupleSize, a->type, GL_FALSE, geometry->stride(), geometry->vertexData());
> ctx->functions()->glVertexAttribPointer(QT_VERTEX_COORDS_ATTR, 2, GL_FLOAT, GL_FALSE, 0, m_vertexCoordinateArray);
> ctx->functions()->glVertexAttribPointer(QT_TEXTURE_COORDS_ATTR, 2, GL_FLOAT, GL_FALSE, 0, m_textureCoordinateArray);
> 
> You use no vertex buffer objects(VBOs), but client side vertex arrays which are mostly slower and deprecated in OpenGL 3.0. (http://www.opengl.org/wiki/Vertex_Buffer_Object) Is there a plan to change it?

Hi Albertine,

The reason for using client side vertex arrays over vertex buffer objects is because most of our buffers are small (4 vertex rects and images) and they change rather frequently. Using a VBO per object is a lot slower than using a client side array. We also played around with merging all our geometry into a single VBO to reduce the cost of buffer switching, but the average performance was always higher with vertex arrays for the QML usecases. 

That being said. We want to enable certain geometries, those with a lot of vertices, like a large paragraph of text or a non-trivial mesh to be cached as GPU-side vertex buffers, but we don't have this in place yet. So we want to make use of VBO's where we expect to get a benefit from them :)

> You also use triangle strips and no indexed vertex triangles, which could utilize the post vertex shader cache, as the default.

Again, the usecase of rects and images, low vertex count, there is little benefit in using index buffers. In fact its more data to send to the GPU, so it is actually an added cost. 

For geometries with slightly higher vertex count, like the text nodes, we use indices. There it also reduces the memory consumption of the geometry.

> 
> Also you use glDrawElements and not glDrawRangeElements which can be faster because of the start and end values, so the driver can utilize some optimizations(this happens also for rendering the whole array). 

OpenGL ES 2.0 only has glDrawElements. 

The scene graph backend API, non-public, allows for plugging in hardware specific renderers. Through this API, one could experiment with if using glDrawRangeElements will make a difference in terms of performance for desktop GL and then ship a different renderer for desktop GL that used this specific function, but my gut feeling is that this won't make a big enough impact enough to be worth it.

> 
> I have no knowledge about embedded opengl chips, but it would be nice to know why you use "older" and "slower" opengl functions. Is this because the driver are so bad?

We try to target the intersection of OpenGL 2+ for desktop and OpenGL ES 2.0, so that the code runs equally on both.

> Best regards, 
> 
> Albertine
> <ATT00001..txt>