Red Dead Redemption 2 PC benchmarks- move over Crysis ; UPDATED

[Humbug]

3 hours ago, PSUGuru said:

I'm curious since this is a DX12 that this supports crossfire in some way...

Vulkan and DX12 have explicit multi-GPU support in the API. It's different from crossfire and SLI. The game developer has to specifically program for it to spread the load across multiple graphics chips.

[vanished]

I assume people here are following the investigations by gamers nexus into the performance issues?

They released another video just yesterday.  TL;DR, if you manage to get into a very specific situation where you have too few cores but they are very fast, the game starts to experience multiple second long "stutters" (personally I'd just call that freezing)

They also test async compute on Nvidia and AMD and find no benefit to either.  As an aside, AMD seems to have some issues with frametime consistency

[corsairian]

Gta 4 on pc before the patch a couple years ago was so hard to run. 5820k and a 1080 and I couldnt even do 4k. On a 12 year old game. I think I was getting under 60fps at 1440p.

[vanished]

13 minutes ago, corsairian said:

Gta 4 on pc before the patch a couple years ago was so hard to run. 5820k and a 1080 and I couldnt even do 4k. On a 12 year old game. I think I was getting under 60fps at 1440p.

Even with the patch it was never an efficient game.  In fact, "the patch" depends what you're even referring to as contrary to what you'd hope and expect, the latest version wasn't always the best.  I distinctly recall having the best performance with 1.0.4.0 (patch 4), even though they eventually went to 1.0.7.0 iirc and afaik I was not alone with this

[Mira Yurizaki]

59 minutes ago, Ryan_Vickers said:

They also test async compute on Nvidia and AMD and find no benefit to either.

I'm starting to see the option to toggle async compute like turbo buttons on old PCs. Turning async compute off so far will either do almost nothing or degrade performance. It should just be a thing that comes with using the DX12/Vulkan render path. Even with compatible GPUs that cannot actually use multiple command queues to enable async compute, the driver simply does some magic to make it act like a single command queue.

 

Plus I find trying to poke at AMD or NVIDIA over "who has better async compute support" silly. The only question to answer with regards to async compute support is "does the GPU accept different command queues?"

[vanished]

25 minutes ago, Mira Yurizaki said:

I'm starting to see the option to toggle async compute like turbo buttons on old PCs. Turning async compute off so far will either do almost nothing or degrade performance. It should just be a thing that comes with using the DX12/Vulkan render path. Even with compatible GPUs that cannot actually use multiple command queues to enable async compute, the driver simply does some magic to make it act like a single command queue.

 

Plus I find trying to poke at AMD or NVIDIA over "who has better async compute support" silly. The only question to answer with regards to async compute support is "does the GPU accept different command queues?"

I suppose there's potentially quite a lot to it.  Does that setting in the file actually change how the game works or is it just a left over with no function?  How do different cards handle async compute?  Perhaps the traditional memes of "nvidia can't do it, only AMD knows how" aren't necessarily accurate, but it's hard to imagine they just appeared out of no where with no basis in reality.  I suspect at some point someone tried using async compute on AMD and nvidia cards and drew conclusions from which one benefited more - nothing fancy, but information worth knowing at the time, assuming it was tested correctly.  Whether those results were even accurate then, and if they still hold up today is another story though.

[Mira Yurizaki]

30 minutes ago, Ryan_Vickers said:

I suppose there's potentially quite a lot to it.  Does that setting in the file actually change how the game works or is it just a left over with no function?

That is a good question because asynchronous compute isn't really an application feature. It's something the hardware has to do to handle multiple command queues the application does make. So if anything, if the application is really doing something to influence what hardware does, then all it's doing is shoving everything down a single queue. Or if we were to use Windows terms, a single engine on the GPU, likely the Graphics engine.

 

EDIT: On that note, I should find a game in my library that has an async compute toggle and see if this really happens.

 

Quote

How do different cards handle async compute?

While I feel like it's interesting to go over this, this is an implementation detail. It'd be like asking how Intel and AMD handle x86-64 instructions.

 

Quote

Perhaps the traditional memes of "nvidia can't do it, only AMD knows how" aren't necessarily accurate, but it's hard to imagine they just appeared out of no where with no basis in reality.  I suspect at some point someone tried using async compute on AMD and nvidia cards and drew conclusions from which one benefited more - nothing fancy, but information worth knowing at the time, assuming it was tested correctly.  Whether those results were even accurate then, and if they still hold up today is another story though.

I think this all stemmed from the beginning when the developers of Ashes of the Singularity called foul on NVIDIA for telling them to us a specific code path or something. This is on top of a handful of examples showing that AMD gained an incredible performance boost with async compute than NVIDIA.

 

However, I think we're attributing performance gains to a single attribute when DirectX 12 and Vulkan introduced a lot of things that was meant to help with performance. Like for example, how does one explain this? (from https://www.anandtech.com/show/8962/the-directx-12-performance-preview-amd-nvidia-star-swarm/)

 

 

As far as I can tell, Star Swarm doesn't use async compute, and yet we're seeing massive performance gains simply by using DX12/Mantle.  And while I was digging around for information on this topic, I came across this slide deck from a GDC presentation. Slides 9 and 12 interest me the most:

 

From Slide 9:

Quote

Hardware Details [AMD]

• 4 SIMD per CU
• Up to 10 Wavefronts scheduled per SIMD
  • Accomplish latency hiding
  • Graphics and Compute can execute simultaneously on same CU
• Graphics workloads usually have priority over Compute

 

From Slide 12:

Quote

Hardware Details [NVIDIA]

• Compute scheduled breadth first over SMs
• Compute workloads have priority over graphics
• Driver heuristic controls SM distribution

If what this slide deck is saying is true, then to me it makes sense why NVIDIA doesn't see much of a boost from async compute as AMD. If you're already prioritizing compute workloads for a feature that's described as squeezing compute tasks alongside graphics ones, then I don't see how you'll get much of a boost in performance.

 

On another note, when also looking around for information on async compute, embarrassingly I found out how I thought NVIDIA Kepler schedules tasks is wrong. I thought the drivers scheduled workloads from beginning to end and the GPU is simply distributing the work as best as possible. i.e., it's just a dumb instruction dispatcher. But it's not, it has a typical scheduler but an aspect from Fermi's scheduler was chopped off because it could be done in software. So how NVIDIA and AMD schedules tasks on their GPU is mostly a moot point.

[vanished]

https://www.youtube.com/post/Ugyryy0KUnXUkd5-9yx4AaABCQ