Testing results beta 1.00.14305 complete

[TUSA/TX-Gunslinger]

I've done a lot of controlled "The Black Death" track replays, and since it's Monday in Russia - I thought I'd post my findings.

Here are graphs of 6 successive track playbacks attempting to isolate the cause of random stuttering and pausing on some track playbacks but not others. The following two examples iterate ProcessingAffinityMask and show the performance of CPU/GPU syncronized with other measurements and Fraps results.

All my settings and system configuration is listed on these first two examples which display 22 minutes of data overall - each TBD track is 3 mins 40 secs in duration:

Note: My HD5870 GPU is operating at maximum clock during loading from CoD track playback






Note the playbacks in which the fps was 0 or lower than 10. Those are track playbacks with significant pausing and stuttering.

Now here's a couple sets of measurements over two different tracks - at higher time resolution so you can see the relationship between GPU and CPU loading during a stutter/pause and a track with good performance - i.e. no stutter or pausing

First the smooth track playback, note that GPU loading (purple) never drops lower than 50% during the track.



Now a playback which had significant pause (like 2 seconds). Note that during the stutter the CPU (yellow) drops to 0 first - then the GPU (purple) drops to 0.



No matter what Catalyst setting or CoD setting I changed - the stuttering and pausing continued randomly throughout testing. Many times, I thought one setting or the other had improved it - but follow on testing produced more stutter tracks.

In summary - It's the CPU not the GPU that producing the stutter and pausing.

As has been reported many times - the AA only works in two modes - OFF and 1X-2X-4X-8X all producing the same graphic output. Strangley, I found performance better at higher settings even though the screen output was the same.



S!

Gunny

[kyletiernan]

Nice work, saved the devs some work. Hopefully they read this and make some changes.

[Phazon]

Nice work. I thought the big pauses were from the CPU being overloaded but it looks like otherway around - the game drops the ball and stops feeding it.

[TUSA/TX-Gunslinger]

Thanks for the kind words. It took me days to figure this out, due to the randomness of runs. At one point I thought it was Tessellation, at another I thought it was ATITraytools interacting with the program, at one point I thought it was ProcessAffinity settings. All false leads

When I finally by the weekend, when I starting looking at the CPU/GPU interactions during stutters - I finally got it. It took all those plots and graphs to prove it however.

Yes Phazon, that's exactly how it seems to me - the CPU gets starved for info and stops - then the GPU follows. In many runs you'll see the CPU start to come down in load - but it picks back up before the GPU is effected.

I wanted to put this out here to stop folks from running out and buying video cards right now. By all means, wait until it all stabilizes then see what you need.

Last thing: As you can see in the first series of graphs, my HD5870 is running at max clocks just fine. One of the interesting things that's occuring apparantely is the HD6000 series cards are not "clocking up". So HD5000's are operating one way - while HD6000's are operating in another.

S!

Gunny

[Sauf]

Great work Gunslinger, only downside is I think Russia is on 5 days off for May day holiday.

[Orpheus]

Originally Posted by TUSA/TX-Gunslinger

Last thing: As you can see in the first series of graphs, my HD5870 is running at max clocks just fine. One of the interesting things that's occuring apparantely is the HD6000 series cards are not "clocking up". So HD5000's are operating one way - while HD6000's are operating in another.

Good work on this testing dude. Just so you know the ATI underclocking issue has been solved:

http://forum.1cpublishing.eu/showpos...&postcount=289

It's the Ubi splash video that plays when the EU edition starts up (RU version doesn't have the Ubi splash so it's an EU problem only, afaik). With GPU-Z open at startup, you'll see normal clock speeds until that video plays - the vid causes the GPU clock to lock to the UVD video setting (usually 400mhz) and ATI powerplay won't detect the change, leaving us stuck at video clock speeds.

Delete or rename the splash.wmv as described in the linked post and any cards suffering this issue should clock normally.

[Buchon]

I found that the game still trashing the HDD, even having free RAM to use, and that event cause shuttering.

If the game is not limited in the use of RAM and detects the available resources, and this objects are previously loaded in RAM, the HDD trashing shutters will disappears.

Maybe is the search of this resources in the HDD what is causing this CPU hold back, or just is another source of shuttering different.

[SUP_Trok]

Very good work!!

[TUSA/TX-Gunslinger]

Originally Posted by Buchon

I found that the game still trashing the HDD, even having free RAM to use, and that event cause shuttering.

If the game is not limited in the use of RAM and detects the available resources, and this objects are previously loaded in RAM, the HDD trashing shutters will disappears.

Maybe is the search of this resources in the HDD what is causing this CPU hold back, or just is another source of shuttering different.

Well, I looked hard for that. By doing sequential track playback runs - where the track is already in RAM after the first playback - you figure your getting around the disk access issue.

It actually looks to me (if I had to be forced to guess) like a broken thread. i.e - one of the many processes that runs threaded, just had an error and stops. Then the process has to go and find something to "do".

In short after several hundred runs this week, I saw no evidence of storage access issues.

S!

Gunny

[Buchon]

Originally Posted by TUSA/TX-Gunslinger

Well, I looked hard for that. By doing sequential track playback runs - where the track is already in RAM after the first playback - you figure your getting around the disk access issue.

It actually looks to me (if I had to be forced to guess) like a broken thread. i.e - one of the many processes that runs threaded, just had an error and stops. Then the process has to go and find something to "do".

In short after several hundred runs this week, I saw no evidence of storage access issues.

S!

Gunny

So there two sources of shuttering.

Im talking about the first load in RAM, for example flying in "free fly mode" when you are approaching to a city the game shutters searching in the HDD some thing, a house or something, when it is already in RAM there no shutter flying the same zone.

But there free RAM, why is not this loaded already ?

About the strange issue that there better performance with AA in x8 than in x4.

That is a ATI issue, they have better performance in x8 than x4, even if it is not working properly, dont know why