Using renderdoc with normal opengl i count 660 draw calls on a hopefully representative frame. Multiple meshes per drawcall are hard due to the architecture of renderware. I have considered sharing vertex and index buffers though. Do you think that will make a big difference?

I suspect that sharing vertex/index buffers won't really help (alone).

Last time I profiled something graphically intensive on the pi 4, I found that touching any of the draw state or uniforms between draw calls would trigger an expensive re-validation on the whole pipeline. 50% of my cpu time was spent in the driver.

Of course, the app I was profiling was pushing quite a lot of uniforms per draw call. Your workload might be different, so profile before doing anything drastic.

I recommend building a version of mesa with symbols so you can see exactly where CPU time is spent.

BTW, try prepending `mesa_glthread=true` to your command to see if that gives you a free speed boost.

hm, state changes between draw calls are hard to get rid of...after all that's why they're separate calls in the first place. profiling the driver is probably indeed something i should look into.

You should be able to batch CPU-side drawcalls by packing multiple meshes into bigger vertex buffer, then generating draw parameters for every object into SSBO/UBO, and then utilizing ARB_multi_draw_indirect to draw everything at once. To change textures inside these batched drawcalls you might need ARB_bindless_texture. This talk is helpful: https://www.gdcvault.com/play/1020791/Approaching-Zero-Drive...

I don't know if these extensions are available on Pi driver, though.

I am a developer but you guys are speaking a foreign language from my perspective in this thread. Where can I learn about graphical programming for the Pi, or are you guys well versed in game programming in general and applying it here? Sounds like an interesting skill set and challenge

https://antongerdelan.net/opengl/ is a decent resource for learning opengl (the author was a TA in my graphics course in college :D). And I do think it's worth Lear ing opengl over vulkan today. Vulkan dials the api complexity up to 11. If you're happy with windows only, then directx 11 would be a good choice too, but I don't have a good reference off hand.

The problem with graphics programming is that really you need to learn two things simultaneously: how 3d graphics are rendered, and how to use a GPU api. They can both be a significant thing to learn alone, and the complexity of cramming the two into your brain together makes things hard.

Seconded, I too would like resources to learn more about this topic. Spend most of my time with business logic.

Try out an introductory OpenGL tutorial. There are many out ther. Just drawing a square will be a good lesson