View Full Version : How to test how many texture calls before FPS drop

06-24-2016, 11:27 PM
Hi, I am trying to get a realtime glow shader going for a mobile app. So far it has been going well, separable convolution is working brilliantly! However it still isn't manageable on some devices, and I know some never devices could really show off their muscle and render glow quite pristinely.

As such I was hoping to find a way that I could figure out (using shaders and CPU code) what the most amount of texture calls that can be made by the gpu before the frame rate drops below 60fps, and before it drops below 30fps. This way I can come up formulaically with a good amount of samples per pixel, and downsample for glow map.

I know that the GPU does a LOT of optimization which is why I am skeptical to say run a fragment shader on one pixel (idk how even to do that) and have it sample textures x amount of times as passed in by a uniform. I worry that the GPU would catch on that each sample was changing things little, or that it was sampling the same point on the texture each time.

How would you suggest programmatically finding out how many texture samples can be done before the fps drops by a certain level? How can you be sure this trial won't be thwarted by gpu optimizations?

Thanks much!

06-27-2016, 02:25 AM
Care one thing : compiler uses hudges optimizations!
All your texture reads must impact the result of your shader otherwise, the compiler will squeeze all unused reads...
And dont forget the cache effect : use a / few big textures to avoid cache effect!
To my mind, the best way is to read n textures for each fragment...

06-27-2016, 03:16 AM
I would advise you to make it dynamic. Build it in a way that your application will automatically increase / decrease the number on the fly based on FPS. This would be the most solid and accurate solution. Just make sure not to change too quickly. Give it some leeway to adjust or else you end up flipping back and forth hastily.