Part of the Khronos Group

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 3 of 3

Thread: How to test how many texture calls before FPS drop

  1. #1
    Junior Member Newbie
    Join Date
    May 2015

    How to test how many texture calls before FPS drop

    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!

  2. #2
    Intern Contributor
    Join Date
    Mar 2014
    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...
    Last edited by __bob__; 06-27-2016 at 04:47 AM.

  3. #3
    Junior Member Regular Contributor
    Join Date
    Sep 2013
    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.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts