PCPer on Crossfire problems in the Titan review

[Final8ty]

This whole tearing fixation is a red herring and you folks should know better.

*every* game with every card exhibits tearing at a mostly random place on a frame unless vsync is turned on.

Why exactly are you trying to steer the conversation away from what they're using that tearing to measure to the tearing itself?

Because its not a red herring when the tearing is far more disturbing.

One would not focus complaint on the salad dressing when one has an allergic condition to the nuts in the salad.

Demonstrate the Micro stuttering without the tearing thank you, i cant stand tearing period.

I didn't watch the whole video because of the tearing and what i did watch i didn't watch closely to see the stutter that they were on about because of the in my face tearing.

Tearing= Not smooth experience to me.
Tearing is clearly not an issue for everyone and some people don't mind it and have come accustomed to it.

Micro stuttering=Not smooth experience to me.
Micro stuttering is clearly not an issue for everyone and some people don't mind it and have come accustomed to it.

 

[SolMiester]

This whole tearing fixation is a red herring and you folks should know better.

*every* game with every card exhibits tearing at a mostly random place on a frame unless vsync is turned on.

Why exactly are you trying to steer the conversation away from what they're using that tearing to measure to the tearing itself?

I can see this is quiet upsetting for you, but that doesn't retract from the fact that many people experience this issue with CF on some games..

 

[BrightCandle]

Keep in mind that frame metering slows down the quicker displayed frames to match up to the slower ones. It doesn't actually solve the face issue of uneven frame distribution.

I think it might fix the production of stuttering frames from the CPU. The way software usually works is that when you call into an api like directx some of the calls are synchronous, that is you wait until the result is ready and returned. Which if it talks to the GPU means you have to wait for it all to complete. Much of DX is now asynchronous which improves performance but some of it is still going to be synchronous. If the presentation of a frame is blocked awaiting frame metering then it will delay the CPU causing it to separate its frames to a more even point.

Not knowing DX specifically I can't be sure that is what happens but it seems likely that somewhere in the call stack nvidia is slowing a thread down which continuously redrifts the separation of frames. So its probably not delaying a frame 16ms on every go its actually only adjusting it a little bit every time. Thus the increased latency and decrease in performance is minor. We know it must be quite minor as the scaling difference between the 7970 and the 680 is quite small most of the time.

 

[omeds]

The only benefit of running faster than 60fps on a 60hz monitor is the increased responsiveness of the controls. The monitor is not displaying more than that so there is absolutely no point in testing for a smooth experience beyond 60hz.

Not true at all. Try a 125 or 250 fps cap on a 60hz display, it's far smoother and far less tearing.

 

[VulgarDisplay]

Not true at all. Try a 125 or 250 fps cap on a 60hz display, it's far smoother and far less tearing.

I already said it's more responsive. That I believe may be the smoothness you are referring too. Yes, it can display more than 60 frames, which gives you several partial frames displayed at different intervals top to bottom for every cycle of the monitor resulting in tears.

It can display 60 whole frames per second.

 

[omeds]

No, responsiveness is not the smoothness I'm referring to. I would have said responsiveness if thats what I was referring to.

Solid 125 and 250fps caps are far smoother than 60fps on a 60hz display without vsync, plus tearing is vastly reduced compared to no cap.

 

[Dribble]

Not sure why so much discussion of tearing, etc - thought article was basically about AMD cheating in Xfire fps scores by inserting useless runt frames?

 

[omeds]

I don't think they're cheating, they just haven't optimised frame distribution by the looks of it. They are rendering as many frames as Fraps indicates, but many of those frames are useless in the end result - what the user sees, because they're runt frames.

 

[Jaydip]

No, responsiveness is not the smoothness I'm referring to. I would have said responsiveness if thats what I was referring to.

Solid 125 and 250fps caps are far smoother than 60fps on a 60hz display without vsync, plus tearing is vastly reduced compared to no cap.

Omeds tell me why not cap the fps at 59 fps then?in very few games you can get 125-250 fps anyway.

 

[boxleitnerb]

Do we actually know for a fact how frame metering exactly works?

 

[BrightCandle]

http://techreport.com/review/21516/inside-the-second-a-new-look-at-game-benchmarking/11

The basic technology, known as frame metering, dynamically tracks the average interval between frames. Those frames that show up "early" are delayed slightly—in other words, the GPU doesn't flip to a new buffer immediately—in order to ensure a more even pace of frames presented for display. The lengths of those delays are adapted depending on the frame rate at any particular time. Petersen told us this frame-metering capability has been present in Nvidia's GPUs since at least the G80 generation, if not earlier. (He offered to find out exactly when it was added, but we haven't heard back yet.)

So we don't know a lot, just that it exists and seems to have a positive impact on pcper's tests.

 

[boxleitnerb]

I imagine that if you have an uneven distribution of frames and delay constantly, even by a small amount, that the cumulative delay would be quite bad. How would this work if the GPUs are working at full load?

 

[Dribble]

I don't think they're cheating, they just haven't optimised frame distribution by the looks of it. They are rendering as many frames as Fraps indicates, but many of those frames are useless in the end result - what the user sees, because they're runt frames.

Pretty optimistic interpretation. Xfire isn't new, they must know about these frames and the effect they have on the all important fps charts which despite all the advances in reviewing are still probably what sells the most graphics cards. I take a more realistic line - they knew, they left them there and didn't tell reviewers about them.

This in my book is pretty bad - they effectively lied about how well their graphics cards perform in Xfire as they knew what reviewers reported wasn't correct. You could even ask - did AMD put them there intentionally? I'm sure this will all come out over time - e.g. testing old drivers to see when the phantom frames first appeared. I await the official AMD response to see what they've got to say.

 

[BallaTheFeared]

I imagine that if you have an uneven distribution of frames and delay constantly, even by a small amount, that the cumulative delay would be quite bad. How would this work if the GPUs are working at full load?

Reduced scaling, instead of 108% like AMD gets now and then you get 60-80%..

You know it's funny I've seen that a few times, AMD gets something weird like 114% scaling and the reviewer just keeps going like thats right, nothing to see here folks, totally normal.

 

[omeds]

Omeds tell me why not cap the fps at 59 fps then?in very few games you can get 125-250 fps anyway.

59 or 62 are fine to use if you can't maintain 125 or 250. Personally prefer 62 without vsync, but prefer 59 with vsync depending on the game.

Pretty optimistic interpretation. Xfire isn't new, they must know about these frames and the effect they have on the all important fps charts which despite all the advances in reviewing are still probably what sells the most graphics cards. I take a more realistic line - they knew, they left them there and didn't tell reviewers about them.

This in my book is pretty bad - they effectively lied about how well their graphics cards perform in Xfire as they knew what reviewers reported wasn't correct. You could even ask - did AMD put them there intentionally? I'm sure this will all come out over time - e.g. testing old drivers to see when the phantom frames first appeared. I await the official AMD response to see what they've got to say.

I was under the assumption the runt frames, despite only being a slither, are still a fully rendered frame by the GPU, but the timings are so bad it's hidden by the other two frames on the display.

If those runt frames are not a fully rendered frame on the GPu side, there sure it certainly is giving them a false performance advantage.

 

[boxleitnerb]

What I actually meant was that if you delay and delay (in periods where the GPU has no breathing room and is working on full load all the time), where does it stop? After a while, the discrepancy in timing between how it would be without the delays and what it is with the delays, would be massive. How do you recover from that? Because at some point you would need to "catch up". At least that is my understanding, maybe I'm wrong.

 

[BrightCandle]

Pretty optimistic interpretation. Xfire isn't new, they must know about these frames and the effect they have on the all important fps charts which despite all the advances in reviewing are still probably what sells the most graphics cards. I take a more realistic line - they knew, they left them there and didn't tell reviewers about them.

This in my book is pretty bad - they effectively lied about how well their graphics cards perform in Xfire as they knew what reviewers reported wasn't correct. You could even ask - did AMD put them there intentionally? I'm sure this will all come out over time - e.g. testing old drivers to see when the phantom frames first appeared. I await the official AMD response to see what they've got to say.

I don't know. We have seen a lot of progress in understanding the problems with AMDs cards over the last 2.5 months from reviewers. AMD has claimed ignorance on the techreport expose. I think their QA might genuinely be that bad. I never assume malice where incompetence will do and in this case and all the other bugs and problems with their support and all the other management issues the company has I think its most likely they just aren't doing things very well at all.

What I would like to see is similar techniques applied to a 5970 or a pair of 6970's so we can see what the previous design did and if its something new or has always been like this. I suspect its always been like this (I had issues with the 5970 as well) and that since the G80 NVidia has had the problem mitigated. Considering AMD's strategy of mid range high end with dual cores to compete with NVidia's highest end card its kind of shocking to see this mess unfold. If anything if you intend to compete using crossfire make it work better than your single card and not a whole heap worse.

Personally I would hope that AMD has every bit as sophisticated performance testing as pcper, I fear they don't however. I do think its time they addressed the pcper and techreport reviews, after all severe performance problems have been found nearly 3 months ago in their solution and we still have a beta driver that does little to solve them. Now we have a whole new scandal, a lot more detail about why crossfire feels wrong, it certainly looks like cheating and again no statement by AMD. This sort of problem wrecks their reputation. I have gone from accepting that AMDs drivers at least improved even if they weren't great to thinking they are hopeless in a pretty short period. I didn't like the cards but others preferred them, must be something rig specific or some subtle difference.

This

is not a subtle difference. Its showing something very broken indeed.

 

[VulgarDisplay]

Actually omeds is right. AMD isn't cheating to get higher fps in xfire because that sliver of a frame was rendered from the top of the screen to the bottom of the sliver, and then it was covered up from top to bottom by the next frame.

They still do all that rendering but their frames uneven distribution makes things look awful. Hopefully they do something about this quickly.

If these sites really wanted to impress me they would now start looking into solutions to the problem if there are any.

 

[Ferzerp]

Actually omeds is right. AMD isn't cheating to get higher fps in xfire because that sliver of a frame was rendered from the top of the screen to the bottom of the sliver, and then it was covered up from top to bottom by the next frame.

They still do all that rendering but their frames uneven distribution makes things look awful. Hopefully they do something about this quickly.

Only a single frame at a time should be written to back buffer. There is no way to produce a frame with more than one line on it unless something incorrect is occuring (Regardless of *Why* the incorrect thing is occuring).

 

[Imouto]

Only a single frame at a time should be written to back buffer.

It's happening in both camps with this kind of testing, hence wrong methodology if you're aiming to measure the user experience. You can't break a great deal of the IQ to measure something else.

There is no way to produce a frame with more than one line on it unless something incorrect is occuring (Regardless of *Why* the incorrect thing is occuring).

So I guess there's nothing wrong with the first line if there's a second.

 

[Imouto]

is not a subtle difference. Its showing something very broken indeed.

They're testing it in a damn 60 Hz display with a 60 Hz capture tool. Dismissing the fact that every single card in that graph will tear the screen having a faster graphics solution will make your screen tear even more regardless of how it is metered.

I just don't know how your logic is working anymore.

 

[boxleitnerb]

I don't understand the problem here. Who is to say this problem doesn't also appear with Vsync on? While gaming, my fps often are below the refresh rate, so microstutter still occurs with Vsync active.

This method may not be directly relevant for people playing with Vsync, but that doesn't mean that you cannot deduct useful information from it. And I know of many people who would never play with Vsync due to input lag. They are important, too.

 

[BrightCandle]

They're testing it in a damn 60 Hz display with a 60 Hz capture tool. Dismissing the fact that every single card in that graph will tear the screen having a faster graphics solution will make your screen tear even more regardless of how it is metered.

I just don't know how your logic is working anymore.

They could test it at 120Hz and it wouldn't make a blind bit of difference to that data. This is not a problem with tearing, its uneven frame delivery made worse by the fact that some frames produced are so useless that you need to remove them. I don't understand what it is you are trying to say at all.

Can you explain further why it is you think 60hz is an issue, because I think we have established that it really isn't.

 

[omeds]

Only a single frame at a time should be written to back buffer. There is no way to produce a frame with more than one line on it unless something incorrect is occuring (Regardless of *Why* the incorrect thing is occuring).

I dont understand, there are 3 frames shown in the screenshot with 2 lines of tearing. The 3 frames are overlapping each other in sequence, right?

 

[Imouto]

There are more answers than Vsync. As for people playing without Vsync because they don't care the slightest about screen tearing don't know why they would care about stuttering either and more when that stuttering is under 16.6ms, the minimum that you aim to see in a 60Hz display. If that stutter last any further than 16.6ms you're going to have a 33.3ms stutter and even more than that to 50ms but looks like reviewers don't even know how their monitors work.

And no, they can't test it on a 120Hz monitor because their capture hardware is capped to 60Hz. Wanna test it again when they get new hardware? OK, but don't show this as it is right now as the holy grail of "user experience testing".

Again the new problem with this method is that having a faster graphics solution is indeed worse than a slower one tear wise. There are only problems with this new testing methods and we are in hands of utterly incompetent people.

Can you explain further why it is you think 60hz is an issue, because I think we have established that it really isn't.

Where? Anyway 60Hz displays ain't the issue here, TR and PCPer methodology is.