Should reviews that don't use FCAT be ignored?

Page 5 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.

wand3r3r

Diamond Member
May 16, 2008
3,180
0
0
I fully understand the software and what it does. I didn't go over every line of code, I had no reason to. Everyone who matters has seen the code, one guy on the net says he found the line that targets AMD hardware? Please, on this forum I'd sooner believe I was adopted than anything people claimed without a slightest bit of proof.

Besides I didn't slam any doors on him we merely debated the aspect of the code he was questioning in relation to the results and what is and isn't actually a FRAPS readout, but given your lack of engagement in much of anything but name calling it doesn't surprise me you weren't able to keep up, nor does it surprise me you took the side of someone you thought was "defending" AMD.



It tags a frame, gives it a color, and another program decides if the frame is large enough to be considered a real frame to the end user. You can see the frames in question, they're little slivers in the screen shots.

There is no deep mystery on how it works, or what it does, or how it does it... All the code is open for viewing by anyone, ignorant fear mongering isn't the defense AMD deserves.



It's all just black magic and bogeymen to you, isn't it? lol sad. It's all about crossfire at this point, but the thread is more an extension of "Are reviews that don't use frame time graphs worth reading" from months prior, try to keep up at least if you're going to comment in a thread instead of blindly taking AMD's side on everything.



When you're dealing with simple to follow, understand, and viewable code... There is something wrong with it. It's not some closed program that churned out results from nVidia HQ, what you're basically saying is nVidia provided a tool for everyone to examine right down to it's source code and pulled a fast one on everyone in the industry, get a grip on yourself.

They must really be getting at AMD with their lies, AMD is even going through the trouble of fixing a make-believe issue, much like they did with your make believe frame time single gpu issue.

Relax you don't need to be upset, I'm pointing out what I found ironic. You're taking it too seriously... I don't know if either side is true, but it's ironic given the sponsorship of the tool. That's why it has to be taken with a grain of salt, and there is good reason to be skeptical (which is natural given the motivation). No need to get all personal, it's not black magic bla bla bla to me.
 

BrightCandle

Diamond Member
Mar 15, 2007
4,762
0
76
Discredit the tool technically if you can, but so far there has been no successful attack on the approach and how it works. What you are trying to do is make a strawman argument and then use it to prove their is controversy or that the tools results are in some way biased. That is unequivocally false, the results are not biased as they are generic to all brands of GPU (Intel included). The origin of the tool is irrelevant to the quality of the results, there is no controversy around the tool at all.
 

wand3r3r

Diamond Member
May 16, 2008
3,180
0
0
I'm only open to the possibility that it could be inaccurate (it could be perfectly accurate, idk), not saying it is or isn't. Someone else can waste their time if they have the interest. It's also obvious NV was involved so it should be determined if they can skew it or if it does work properly with AMD cards. Read these words. I'm not arguing it's inaccurate but it certainly is worthy of verifying.

I'm not proving anything about the tool, merely mentioning possible conflicts of interest.
 

BallaTheFeared

Diamond Member
Nov 15, 2010
8,115
0
71
There is nothing bias in the code, the irony is the time of the release coupled with nVidia's advances in mGPU smoothing.

Fermi isn't as good as Kepler in this respect, however with all the single card stutter taking place for AMD, and nVidia quietly sitting in the corner of a dark room knowing what they've got what better time to release it?

There is nothing mysterious about it, nVidia had the upperhand and the time was ripe for a new tool to expose mGPU issues that we've all known about over the years. It just so happens that nVidia had been working to alleviate them over a several year period on both the hardware and software level.

I don't presume to know nVidia's motives (my guess would be sales), but that aside the tool itself is unbiased and overdue.
 

wand3r3r

Diamond Member
May 16, 2008
3,180
0
0
Yeah that is logical. Either way the attention is bringing improvements so it's a win for consumers.
 

BallaTheFeared

Diamond Member
Nov 15, 2010
8,115
0
71
Definity, I rarely ever used vsync before but with my CF setup I tried it in Alan Wake because my single couldn't cope and it was fine for me.

Because of this exposure AMD should release a driver in the coming months to improve my experience. I'm already all in this gen with AMD, no reason for me to needlessly bag on them. All I want is the best possible experience I can get, with or without band aids and tools like this expose both the good and the bad.
 
Last edited:

Black Octagon

Golden Member
Dec 10, 2012
1,410
2
81
I gotta say, this thread has actually been a very interesting read so far.

This is despite the fact that I still struggle to get my head around the finer points of this frame metering business.

(And despite the fact that the discussion nearly degraded into insults a couple of times there...hopefully that's behind us).

sushiwarrior, if you truly believe that something is wrong with the code then I can only encourage you to communicate this to the review sites, and not (only) post about it on forums. I don't understand enough about this to have an opinion myself, however I must say that (unless I mis-read one of your posts) you don't seem to have conclusively shown that review sites are indeed using FCAT for their FRAPS reports. I can see how it would be problematic for them to do so, but I'm not convinced that they are, in fact, doing this. Do you know it for a fact?
 

SirPauly

Diamond Member
Apr 28, 2009
5,187
1
0
There is nothing mysterious about it, nVidia had the upperhand and the time was ripe for a new tool to expose mGPU issues that we've all known about over the years.

That's probably correct! I was curious about any smooth improvements with Kepler and noticed this with the GTX 690:

The GTX 690 uses hardware based frame metering for smooth, consistent frame rates across both GPUs

Desired to learn more -- was it just GTX 690? Improvements with Kepler? So, I decided to join the PC perspective chat with the Live Review of the GTX 690 and asked a hardware frame metering question:

And basically received this from nVidia, " Good to see you here SirPauly but this is not the right time to discuss frame metering but something we may address in the future!"

I was wondering why they wouldn't discuss a strength they had, but may of been working on the tool to prove the strengths of frame metering and SLi.
 

sushiwarrior

Senior member
Mar 17, 2010
738
0
71
Perfect, here is the issue. The last issue they discuss, the 2 scanlines. That's what I'm talking about. Is it a runt? Yes. Is it a minor issue? Sure. Does that look like a 16 FPS penalty to anyone? I really, really don't think so. FCAT treats that 2 scanline bar as a 16FPS penalty. It doesn't know how to handle it, even though Nvidia tried to put code in to fix it.

So there you go, Mr. BallaTheTalksOutOfHisAss, there's your proof. Those 2 scanline chunks correspond to 16FPS spikes in the "claimed" FCAT output, even though FRAPS would never have claimed there was 16 FPS there, hence proving that what FCAT claims FRAPS would say and what FRAPS actually does say are different.
 

BallaTheFeared

Diamond Member
Nov 15, 2010
8,115
0
71
Where are you getting 16 fps from?

skyrim-fps-filtered.gif


So what do we make of the problems of runt and dropped frames? They're troublesome for performance testing, because they get counted by benchmarking tools, helping to raise FPS averages and all the rest, but they have no tangible visual benefit to the end user.

:confused:
 
Last edited:

BallaTheFeared

Diamond Member
Nov 15, 2010
8,115
0
71
I think he's claiming that FCAT is creating RUNTS that programs like FRAPS would not pick up. This would therefore inflate the actual reported FPS numbers that CF would get with FCAT compared to a program like FRAPS thus resulting in AMD looking worse by having MORE fps to start with, but THE SAME after the removal of RUNT frames.

Or that they're actually there, but that programs like FRAPS wouldn't pick them up, I can't be sure!

Honestly I'm having a hard time grasping the point, perhaps I'm just that stupid /:(\
 
Last edited:

bystander36

Diamond Member
Apr 1, 2013
5,154
132
106
Perfect, here is the issue. The last issue they discuss, the 2 scanlines. That's what I'm talking about. Is it a runt? Yes. Is it a minor issue? Sure. Does that look like a 16 FPS penalty to anyone? I really, really don't think so. FCAT treats that 2 scanline bar as a 16FPS penalty. It doesn't know how to handle it, even though Nvidia tried to put code in to fix it.

So there you go, Mr. BallaTheTalksOutOfHisAss, there's your proof. Those 2 scanline chunks correspond to 16FPS spikes in the "claimed" FCAT output, even though FRAPS would never have claimed there was 16 FPS there, hence proving that what FCAT claims FRAPS would say and what FRAPS actually does say are different.

If there are 16 of them a second, it would be a 16 FPS less, as they are pretty worthless. That said, it doesn't even show 16 FPS less in the example you gave.
 

sushiwarrior

Senior member
Mar 17, 2010
738
0
71
Where are you getting 16 fps from?


:confused:

If you had an actual run.sps file, like you don't, because you've never used FCAT on real data in your life, you would notice the "dropped frames" column is always in multiples of 15 (15, 30, sometimes 45) and also includes a runt frame. This is why each of those bars is interpreted by FCAT as saying "FRAPS would have reported 16 frames rendered but there are none rendered".

I wasn't saying that review has the problem, as each review can interpret the FCAT data differently and use it as they please, but they outlined the issue in the "2 scanlines" screenshot.
 

BallaTheFeared

Diamond Member
Nov 15, 2010
8,115
0
71
And yet still FRAPS reports higher FPS than FCAT even prior to the removal of the RUNT/dropped frames, so again what is your point?
 

sushiwarrior

Senior member
Mar 17, 2010
738
0
71
I think he's claiming that FCAT is creating RUNTS that programs like FRAPS would not pick up. This would therefore inflate the actual reported FPS numbers that CF would get with FCAT compared to a program like FRAPS thus resulting in AMD looking worse by having MORE fps to start with, but THE SAME after the removal of RUNT frames.

Or that they're actually there, but that programs like FRAPS wouldn't pick them up, I can't be sure!

Honestly I'm having a hard time grasping the point, perhaps I'm just that stupid /:(\

Yes, exactly. The way FCAT handles those 2 scanlines is saying "these colours are out of order! this is colour #1 and I was expecting colour #3! Therefore the card dropped colours 3-16, that's 15 dropped frames. Plus this is a runt".

If there are 16 of them a second, it would be a 16 FPS less, as they are pretty worthless. That said, it doesn't even show 16 FPS less in the example you gave.

It's not 16 a second, the issue is FCAT interprets that 2 scanline chunk as INSTANTLY missing 16 frames (15 dropped and 1 runt).
 

sushiwarrior

Senior member
Mar 17, 2010
738
0
71
And yet still FRAPS reports higher FPS than FCAT, so again what is your point?

I don't know which of those values are what, it's not clear what they mean by FRAPS and what they mean by FCAT. Also I'm talking about other reviews like HWC where they used the standard FCAT output.
 

sushiwarrior

Senior member
Mar 17, 2010
738
0
71
I'm talking about your link, they used FRAPS and FCAT separately.

Yes, that link also goes to show what FRAPS actually sees and what FCAT claims FRAPS sees is different... but that's besides the point, I'm talking about this specific 15 dropped frame issue which you can easily see in the HWC graph.
 

Will Robinson

Golden Member
Dec 19, 2009
1,408
0
0
I fully understand the software and what it does. I didn't go over every line of code, I had no reason to. Everyone who matters has seen the code, one guy on the net says he found the line that targets AMD hardware? Please, on this forum I'd sooner believe I was adopted than anything people claimed without a slightest bit of proof.

Besides I didn't slam any doors on him we merely debated the aspect of the code he was questioning in relation to the results and what is and isn't actually a FRAPS readout, but given your lack of engagement in much of anything but name calling it doesn't surprise me you weren't able to keep up, nor does it surprise me you took the side of someone you thought was "defending" AMD.



It tags a frame, gives it a color, and another program decides if the frame is large enough to be considered a real frame to the end user. You can see the frames in question, they're little slivers in the screen shots.

There is no deep mystery on how it works, or what it does, or how it does it... All the code is open for viewing by anyone, ignorant fear mongering isn't the defense AMD deserves.



It's all just black magic and bogeymen to you, isn't it? lol sad. It's all about crossfire at this point, but the thread is more an extension of "Are reviews that don't use frame time graphs worth reading" from months prior, try to keep up at least if you're going to comment in a thread instead of blindly taking AMD's side on everything.



When you're dealing with simple to follow, understand, and viewable code... There is something wrong with it. It's not some closed program that churned out results from nVidia HQ, what you're basically saying is nVidia provided a tool for everyone to examine right down to it's source code and pulled a fast one on everyone in the industry, get a grip on yourself.

They must really be getting at AMD with their lies, AMD is even going through the trouble of fixing a make-believe issue, much like they did with your make believe frame time single gpu issue.

There's probably some hidden code stuff goin on.
<[if AMD/gpu] act all spikey n shit,>
:colbert: