View Single Post
Old 02-Jan-2013, 17:46   #24
Andrew Lauritzen
AndyTX
 
Join Date: May 2004
Location: British Columbia, Canada
Posts: 2,275
Default

Quote:
Originally Posted by MJP View Post
I think that reviewers should just post a GPUView capture for each benchmark,and then we'll really know what's going on.
Haha, agreed! And ideally vtune traces with driver symbols too

Quote:
Originally Posted by silent_guy View Post
Are there technical reasons why review sites can't post raw fraps numbers for all the benchmarks they run?
Not really, no. As Scott mentions, you basically just check off an option in FRAPS that dumps the raw data to a file, and FRAPS works in basically everything.

Quote:
Originally Posted by caveman-jim View Post
What 99% doesn't show is uneven frame render times inside that target time.
Definitely true, and there are potentially some other metrics that would capture this better, such as some sort of running variance/deviation metric. I think there are definitely other interesting ways to analyze the data than what Scott has done for instance, but I just want to get over the first hurdle to start

Quote:
Originally Posted by caveman-jim View Post
I wonder how power limiting technology will affect gaming performance, right now GPU's clock down under full load to stay in TDP (yeah I know, the message is they turbo when load is light, same difference). Frame rate limiting and vsync leave TDP on the table, I wonder if the next step is power aware geometry/AA/compute ... this may be off topic for this discussion though.
It's definitely going to get really interesting, no doubt...

Quote:
Originally Posted by OpenGL guy View Post
I don't know what is going on with Borderlands 2, I work on OpenCL. However, I think you are being a bit too judgmental here.
As I've mentioned in previous responses, I wasn't referencing the AMD issue there specifically, just using examples of why FPS is a bad metric.

Quote:
Originally Posted by OpenGL guy View Post
Second, some features are emulated now (think fog). So if an API feature were enabled that required recompilation of shaders, then you might experience a "hitch".
Right, i.e. "state-based recompiles", but these get nastier than just fixed-function features. Still like changing certain rasterizer/blend state, bound texture types (2D/3D/Cube/etc) and so on can also cause recompiles and the state that is "dynamic" vs. "compiled" is implementation dependent and completely opaque. ... and it definitely does happen in the middle of gameplay. This sort of stuff has to stop in the long run, but it implies more general hardware and people don't want to pay the price.

But yeah, to reiterate, I'm not claiming that's what's happening here (it's probably more memory-related stuff, as usual), but it's yet another "hitch/stutter" that is ignored when measuring using FPS. Also, I think I'm allowed to be "judgmental" about the state of the industry here, both as a gamer and a developer at an IHV (although I don't specifically do drivers) I just want us all to concentrate on improving the gaming experience in this area a little bit... I don't think it'll be a ton of work, but it requires redefining our performance metrics.
__________________
The content of this message is my personal opinion only.

Last edited by Andrew Lauritzen; 02-Jan-2013 at 18:20.
Andrew Lauritzen is offline   Reply With Quote