We found that when DrawCall used in the product becomes a lot, the API call overhead of the OpenGL ES of the CPU end will be high. This part should be the overhead of Driver. But we don't know what is expensive to overhead for a DrawCall. So we can only rebound through non-stop testing. Although we have tested some conclusions. But we are not very confirmed, they are correct. So, I want to ask a professional：
1.what is the main overhead of the Driver?
2.If you can do a proportion of overhead according to the type, what is the rough proportional situation? For example: Texture, FBO, Vertex, UBO, Uniform, Shader, TBO ... If sorted, what is the order?
3.Also, these overhead mentioned above is related to the specific parameters? Such as the size, number, etc.
Bulk data size shouldn't matter - that will already be in memory when the draw happens.The first draw in each frame and/or the first draw to the window surface might be slower, as it's tied to frame sync (especially if you are hitting vsync - that might be the time where the frame wait is inserted).
But we found that the cost of more than one drawcall in a frame is relatively high, and there will be multiple drawcall api calls, which is relatively expensive. What is the reason for this?
No idea without any data. Possibly just the application thread is getting descheduled and something else is running? Have you tried a profiler, like our Streamline profiler to see if you can see what's going on?
We have checked that the overhead is only the API call of opengl es.
Or, can I understand this question like this:
In the Mali GPU driver, except for the first drawcall in a frame, other drawcall overheads are very low and can be ignored, right? There is not any blocking logic in the API call layer, right？
In the general case, no, draws shouldn't block. They can be in some corner cases (high vertex counts, high draw counts), but real content tends not to get close to these limits.
Pete