Frame rate limited?

[Rodrix]

Hi everyone!

I am surprised... I compared frames per second for both a billboard tree consisting of just two squares in X, and a 180 poly palm tree, both with alpha test. Results are 30 fps and 60 fps respectively.
How can that be?!

Billboard) 4 triangle polygons, 512x512 texture with alpha channel, texture vertex maps all the texture fully, texture contains almost 40% transparent area (alpha test on). ==> runs at ~30 fps, 0.033 seconds per frame (VSync off)

Palm) 180 triangle polygons, 512x512 texture with alpha channel, texture vertex maps very little transparent area (alpha test on). ==> Runs at ~60fps, 0.016 seconds per frame (VSync off)

So actually processing more polygons is cheaper than doing more alpha testing from a texture? Polygon operations are cheaper than alpha test and alpha blend?
What is the explanation?
Or am I frame-fill limited?

Thanks so much!
Rodrix

P.S: What is the max number of 512x512 texture you guys recommend loading into OpenGl in order to avoid frame-fill rate limited?

[zeoverlord]

Yes, kinda.
It depends on many factors, like how many billboard/palms you have and where they are placed.
If you have lot's of billboard up close then you will be more fillrate limited than vertex limited, relative to if you have palm objects.
However billboards are unbeatable at a distance.

Remember when it comes to fillrate limited graphics, polygons are free, so use them.

And BTW, texture size have nothing to do with the fillrate limitation, the limit comes with the total memory size of your card, however you need a couple of hundred textures to do that, so it's unlikely that will happen for a few billboards.

[Rodrix]

Wow...!
you are right.

Remember when it comes to fillrate limited graphics, polygons are free, so use them.

Could you please explain me better what you meant in this line? I think I am really not understanding the concept of being fillrate limited, you say it doesn't have to do with the size of the textures I load? I thought that if loaded many 2048x2048 textures into many objects then that would cause the program to become fill rate limited... I was even considering to reduce the texture size of my skybox to reduce fill rate limited. (Is this wrong?)

I tried this now:
Billboard Test 1) 5 billboard trees in view for distance x ==> 60 fps. VSYNC On.
Billboard Test 2) 6 billboard trees in view from distance x (same x as test 1) ==> 30 fps!!. VSYNC On.
(I did it with VSync on to be consistent with the previous test. I realized I Vsync wasn't truely off...
). Without Vsync an important drop occurs also, but from like 90 fps to 60 fps or so.

This incredible drop in FPS from 5 to 6 billboard trees, (just one tree more), means that I am frame-rate limited?

Polygon Palm Test) Draw N palms (polygon palms) one on top of each other (superposed). Now with VSync Off.
N=3 ==> 66 FPS 15ms
N=4 ==> 60 FPS 17ms
N=5 ==> 56 FPS 18ms
N=6 ==> 54 FPS 19ms
N=7 ==> 50 FPS 21ms
N=10 ==> 42 FPS 25ms
N=13 ==> 38 FPS 26ms
N=15 ==> 34 FPS 30ms

This seems pretty linear. So it means I am not vertex rate limited even with 15 palms, right?
Vertex rate limited would mean a huge sudden drop of FPS right?


Thanks so much in advance,
Rod

[ZbuffeR]

>> Vertex rate limited would mean a huge sudden drop of FPS right?
not quite.

Fillrate limited :
- when the time needed to draw all pixels (event the trasnparent ones) exceeds the time needed to transform the vertices, so the vertex process is waiting for the rasterization.
It is easy to check for fillrate limitation if you keep the exact same rendering but reduce the window width and heigth. You will see a important change of FPS. When the rendering window is small enough so that FPS don't increase anymore, then you are vertex limited.

Checking directly for vertex limit is a bit harder, basically you render the same scene, just with more detailed objects. In your example, simply drawining more trees increase both vertex and fill process.
Any way, really disable vsync, and you should measure milliseconds instead of FPS. Fps are not linear, then don't add up.

[Rodrix]

Wow! You are so right!!!
Thanks for the tip!

I reduced my window size, perfomance changed from 38ms (28 FPS) to 17ms (60 FPS)!!!! So indeed! I am fill rate limited.

You guys say that texture size doesn't have to do anything with being fill rate limited, because what matters is how much texture is rasterized on screen rather if the file to produce the texture?
So that means that a texturized object that fills the whole screen with a 2048x2048, means the same amount of work to the GPU likea tiled up 64x64?

In other words, is there anywhere I can read about how to reduce frame rate limited?

Thanks so much guys!!!
Cheers,
Rod

[Komat]

Originally posted by Rodrix:
So that means that a texturized object that fills the whole screen with a 2048x2048, means the same amount of work to the GPU likea tiled up 64x64?

For the bigger texture the GPU needs to fetch more data from its memory so the work is higher. Unless you are doing something cache unfriendly like using texture coordinates that vary greatly in each pixel or minifiyig texture without mipmaps, the additional memory accesses for bigger texture should be not a big issue.

[ZbuffeR]

how to reduce fill rate needs ?

Draw less surface, less complex shaders, less textures, avoid blending. Trim your billboard geometry so that it is close to the textured tree.

BTW I think you may gain some rate by using alpha-testing, to discard transparent parts of the texture. Keep the threshold low. The hardware can optimize the skipped fragments (even if the texture still has to be read for alpha value).

[Rodrix]

Trim your billboard geometry so that it is close to the textured tree.

Great tip! , I guess that this was the main issue with my billboard trees, too much pixel work for dropping alpha values.

Thanks so much everyone!

ZbuffeR, could you clarify this line for me:

Keep the threshold low. The hardware can optimize the skipped fragments (even if the texture still has to be read for alpha value).

Thanks in advance!

[ZbuffeR]

"Keep the threshold low" : with both alpha testing and blending, if your alpha-test threshold is 0.5, you can see aliasing when the billboards becomes transparent. With something like > 0.0 it should be ok.

You won't see a visible difference, and it may be faster (probably not so much a gain than trimming the billboards but you can try both at the same time) :
glEnable(GL_ALPHA_TEST);
glAlphaFunc(GL_GREATER,0.0f);

[Rodrix]

Oh great!
You gave me a really good idea:
I got a huge mountainbox with a 1024x1024 texture that is almost 80 % transparent. I will trim the mountain box.

Last question: I got a plane 0.00001 points above my ground plane that contains a fog texture with alpha blend. Will it be more economic (in performance) if I use multitexture on the ground plane instead of using two planes and one with alpha blend?

Thanks soo soo much!
Rod