Still, an uneven interval should still provide better responsiveness nonetheless, if the frame rate is going to almost 2x. This is where it gets tricky: looking at just the frame times doesn't show you the real problem that's going on with contemporary multi GPU solutions, the big problem is that the responsiveness is in fact worse!
Before we dwell any further into this issue, we need to look at multi GPU rendering modes and have a more detailed look at how the issue presents itself to the user.
Before we dwell any further into this issue, we need to look at multi GPU rendering modes and have a more detailed look at how the issue presents itself to the user.
Test System
AMD Athlon 64 X2 5200+
6GiB DDR2-800
320GB Samsung HD321KJ
Jetway M25GT-SG, nForce 550 based, with dual PCI-e x8
Dual Nvidia GeForce 9400 GT 1GiB in SLI Mode
Tested in Windows Vista x64, Server 2008 x64
Testing Notes
Despite running the tests with Nvidia's WHQL certified 260.99 drivers, I found the results different in both OSs - Server 2008 was generally better performing than Vista in all benchmarks, though not by much.
Vista and Server 2008 results are not directly comparable as the graphical settings weren't the same but only set to guarantee that micro stuttering was clearly distinguishable. I had the HDD die before I could reproduce the results again. I stand by them, since not even running nHancer I could change rendering modes and the driver seemed to be sticking to always rendering
So, What's Up?
See this YouTube video below and tell me if you can spot the problem:
The game is Serious Sam HD. Do you see that there's a ghost image that's always trailing the other one? This is not right. Why the hell is an image showing up this kind of ghosting? Which one is the real frame? Which should you trust when you're trying to shoot something? This also happens in more subtle ways, which is where I noticed it while running an SLI of 9400GTs while in an effort to evaluate if SLI had real benefits - due to the game incompatibilities that I heard so much about. This only happens with SLI and it is easy to spot with a frame rate close to 30fps with a single card, on a CRT @ 85Hz. A single 9400 GT showed no problems.
The other game here is Portal, pay attention to the gravity gun as I move it around:
I can show you what I mean in a better way by using a frame from the movie:
You can clearly see the VSync split(and another one above) and in the middle there's a full image with the said ghosting, which is where I first noticed the problem. Serious Sam HD shows it worse, while in some games it is nearly impossible to spot. Keep in mind though, just because we can't spot it, it doesn't mean the game picture feels more fluid, as the frame rate counter almost doubling seems to imply. The reason because one can't notice the game with more fluidity and why this ghosting appears is the same, but to understand what is going on, you should better understand how multi GPU currently works.
(Both these videos were taken at around 30 FPS, or approximately 15 FPS rendered per GPU.)
(Both these videos were taken at around 30 FPS, or approximately 15 FPS rendered per GPU.)
How?
GPUs have not usually been made to work in pairs, triplets, or quadruples, as it is possible nowadays. The first design of such sort was the 3dfx Voodoo², which featured the SLI rendering mode, which at the time meant "Scanline Interleaving". It was a much different rendering approach than today's AFR and SFR modes and I've never had the chance to see one work. Nowadays SLI stands for Scalable Link Interface, which is what Nvidia calls the link they have embedded the some hardware with, which communicates through the SLI bridge or, alternatively, through the PCI-Express bus on slower GPUs or when in tandem with the integrated GPU.
Both AMD and Nvidia currently use the same rendering mode, AFR, which stands for alternate frame rendering:
Regardless if you call it SLI or CrossFire, AFR is happening in the background, each card is rendering a different frame at the same time. AFR is used in a more widespread fashion, since it's the mode that provides higher benchmark results.
SFR was a solution that Nvidia adopted and that split the whole scene between two GPUs, putting them together before sending it to the display. A short note: SFR performance wasn't as good as AFR, due to synchronization delays. Hence, it seems, AFR eventually won out and became the preferred rendering mode.
Then you have the dual GPU cards, which rendered in a mix of modes:
As far as I know, AMD/ATI used AFR from as far as the old ATI Rage Fury MAXX and Nvidia was the one to try and push SFR, which, if I recall correcly, was the only mode present at the debut of the technology in the GeForce 6 series cards. In the meantime AMD has worked on other rendering methods, which we will discuss below, though AFR is preferred and Windows 7 (or DirectX 11, can't recall) went as far as allowing hardware manufacturers to increase the number of buffered AFR frames, thus increasing performance of multi-GPU solutions.
AMD CrossFire
AMD CrossFire
![]() |
Scissors rendering mode (courtesy AMD) |
![]() |
Super Tiling rendering mode (courtesy AMD) |
Explaining Micro Stuttering
Micro stuttering can be quantified by benchmarking with FRAPS, or any other program that allows you to capture the frame rate and the frame arrival time. PCGH did this, and so did I a few months ago. What I found was that two different OS versions, with three different drivers, all exhibited the same problem. The game is Portal 2 and each pair of frames was arriving at close to the same interval. Let me show you a snippet of that log :
![]() |
Frame arrival times |
In both Windows Server 2008 benchmarks, despite the visual anomalies show in the video still being present, the frames arrive at intervals reasonably paced, so much that on the plot it is possible to see that the Windows Vista x64 version is the only one that plots as micro stuttering below. Single GPU and SLI setups on Server 2008 exhibit very close to even interval times, with the occasional small deviation that can be attributed to other factors like OS background activity:
![]() |
Micro stuttering plotted, please view in full size. |
The AFR Problem
Alternate frame rendering works by, in essence, trying to "predict" the future. When one card is rendering one frame and the other one is rendering the next one, how can it know what the next frame will show? It can't without introducing more lag to the input data, since games are not pre-rendered and what the graphics card needs to work is game state related. The current frame being rendered is of the last information available but since the next frame in line is being rendered with the game data only available at the time the information is sent to the "slave" GPU, it is doing nothing more than rendering the same frame twice. The problem then, is that when it is actually displayed, it is displayed at a time when the game supposedly already has updated information, e.g. you have quickly turned the aim to side contrary to the movement when the 2nd frame was sent to render. In principle then, AFR fails.
Graphics vendors, in this case Nvidia, seem to be trying to send the frames at uneven intervals, by sending the second frame as soon as it's rendered, so that displaying the same frame twice results in you not noticing artifacts, something that works ok for that objective. Unfortunately, it seems they are somehow allowing frames to arrive out of order, which results in the visual artifacts of the Serious Sam HD video, where a frame with the crosshair with center at pixel "x" is shown after a frame with the crosshair "x+1" pixels - assuming movement to the right (on a regular x/y axis). This results in the being able to see "two" crosshairs instead of what would be a motion blur effect from one point to another:
You can check the video thoroughly to reassure yourself that this is not an artifact from the video but that, in fact, the crosshair is moving in an inordinate fashion.
My best guess for what is going on on this particular case is that since the 9400 GT has to send the SLI data through the slower, non dedicated, PCI-e 1.1 x8 bus on this motherboard, the driver is allowing the aforementioned out of order rendering, or rendering more than one frame ahead, in which case really old information would be showing up after an updated game state frame from the main GPU. Either of these two will cause the above problem. In my case then, I just don't have micro stutter, I have slower performance and graphic artifacts than one GPU! The only way to fix this is to go back to SFR.
Do you notice this issue with AMD and Nvidia hardware with SLI bridges? Please report back your findings, though with AFR in place I will expect you to have it. More thorough investigation is warranted.
How To Spot Trouble
With proper synchronization and ordering of frames, it is possible to have multi GPU solutions that trick the user through numbers, much like it has been up until now. If even 4 frames at the same time can be displayed at even intervals, a high frame rate can be registered with no visual artifacts (in theory, no graphics or even DX/OpenGL expert here).
It is then of the utmost importance to check if framerate is increasing and if the game feels more fluid or not, since otherwise your graphics card is just slower than one with a single GPU which are usually clocked higher (GTX 590 vs 580). You can do this by setting an immensely high resolution, AA, AF and overall graphics settings. If you can bring your solution to the point it is rendering 30FPS per GPU, you will notice artifacts if present or that it simply isn't more fluid with SLI/CrossFire, despite what benchmarks tell you.
I cannot stress enough that this issue may be completely unnoticeable in setups that put out 200+ FPS, so be careful with that during testing.
Conclusion
Multi GPU solutions, for the benefit of the consumer and not just benchmarks and "performance crowns", need to quickly ditch AFR modes once and for all. The fact that some manufacturers are dedicating engineering resources to Hybrid SLI and CrossFire solutions is troublesome since they cannot provide an adequate performance and probably will have to rely on AFR and shortcuts that exacerbate the rendering issues herein presented. More investigative work needs to be done on this issue with new eyes and better hardware (especially better SLI and CrossFire solutions that aren't available to me), so that this issue that has been roaming the web for years now can be put to rest. If SFR solutions are not beneficial, engineering resources are far better used in improving single GPU solutions that don't get the same performance degradation that multi-GPU solutions have, despite the higher cost of a multi GPU solution. In this case, Nvidia's big chips strategy seems to take the lead.
Multi-GPU solutions cannot be providing lower performance, stuttering and graphic rendering inaccuracies.
What To Do Now?
"Lobby" the manufacturers to allow selection of rendering modes for all games (this might not be possible due to technical problems). A public outcry on the enthusiast community may provide the attention necessary to get this fixed. Nvidia already had removed PhysX support on low end hardware due to it not providing benefits over common CPUs - that would be something nice for SLI. If you only get +50% over a single GPU, people will still pay for it, especially if it feels faster.
Other than for general purpose compute, multi-GPU solutions currently aren't looking like a very good choice for high performance enthusiasts, so it makes no sense to market them as one. Further improving high end chips into even higher grade models might be the only possible venue for someone looking into the top of the performance scale.
I would love to read about your experiences, so if you have the hardware and time please post them on the comments or in the forums and I would love to republish them. It is very important to get this tested with Windows 7 and more modern hardware before asserting this as a general problem, though I am sure that when AFR rears it's head, it will be present.
2 comments:
nice article, but waht about nvidia surround and eyefinity stuff? how is there the rendering on multiple GPUs?
Thank you.
Didn't try it but from user reports they say that the problems still persist. It makes sense that way because if you use AFR instead of one GPU per screen you theoretically get more frames per second as the work is more evenly split. If each GPU per screen was used it would solve the problem AFAIK but performance would be dependent on which screen has the viewpoint with the highest load and FPS would vary per screen. Don't know if that is also possible to do in current DirectX or OpenGL APIs, probably not.
Post a Comment