optimizing fps performance

[krom]

Hi all
When building applications Im wondering what exactly has a hit on performance.
Trying to figure out where I should focus on optimizing.

I notice my geometry, animated geometry, textures and gui takes most of the impact on fps,
but what about the other stuff I have in the loop like alot of getPosition, setPosition, UpdatePosition, getDistanceFrom and animators?
Is this easy work for the cpu and basically has no noticable impact on fps?
What about renderToTexture, is this equal to rendering the scene twice? or does it re-use from earlier rendering processes in the loop?

I know going from 2000 to 1000fps isnt really a big performance hit in drawtime, but im thinking to keep my application over 400-500fps on
my computer to make it perform ok on slower computers.

Krom

[REDDemon]

most time is taken by file loading and drawing ("render" method). Even drawing only a cube takes a lot of time and so drawings many cubes drop down framerate (1000 cubes on my PC for about 60 fps). Of course even if irrlicht has much overhead, all other stuff has reduced impact on performance. (unless for mobiles in wich all those virtual calls make a certain difference).

I know going from 2000 to 1000fps isnt really a big performance hit in drawtime, but im thinking to keep my application over 400-500fps on
my computer to make it perform ok on slower computers.

That's not the way to go. First an application usually don't scale. So if you have a 500 fps on a 4Ghz CPU you will not get 250 fps on a 2Ghz cpu (there are many factors like cache size, tasks done by the Operative system in the same CPU of the game, different prefetech and pipelining capability ). Of course the same apply to GPU, to memory speed etc. you can still have improved performance due to that reason but maybe there's another reason that reduce performance etc. For GPUs that can e particulary true. GPUs have slower clock frequence, but are able to parallelize much work. For that reason drawing a cube on a old videocard can take the same exact time on a new videocard with same frequence. The difference is that the new videocard can maybe render a whole scene in the same time of drawing a cube for the old card. drawing a cube is usually a bad way to use GPU resources.

There is also a tecnology factor. simply certain features are not available on older machines.

The way to go is to test the application on older machines and make it running at 60 FPS. then you can add additional stuff for newest machines. Of course if you don't have a state of the art PC you can assume your machine as "old" so that when the game is ready it will run nicely on most machines. If you really want to support old machines you have to test your game on a number of old machines.

Yes if you get 500 fps, and you are not using special features it's probable the game will run at 60 on a old machine (how much old?)
but that's not a guarantee..

@render to texture: depends on how you are using RTT. You can still render to a texture and then show that texture on the screen, (in this case you have to render the whole scene only once. there's always the extra drawing time for presenting the texture to the screen).

You can also want to create a "mirror" effect. In that case you need to render the scene twice + cost for rendering the water. that's expensive and that's why most games reflects only terrain and not other items like vegetation.

[hendu]

@OP

No need to guess. Install your favorite profilers for both CPU and GPU.

@REDDemon

Crysis 2 does screen-space reflections

[REDDemon]

what about screen space raytracing then? that's not very easy for beginners i think and has also of artifacts unless you blur in someway the result.

[hendu]

Yes, they ray-march in the pixel shader, and yes, they blur when there's not enough data (for example when the reflection would be outside the screen). It doesn't look half bad, though.

[mongoose7]

Not really "screen space."

[hendu]

How come? It only uses the screen data and runs in a screen-space quad pixel shader.

[mongoose7]

"... they ray-march in the pixel shader." If its a quad pixel shader then I should withdraw my comment. But I don't see how you can do a raytrace in a quad pixel shader, or maybe that is not what is meant.

[hendu]

Ray march is the usual term, you read the pixels following a ray/vector. Perhaps a picture explains better:


Current pixel in red, target in green, pixels read in black.

In this case they read the depth, and if it's greater than the start pixel's depth, you reflect that pixel's color.

[mongoose7]

How do you choose the rays?

Though I can't really see it working. If I imagine a small lake, then all objects behind the lake would be reflected? Even if it is only the shore. You really only want to "reflect" an object if it is much closer to the top of the screen than the "lake." It seems to cry out for a bit of maths, not simply greater-or-less.

[hendu]

You get the reflection vector by reflecting the camera/view vector on the shiny surface (of course flattening to 2d at some point). I don't understand what you mean with behind the lake. Maybe post a pic

My explanation wasn't clear though, the comparison is not to this pixel's depth, but the interpolated depth at that point in the ray of course.

[ACE247]

This topic got 'off-topic' fast!
@krom if your rendering with directx add Nvidia PerfHud to irrlicht, you can enable it in irrcompileconfig.h(but download perfhud first!), should give you enough profiling data.

[krom]

thanks for useful comments!
Yea, post took off into screenspace:)
So far I noticed RTT did drop my framerate, changed it to 512 from 1024 and things got alot better,
actual resolution on screen is about 750px if im running in 1920width resolution, so 512 bit to low... but then again, it looks quite ok so im keeping it like that.
its basically a rifle scope setup where im looking trough both scope and FPScam at the same time.

Im using opengl and installed gDEBugger, not sure how to interpret the values it gives me yet.

[dotProduct]

I notice my geometry, animated geometry, textures and gui takes most of the impact on fps,
but what about the other stuff I have in the loop like alot of getPosition, setPosition, UpdatePosition, getDistanceFrom and animators?

Of all those functions, the getDistanceFrom() would most certainly take the longest as it requires a square root calculation which takes a relatively long time. I presume this is why getDistanceFromSQ exists. If you're doing a lot of these operations per frame, it may be wise to use the squared distance instead (if possible) and/or find a way to do fewer such operations.

It would be interesting to see how which method of find a square root is implemented by irrlicht, as there are many.


http://assemblyrequired.crashworks.org/ ... uare-root/

[krom]

Noticed that even addEmptySceneNode push the fps down.. how come if they are not even visible?

a simple test
Initial 475 fps
1000 addEmptySceneNode, fps = 345
1000 addCubeSceneNode, fps = 147