Skyrim
The Elder Scrolls V: Skyrim (DirectX 9)
The Empire of Tamriel is on the edge. The High King of Skyrim has been murdered.
Alliances form as claims to the throne are made. In the midst of this conflict, a far more dangerous, ancient evil is awakened. Dragons, long lost to the passages of the Elder Scrolls, have returned to Tamriel.
The future of Skyrim, even the Empire itself, hangs in the balance as they wait for the prophesized Dragonborn to come; a hero born with the power of The Voice, and the only one who can stand amongst the dragons.
Our settings for Skyrim
Here is a video of our testing run through, for your reference
Skyrim is one of the few games were we don't see major problems with runt frames and animation smoothness, but the new prototype driver is still able to make some improvements over the 13.5 beta.
As I said, this game didn't suffer from problems in the same way that Battlefield 3 and Crysis 3 did. It also sees some very modest improvements in frame times. Take a look at the 25-30 second mark and you'll see a couple of orange masses of alternating frame times; those are minimized with the prototype driver.
Our minimum FPS percentile graph shows that same modest improvement over the 13.5 beta, with an increase in the average frame rate of 10 FPS. In both cases though, the GTX Titan and GTX 690 remain ahead.
The frame variance data doesn't show much change from the 13.5 beta to the new prototype but any improvement is good to see.
I feel honored that were on
I feel honored that were on the eve of having a new and much better way of measure perofrmance.
Ryan, i dont doubt that eventually you’ll be known as the father of frame rating.
Keep up the awesome work, and ignore teh bias comments.
What about 120 hz
What about 120 hz monitors.with a 120 hz output i suppose results should be better, since shorter frames would be visualized in a single refresh cycle instead of create tearing
Have you asked them about all
Have you asked them about all the tearing?
Obviously the fluidity of the game play is significantly improved, however it seems like tearing is much worse.
BF3 was tearing the entire time it seemed.
What do you mean “tearing is
What do you mean “tearing is much worse”?
“Tearing” is essential part of game playing experience. More tears – better experience.
I mean download the BF3 vid
I mean download the BF3 vid and watch for tearing at 50% and 20% speeds. Its bad, and i would definitely argue that tearing like in this example is degrading the game experience.
Well, the thing is that you
Well, the thing is that you either have vsync on preventing the tearing or you have max framerate.
The issue with vsync is that your performance will have to be in direct relation to your displays frequency, so with a standard 60hz display your fps would either be 60, 30, 20, 15, 12, 10… and with a 120hz display you would have 120, 60, 40, 30, 24, 20, 17.14, 15, 10.91, 10 ….
With vsync on WYSIWYG, meaning that the shown and perceived framerate is identical as each time a full frame will be shown, so no “runt” will ever exist.
After saying all this i now notice that you didn’t understand properly the problem discussed with multigpu setups, look at the “monitor output by dual gpus” graphic and notice that the frame metered solution doesn’t show a full frame because of it’s nature, what it does is that the ammount of frame shown from each gpu is cut to be aproximately of the same size, and this more homogeneization of frame time is what gives fluidity to the experience.
would this be same for Hd
would this be same for Hd 7970 crossfire? if so i’m going upgrade to them xD
Kudos due where its due.
Kudos due where its due. Great review.
Unlike Hardocp who didn’t even mention the prototype driver and slammed the 7990 in its current driver state, atleast pcper mentioned the future fix, and they even went further showing results in a seperate review. Thats about as fair as you can be.
Even though this driver will be years late for non vsync xfire users (vsync + rp dfc fixed this issue long ago for me), but better late than never for those who game without that configuration and really one of nvidias biggest multi gpu advantages is about to dissapear , as results even this early are very encouraging.
i think that you didn’t
i think that you didn’t understand very well the issue…first of all indeed it’s not only a crossfire issue, the new drivers will fix everything about the frame generation, after that the frame is put into the frame buffer from the pipeline…so it will be also a single config improvement. And also the v-sync function will work better and it will benefit, as it’s always related to the frame buffer, from which vsync pulls the frames from.
What was the average load
What was the average load power consumption with the prototype driver?
I would expect it to be lower, since a metered gpu setup could be doing only 50-60% of the work of an unmetered setup, as shown in the first page of the article.
I didn’t test exactly, but it
I didn't test exactly, but it should be the same. We are rendering the same number of frames, they are just spaced differently.
You are rendering less
You are rendering less frames, because the metered GPU will try not render any frames that will be runt (in a best case scenario).
In your example image, in page 1, the unmetered GPU will render ~6 frames per draw time vs ~4 frames on the metered GPU per draw time.
Instead of having both GPUs at 100% on an unmetered setup, the metered setup works more in tandem, which should reflect less power consumption. 🙂
Since the prototype driver is
Since the prototype driver is not effecting Fraps FPS much at all, it is not effecting total frames rendered much at all, and in return, the power usage is going to hardly be effected.
Frame metering doesn’t require a lot of adjustments to work, at least in their current state, so I doubt there is much of a difference in power usage.
The prototype driver is
The prototype driver is affecting “Observed FPS”.
The difference between drivers in “Observed FPS” can be used as an estimate for the amount of discarded or runt frames. The only way to eliminate those is by having one GPU wait until the other is almost done rendering a frame, a “tandem” setup. If you are having one GPU waiting, it’s not consuming power.
You guys are looking at frame averages (fps) without looking at the frame distribution underneath. The prototype driver achieves the same fps numbers doing *less* work than the normal driver, since its *efficiency* is higher.
Looking at the frame variance charts, we can estimate the time each GPU is waiting in the prototype driver — e.g., for BF3, each will wait around 10ms. In the same chart, we can see that the normal driver keeps both GPU always at 100%, that’s why frames vary ~[0,20]ms.
So, not only does the normal driver spends time rendering frames that won’t be seen, it renders them inconsistently.
Bottom line, from the moment a driver introduces any kind of time delay into the pipeline, there *has* to be reduced power usage, since Watt equals to Joule/second.
You should be using total FPS
You should be using total FPS from Fraps, when talking about the work the GPU does. It doesn’t matter if it is a runt or not, the GPU still rendered the whole frame. It just gets overwritten by the 2nd GPU’s image. In terms of power usage, Fraps has the more accurate picture.
In terms of what we find useful, that is where Observable FPS comes into play.
Yes, you are correct! 🙂 The
Yes, you are correct! 🙂 The unmetered vs metered pic on the first page of the article is misleading and led me to believe there could be more delays introduced than there really are.
As you said, and is shown by total fps from fraps, both setups are rendering the same amount of frames (so, doing the same work), the metered setup just has a different “starting point” (see my comment below).
Still, I guess most of the
Still, I guess most of the time the power consumption between both (metered vs unmetered) will be equal, as when rendering a constant framerate both GPUs will be at 100% usage with one starting rendering when the other has its frame ~50% complete.
Only when there are more complex scenes where the framerate starts dipping (more time to render each frame) there is a need to pause one of the GPUs untill the other is at ~50% frame completion. The reverse case is also an interesting conundrum. 🙂
You guys have been doing such
You guys have been doing such an impressive work. Hands down…
Are you guys able to get
Are you guys able to get 120hz through your testing setup with reduced blanking?
From what I understand,
From what I understand, saving the data from a 60hz run, requires a RAID 0 setup with SSD’s, otherwise the storage can’t keep up. I believe THG required 5 SSD’s in RAID 0 just to be able to store the data fast enough so they can analyze it later.
I’m guessing there are technical roadblocks for 120hz to be analyzed like this. The FCAT card may also not be capable of taking in data that fast either.
Well, they managed to do it
Well, they managed to do it with a 4K display, so it should be possible on the storage side, but the FCAT card still has to be able to handle 120hz.
Interesting, thanks.
Interesting, thanks.
Is there anyway to get a hold
Is there anyway to get a hold of the prototype driver?
I don’t want to give you a
I don’t want to give you a big head or anything, but might you have helped AMD with a vital bit of debugging/testing that they never thought of? What does this do to 3x 7970s? I also want to know if they will backport the update to 6870/6970/6990s if this is possible. If you can do anything else like this to give them more data to help out AMD card users, we will be eternally grateful, though I’m not sure NVidia will be happy about it.
I’ve read another review
I’ve read another review about 7990’s performance, FCAT, prototype driver, etc, basically the same thing, although there was something i noticed.
In their benchmarks the hardware (FRAPS) FPS was also quite bigger for the prototype d. compared to the basic catalyst 7990. While for the observable FPS this difference is easy understandable, i found no explanation for the extra FPS.
Prototype driver just “arranges” the frames in a smoother way, but why it appears to produce more frames?
The review is on Tom’s
The review is on Tom’s hardware. You can notice that there are a lot of differences in frames rates (both observable and FRAPS) between the 7990’s prot. driver and normal one.
The review is on Tom’s
The review is on Tom’s hardware. You can notice that there are a lot of differences in frames rates (both observable and FRAPS) between the 7990’s prot. driver and normal one.
The review is on Tom’s
The review is on Tom’s hardware. You can notice that there are a lot of differences in frames rates (both observable and FRAPS) between the 7990’s prot. driver and normal one.
it is possible to compare a
it is possible to compare a video of a 690 vs. 7990
I installed my 7990 last
I installed my 7990 last night and went straight to BF3…Frame Rates sucked! I was expecting much more from this card. I am reading where it is a driver issue and that the driver to fix these issues should have been released already. Is it out? How do I fix this issue so I get the card to work better than the GTX 570 I used to have??