Author Topic: SLI PSA  (Read 3316 times)

Spectere

  • \m/ (-_-) \m/
  • Administrator
  • Hero Member
  • *****
  • Posts: 5716
  • printf("%s\n", "Hi!");
    • View Profile
    • spectere.net
SLI PSA
« on: March 17, 2017, 08:33:47 PM »
Just thought I'd share an issue that I ran into recently, just in case anyone out there has, or is planning, to put together an SLI build.

(tl;dr summary at the bottom of the post)

So I was playing Sniper Elite 4 when I noticed that I was getting some weird microstutter in certain situations. It only seemed to happen on maps with a lot of physics objects (namely, corpses). It was generally okay until I started playing survival, when the game literally became unplayable at around wave 5-6. Despite everything, I was still pushing over 60fps.

The day after that disastrous run I fired up Afterburner to see what was going on. Since the issue occurred regardless of the resolution and detail settings that I used, my original theory is that my 5-year-old i7-3770 was getting taxed, but that was quickly shot down when I realized that the game wasn't even utilizing 50% of each thread.

However, as I realized how many frames were being pushed I realized that there is a serious omission to SE4's display options: a framerate cap. There is vsync, but that typically introduces noticeable input lag for me, so I avoid using it. Sure enough, I went into the training range and my cards were pushing as many frames as they can, with 100% utilization on both boards. What's worse is that it uses AFR, or alternate frame rendering. That means that GPU #0 renders one frame, GPU #1 renders the second, GPU #0 renders the third, and so on. Now, the training range ran smoothly, but with the framerate being uncapped, and both boards effectively taking turns at rendering frames caused me to come up with a theory.

I don't work for Rebellion, so I don't know what kind of tech the game uses (and I'm too lazy to try to figure it out), but if it's like most it probably uses compute shaders for physics. The startup options screen has a checkbox for "Async Compute," which is a DirectX 12 feature specifically designed to allow all GPUs to process compute shaders simultaneously. What I think happened is that when the bodies started to pile up, the cards started spending more time calculating physics. Modern GPUs have a few thousand small, highly efficient computational cores that handle both graphical and computational workloads (NVIDIA calls them CUDA cores, AMD calls them Stream Processors, and Intel calls them Execution Units). Each shader, be it graphical or computational, are essentially a program that runs on these cores.

So basically, the cards are both running full tilt, both of them processing graphics (as fast as they can churn it out) and physics. So far so good.

Well, not really. I believe that two issues happened that caused the severe microstutter: 1) the load between both cards can never be perfectly balanced, even if you're only rendering graphics and 2) the cards were being taxed so hard that they couldn't properly sync. So basically, you'd have frame 2 arriving 8.33ms after frame 1, then frame 3 arriving 25ms after frame 2. It averages out to 60hz (and since that's all my display can manage, that's the number that really matters), yes, but it causes an extremely janky-looking output.

The solution was ultimately to use RivaTuner to cap the game's framerate at 60fps. That entirely removed the stutter, and now the game's framerate is more stable at 1440p than it was at even 720p before. Woot. I tried 4K, but that pushed the GPU utilization a bit too high for comfort (though a single 1080 Ti could probably handle it--that thing is stupidly powerful).

tl;dr: If you're running SLI (or Crossfire), cap your framerate or you could end up with horrific microstutter.
"This is a machine for making cows."

Bobbias

  • #1 Poster
  • Hero Member
  • *****
  • Posts: 7210
  • 404 Avatar not found.
    • View Profile
    • Magnetic Architect
Re: SLI PSA
« Reply #1 on: March 20, 2017, 01:56:24 AM »
Nice work, i've heard lots about microstutter with sli, but most of what I've seen hasn't been able to figure out why it happens or how to mitigate it well.
This is going in my sig. :)

BANNED FOR BAD PUNS X_x

Spectere

  • \m/ (-_-) \m/
  • Administrator
  • Hero Member
  • *****
  • Posts: 5716
  • printf("%s\n", "Hi!");
    • View Profile
    • spectere.net
Re: SLI PSA
« Reply #2 on: March 20, 2017, 09:50:21 AM »
Yep, same, though I've heard that it's been more or less mitigated, especially on NVIDIA's end. That was a major concern for me before I bought my cards, so I was sure to do plenty of research on it. :P That's one of the reasons it threw me off when it happened--I've had my setup for a couple of years now and have never actually experienced microstutter.

I'm fairly certain that the microstutter problem (at least when it crops up nowadays) is caused due to a load imbalance between the cards. One card is always going to work at least slightly harder than the other(s) if nothing else because it has to manage display output, maintain sync between all of the other cards, etc. On top of that, with GPUs supporting clock boosting nowadays, it's very unlikely that you'll have two cards that can actually push and maintain the same clock rate for a set length of time, so you either have to downclock your cards or reduce the load. Compute being what it is (i.e. taking away rendering resources) just throws another giant spanner in the works, since the number of, say, physics calculations that are done can be wildly inconsistent between frames.

With cards getting as ludicrous as they have been getting, my next GPU purchase will be a single-card solution. I mean, the 1080 is roughly on par with my 980s, and the 1080 Ti easily blows both of them away. If I weren't working on putting together a Ryzen-powered rig, I'd probably get a 1080 Ti just to make my setup a bit simpler (though selling my current cards would probably pay for a new GPU. Hmm...).
"This is a machine for making cows."