this project ), even 2x MSAA ruined performance, if you use the same setting on Pi4, I think that contributed the most to the performance issue. At least for my test cases on Pi4 (see e.g. All modern GPUs support non-power-of-2 textures, Pi4 included.Ĥ. My desktop PC is fast enough to deliver 60 FPS, but on RPi you should not use textures much larger than necessary.
Only top-center 3840*2160 portion was actually used. That’s a good idea by itself, the problem with that, the temporary texture has size 4096*4096 pixels. Starting from EID 5377, the game was finishing rendering of the previous one. Up to EID 5328, the game rendered the next frame. GPUs disable some optimizations (early Z rejection is one of them) when you calling discard in GLSL/HLSL.ģ. Write another pixel shader for cases when you don’t need alpha tests. In your pixel shader you often have this code: Translucent objects need to be rendered back to front like you’re currently doing.Ģ. The sorting doesn’t need to be perfect, an approximate will do as well, but with these ~5k draw calls I’m pretty sure even C qsort gonna be adequate on Pi4. If you do that, early Z rejection gonna save tons of pixel shaders and fill rate.
Consider sorting opaque objects by Z and render then front to back.
On the main rendering pass, your code renders stuff mostly back to front. Here’s a renderdoc capture from my PC: ġ. Compiled 32-bit Windows build of VC with GL2. I don’t have GTA3 but I do have VC on Steam.
