Comments on: The evils of fps http://www.realtimerendering.com/blog/the-evils-of-fps/ Tracking the latest developments in interactive rendering techniques Mon, 17 Jun 2013 03:17:13 +0000 hourly 1 http://wordpress.org/?v=3.4.1 By: Naty http://www.realtimerendering.com/blog/the-evils-of-fps/comment-page-1/#comment-94 Naty Sat, 25 Jul 2009 04:01:46 +0000 http://www.realtimerendering.com/blog/?p=125#comment-94 The discussion assumes the researchers do the measurement properly. It is quite possible to correctly measure true GPU costs of individual operations at sub-millisecond precision; tools such as PIX do it all the time. The discussion assumes the researchers do the measurement properly. It is quite possible to correctly measure true GPU costs of individual operations at sub-millisecond precision; tools such as PIX do it all the time.

]]> By: baxissimo http://www.realtimerendering.com/blog/the-evils-of-fps/comment-page-1/#comment-93 baxissimo Sat, 25 Jul 2009 03:00:56 +0000 http://www.realtimerendering.com/blog/?p=125#comment-93 I don't know. When I see a msec value for a GPU technique it always makes me a bit nervous. How can I be sure they actually timed the GPU part of the operation to the end and didn't just time how long it took to submit the commands to the command stream? Whereas for FPS, assuming they're measuring the whole period from frame start to frame start, then I know there's less wiggle room for measurement error. I don’t know. When I see a msec value for a GPU technique it always makes me a bit nervous. How can I be sure they actually timed the GPU part of the operation to the end and didn’t just time how long it took to submit the commands to the command stream? Whereas for FPS, assuming they’re measuring the whole period from frame start to frame start, then I know there’s less wiggle room for measurement error.

]]> By: Mauricio http://www.realtimerendering.com/blog/the-evils-of-fps/comment-page-1/#comment-91 Mauricio Thu, 23 Jul 2009 22:48:05 +0000 http://www.realtimerendering.com/blog/?p=125#comment-91 I should add that this above comment has implications for profiling. For example, a profile may indicate that Present() is taking a long time, when the GPU is in fact spending that time processing previous work, not the back buffer presentation. I should add that this above comment has implications for profiling. For example, a profile may indicate that Present() is taking a long time, when the GPU is in fact spending that time processing previous work, not the back buffer presentation.

]]> By: Mauricio http://www.realtimerendering.com/blog/the-evils-of-fps/comment-page-1/#comment-90 Mauricio Thu, 23 Jul 2009 22:45:26 +0000 http://www.realtimerendering.com/blog/?p=125#comment-90 "Therefore, SSDO is actually 3% more costly than SSAO, rather than 2.4%." Hmmm... I think another example would have been more compelling. It's also worth mentioning *how* you determine the time spent. A naive implementation will measure a "frame" as the time between the first rendering call and presenting the back buffer (e.g. Present()), or the time it takes to make a single graphics API call (e.g. DrawIndexedPrimitive()). Since the CPU and GPU are working asynchronously, that won't work: the call may return immediately while the GPU processes it. Generally you want to measure over several frames, since the CPU is only allowed to get a few frames "ahead" of the GPU. “Therefore, SSDO is actually 3% more costly than SSAO, rather than 2.4%.”

Hmmm… I think another example would have been more compelling.

It’s also worth mentioning *how* you determine the time spent. A naive implementation will measure a “frame” as the time between the first rendering call and presenting the back buffer (e.g. Present()), or the time it takes to make a single graphics API call (e.g. DrawIndexedPrimitive()). Since the CPU and GPU are working asynchronously, that won’t work: the call may return immediately while the GPU processes it. Generally you want to measure over several frames, since the CPU is only allowed to get a few frames “ahead” of the GPU.

]]>