I'm adding functionality to my engine profiling code and two things I'd really like to add are:
1) be as precise as possible when it comes to evaluating current bandwidth usage. Doing a triangle count is easy; however, getting precise information on the amount of data that is actually sent to the GPU every frame is a whole lot trickier (furthermore, things get much more complicated when trying to estimate actual on-board vertex emission rate when GPU-side geometry emission is used). As far as I know there's no way to query the driver for this information, so I'm wondering if there are other ways apart from encapsulating every single GPU call and recording all data that goes through them/reaches the rasterisation pipeline due to them.
2) is there a way to programmatically know when the application becomes fillrate-limited? A) I'd like to toggle some options and dynamically reduce particle counts etc if/when this happens. Most games provide quality options you have to toggle manually or auto-tuning, which does separate measurements and then suggest the most appropriate settings, so I'm guessing there's no direct way to measure fillrate (other than to perhaps just make a guess based on current framerate). B) I'd like to add some profiling tools to my engine (these don't need to be real-time), which measure fillrate either indirectly or calculate it by some heuristic. How could I do this?
Determining bandwidth and identifying potential fillrate issues
If you want to do profiling sessions then try out some of the already existing tools. I can definitely recommend ATI's GPU PerfStudio 2, it provides timers and counters for everything you can imagine (or rather it hooks the ones that the driver/hardware provide, as do other programs, e.g. gDEbugger). I assume from the fact that gDEbugger uses these timers that there is an API provided that you can use to hook them yourself in game, if you want to use them for automatic LOD. Something gives me the feeling that this might not work out well though (code too hardware specific, timers not designed with this in mind, so their performance might not be the driver developers top priority).
Author
Ok, that's useful for fixed case scenarios, but what I'd like the most is identifying when the player is stepping head first into a particle system that's been added dynamically (fully dynamic pipeline, dynamically created particle systems). Even a few hundred particles that appear perfectly okay from a small distance away will choke my GT240M when I move right up to the emitter source, causing a framerate drop from 500 to 20. I'd like to identify this kind of scenario at runtime and respond to it in some way (reducing particle size, drawing fewer particles, enabling per vertex depth sampling and early outs to reduce overdraw, etc). At this point I think the only useful heuristic is to compare particle system proximity and framerate, which, while a valid solution, is crude and doesn't really provide me with a good heuristic when it comes to actually reducing settings on the fly.
Other than that the only solution I can think of is to keep the camera away from all particle systems.
Other than that the only solution I can think of is to keep the camera away from all particle systems.
MY intuition is that using precise metrics in this way will introduce a lot of complexity into your loding system. e.g. if you find out that the particle system draw call is causing a lot of fill you still won't know whether it is causing *too much* fill unless you also know what all your other systems are doing. And if you go more general and just take a fill rate for your whole renderer then you won't know which systems to scale back to get it
under control.
The fill-rate of your particle system should vary with distance in a predictable fashion (ignoring clipping) so as long as you have a base line comparison (i.e. the "auto detect settings" button) then you should have no problems with that.
But I don't know of any simple way to get the info you are looking for, all I can say is check out the docs on the driver inbuilt performance timers I mentioned, maybe I am wrong and they are appropriate to be used in a game.
under control.
The fill-rate of your particle system should vary with distance in a predictable fashion (ignoring clipping) so as long as you have a base line comparison (i.e. the "auto detect settings" button) then you should have no problems with that.
But I don't know of any simple way to get the info you are looking for, all I can say is check out the docs on the driver inbuilt performance timers I mentioned, maybe I am wrong and they are appropriate to be used in a game.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
