slow input to shader

I wrote a shader which works fine but I would like to further increase the frame rate so I can apply it to more interesting and more complex cases. When I use the “Capture Opengl ES Frame” tool in Xcode, it shows that the CPU time usage is a factor of six times larger than the GPU usage, although almost nothing should be calculated outside of the shader. In fact, only a small fraction of the maximum GPU performance is use.

For my project, I do need a lot of data in the shader and I finally managed to reduce the amount of data to a size that is accepted by Opengl ES. However, the amount of data is relatively large. In addition to 10 uniforms, I have more than 70000 vertices with 13 attributes each (12 vec3 and 1 vec4).

The bottleneck seems to be the transfer of data from Codea to Opengl. Apple suggests to use VBO but Codea so far only seems to support VAO. Is this correct? Is there a way out or do I need to use some separate C code to manage the data transfer more fluently? Will Codea 2.0 help?

While you could probably do it faster in Objective C, the more important question is what are you trying to do, because even faster, it may still be the wrong approach and not be fast enough.

Basically sending the vertices or associated attributes to the GPU is expensive, especially for a large mesh (70k vertices sounds quite large).

I guess the question is what are you trying to do and why, then once we know that, maybe there’s an easier way to do it.

A couple of examples from things I’ve done:

http://www.twolivesleft.com/Codea/Talk/discussion/2465/my-grass-simulation-with-vertex-shaders/p1 Was an idea of grass simulation. Doing grass and waving it about by touch etc in lua and then sending the modified vertices to a shader would be terrible performance wise. So the vertices are fixed with a weighting, then only the touches are sent to the GPU each frame as uniforms, and all the heavy lifting is done there.

http://twolivesleft.com/Codea/Talk/discussion/2901/skeletal-animation-shader Again for the same reason, the vertices are setup and sent to the gpu once at the start in a nuetral pose. Then by sending a set of uniforms representing the rotation at the joints, significant movement can be made while keeping the quatity of data moving to the gpu low.

A new feature that is only in IOS 6 is textures in the vertex shader, these again may give a path to having a static set of vertices that don’t get recent to the gpu, but using a texture to deform them. An example could be using a texture as a heightmap for a 3d terrain.