Gamers Are Wrong About 1440p vs 1080p CPU Benchmarking

[poshflamingos]

Now you're being intentionally obtuse. The CPU uses the PCIe bus to send data to the GPU, to perform network and disk I/o, etc ... and when the GPU is loading that bus via DMA calls, there is less bandwidth available for everyything else.

JFC
No, again, that's not how any of this works. None of those buses are shared. The GPU has its own, exclusive 16 PCIe lanes connecting to the CPU. The SSD has an additional 4 PCIe lanes connecting to the CPU, separate from the GPU's 16 lanes. And then the RAM has yet another separate bus, completely independent from PCIe altogether.
A GPU could be using 100% of its 16 PCIe lanes, and that still doesn't take away anything from the SSD and RAM buses, because none of those buses are shared.

I have no clue why you believe all game assets must be read from disc using random reads

Yes, all game assets in modern games are loaded through random operations. If you pack assets sequentially, you lose the ability to stream individual assets on demand. That could work on games that are split into separate levels that are loaded one by one, but most modern games are no longer made that way.

You don't need to "saturate" a bus to slow it down -- if you're using 10% for I/o, then only 90% remains for everything else.

"10%" of what?
If you mean RAM (where SSD assets are loaded into), even 10% is extremely generous. The 0.1 GB/s to 1 GB/s you get from random reads means between 0.2% and 2% of typical DDR4, and 0.1% to 1% of typical DDR5. Absolutely insignificant.

Still worse: you're forgetting that a GPU uses the bus *also* for direct memory access -- and this often does saturate it.

LMAO
SSD to VRAM (which, to be clear, does not actually happen, because there's no API for it yet; DirectStorage is not that, and RTX IO is not used by anyone yet; and no dev is manually programming DMA calls on the metal for their games) would be even more insignificant than to RAM. Random reads from a SSD mean 0.03% to 0.3% of the bandwidth of a RTX 3060, and 0.01% to 0.1% of the bandwidth of a RTX 5080.

Why on earth do you think we've consistently moved to higher bandwidth PCIe standards, if we weren't reaching limits on the existing ones?

We aren't. The vast majority of people are still on PCIe 3.0 or 4.0, even the most recent boards only have a partial implementation of PCIe 5.0 (most just for the M.2 slots), and there are zero plans to move to PCIe 6.0 or 7.0 on consumer hardware. Those newer revisions were made for datacenters, and consumer hardware does not benefit from it at all.

Learn how game engines work. As I said earlier, every major engine performs resolution-based LOD reduction. The fact you believe you can "test this easily" by loading up and game and looking at frame rates belies an utter lack of understanding. Why not at least attempt to learn about a subject before arguing it?

"...Unreal Engine manages Level of Detail (LOD) based on screen resolution using a "Screen Size" metric, which calculates the screen-space diameter of an object's bounding sphere."

That's not what I was talking about, genius. What you're talking about is just the engine choosing which version of the asset to default to relative to the screen. That's completely unrelated to the issue I was talking about. Choosing whether to use LOD 0, LOD 1, LOD 2, etc, depending on resolution does not produce additional draw calls.
I was talking about when games change environmental LODs and draw distances based on resolution, not the LOD of individual assets. For example, what Digital Foundry discovered on Forza Horizon 5. Changing resolution in FH5 changes the actual draw distance of objects and textures on the screen. You can see objects popping in and out and textures becoming degraded in the distance as you change the game's resolution. That's the issue I was referring to, and that issue does produce additional draw calls (because it's loading in more distant objects, not just higher LODs of the same object as your video is refering to).
And no, I don't mean you can easily test it by "looking at framerates". You can easily test it by using your eyeballs and seeing how on the vast majority of games, increasing the resolution alone does not make extra objects appear at a distance. But on Forza Horizon 5, one of the few games with this issue, increasing resolution alone does make extra objects appear at a distance. That is what increases CPU load, and it's not good practice. Good practice is for resolution and draw distances to be controlled separately.

 

[Endymio]

The GPU has its own, exclusive 16 PCIe lanes connecting to the CPU. The SSD has an additional 4 PCIe lanes connecting to the CPU, separate from the GPU's 16 lanes

No. While the x16 lane is usually GPU-CPU and the x4 lane usually NVME-CPU, none of this is hardwired. The x16 lane can be split, and any or all these can be redirected at will:

"...DirectStorage relies on PCIe NVMe lanes to function efficiently. It is designed to move game data directly from an NVMe SSD over the PCIe bus to the GPU, bypassing the CPU ...."

Nor is DirectStorage the only API performing this.

Yes, all game assets in modern games are loaded through random operations. If you pack assets sequentially, you lose the ability to stream individual assets on demand.

This is the most absurd yet. Allowing random access doesn't preclude sequential reads, nor do "all games" use random access exclusively. I found this easily enough:

" - Random Access Loading: Primarily used by open-world games (e.g., Cyberpunk 2077, Grand Theft Auto V) to stream small, scattered assets

• - Sequential I/O Loading: Used when loading large, contiguous files, such as when loading into a new scene in linear games or a single .dat file (e.g., Starfield, Nier: Automata or games with packed archives)

- Mixed Sequential and Random: DirectStorage games: Forspoken, Ratchet & Clank: Rift Apart...

While some packing schemes make random access inefficient, that's not what was originally stated.

SSD to VRAM (which, to be clear, does not actually happen, because there's no API for it yet; DirectStorage is not that, and RTX IO is not used by anyone yet; and no dev is manually programming DMA calls on the metal

I'm not even going to point out the error here, because the base issue exists without DirectStorage. When the CPU is decompressing assets to send to the GPU and those assets are based on resolution -- higher resolutions require work to load and decompress, annd thus more work for the CPU.

Point proven. Case closed.

That's not what I was talking about, genius. What you're talking about is just the engine choosing which version of the asset to default to relative to the screen. That's completely unrelated to the issue I was talking about. Choosing whether to use LOD 0, LOD 1, LOD 2, etc, depending on resolution does not produce additional draw calls.

Was this a joke? Higher levels of detail require larger assets, and more work to load, decompress, and render. That alone proves my point -- but you're still missing the fact that higher resolutions do indeed result in additional draws, when those resolutions expand previously sub-pixel (and thus undrawn) assets substantially. Yes it's a small factor -- unless you specifically design a scene to exploit the effect -- but it still exists.

 

[Tech420]

I never cared for 1440p. Never. Fail to see any point. It's a barely noticeable difference from 1080p.

1440p literally contains 80% more pixels. It's almost twice as good as 1080p. Maybe the 1440p monitor you were looking at was actually 1080p and someone just put the wrong sticker on it. You can check the monitor for any stickers that have corners that look like they are coming off, or check in your windows display settings to confirm the resolution.

 

[ignasc]

Some people really like to dig deep into this. Deeper than necessary.

You look at CPU benchmarks at low resolution to see what are the limitations of those CPU's.

You look at GPU benchmarks at high resolution to see what are the limitation of those GPU's.

Your so called "real world performance" is simply the lower performance of the two components - that's how fast your system will run current games. It will not be dead on the spot with numbers, but it will be very close to those numbers.

You have everything you need to pick a CPU and GPU that fits your needs now and be able to somewhat plan a little bit into the future. You don't look at just one of benchmarks to pick both components - you cross reference both benchmarks.

At the end of the day, CPU and GPU are very different components, despite working together in the system: you cannot use the same test on both of them.

Someone made car analogy earlier in the comments. If I were to make car analogy it would be more like this: the whole car is your PC, the engine is your GPU and tires are your CPU. You don't test engine performance with cheap, crappy tires on the wheels, the same way you don't test how well your tires hold on the road with a 1.0L engine either.

My personal experience with PC building has been great thanks to these benchmarks. I always kept my systems for 5-7 years with only a GPU upgrade half way through its lifespan. And I always picked CPU and GPU in the same fashion:
1. Set myself framerate target, usually around 90-120 fps range makes me happy for modern games.
2. Check, which GPU's are capable of that fps on average at 1440p with max quality settings.
3. Check, which CPU's are capable of that fps on average at low resolution.
4. For a little bit of GPU longevity, I pick GPU that can output around 120-140fps on average and is within my set budget. Even better if GPU can output more and is still within my budget.
5. I pick a mid range CPU that can output closer to 180-200 fps, again for longevity and is also within my budget.

Those two benchmarks give me all the answers I need for current gaming situation and gives me good insight of what to expect in the near future:
I know my system can run current games on average at around 120-140fps and I still have some room for future games. As games become more demanding, my system will slowly drop down to around 60-100 fps for newer games. I might adjust graphics settings in games to maintain performance and 3-4 years later I upgrade GPU and this will push my fps back to higher range, since CPU also had higher ceiling, I do not need to upgrade it just yet AND my cpu will probably still be in the new benchmarks, so I will be able to see what limits does it have for new games. Another 3 years later, my system will probably gonna be showing signs of aging, doing 60-80fps average with reduced graphics quality. At this point if my CPU is no longer listed in new benchmarks I might run my personal tests at very low resolutions, to see if fps improve - if not and GPU is not under full load, that means CPU hit it's limit. At this point I make decision: either do a full system upgrade or if my GPU is still capable, I only do CPU/MOBO/RAM upgrade and reuse my old GPU until it hits it's limit.

The above worked for me like charm for the past 3 systems I had. In fact, my previous system had I5-6600K paired with GTX 1070 and it was a very well paired system that aged nicely. So nicely, that I actually did a full platform upgrade to AMD and still reused my GTX 1070 for another year, until recently I replaced it with 5070 Ti.

 

[poshflamingos]

No. While the x16 lane is usually GPU-CPU and the x4 lane usually NVME-CPU, none of this is hardwired. The x16 lane can be split, and any or all these can be redirected at will:

Lanes can be split or redirected, but that's not something that just happens to you against your will and knowledge. You have to go out of your way to set it up like that. And why would you do that?

And it doesn't change the fact that RAM and VRAM buses are complete separate and independent from PCIe. You were talking about "system bus", as if there's a singular system-wide bus somewhere that all of those connections are sharing, and that is categorically wrong.

"...DirectStorage relies on PCIe NVMe lanes to function efficiently. It is designed to move game data directly from an NVMe SSD over the PCIe bus to the GPU, bypassing the CPU ...."

Again, I don't know what you're quoting, but whatever wrote this thing you quoted is wrong. DirectStorage is just an API, it by itself does NOT provide you direct SSD to VRAM transfers. If it did, features like RTX IO would have no reason to exist.

This is the most absurd yet. Allowing random access doesn't preclude sequential reads, nor do "all games" use random access exclusively.

I didn't say "all games" use random reads, I said modern ones (I.e. PS5/XSX generation ones) do. Old games don't. The reality is that any game designed to stream assets in real-time will inevitably rely on random reads, because assets packed together sequentially cannot be streamed. And the vast overwhelming majority of cutting-edge games this generation were built for asset streaming.

Sure, some mostly older games were built with separate linear levels, those can use sequential reads. But that means that 1) those games don't have the ability to stream assets, and 2) those games only load data during loading screens, so the performance impact that the storage has on gameplay is zero, because nothing is read/loaded during the levels where you're actually playing the game, only in between them.

I'm not even going to point out the error here, because the base issue exists without DirectStorage. When the CPU is decompressing assets to send to the GPU and those assets are based on resolution -- higher resolutions require work to load and decompress, annd thus more work for the CPU.

Was this a joke? Higher levels of detail require larger assets, and more work to load, decompress, and render.

This is another case where you have a fundamental misunderstainding of how game assets work.
When you're dealing with different levels of detail of the same model, like in your video where the game swaps between LOD 0, LOD 1, etc, of that tree model depending on resolution, those individual LODs are not separate files. The tree asset is one single file that includes all of those variations packed inside it. If you have a model with, say, six different LODs, the game always load all 6 LODs at once (because they're all one single asset file), and then simply decides which one to use. Same with mipmaps, they're not different files, they're variations of the same texture (plus texture maps) packed together into one asset.
So no, you do not have higher CPU load to load/decompress assets at higher resolutions. Because you're always loading/decompressing all variations of that asset at once, because they're all packed inside a single asset file.

That alone proves my point -- but you're still missing the fact that higher resolutions do indeed result in additional draws, when those resolutions expand previously sub-pixel (and thus undrawn) assets substantially. Yes it's a small factor -- unless you specifically design a scene to exploit the effect -- but it still exists.

This makes it obvious you also don't understand what a draw call is.
A draw call is a command the CPU issues to the GPU driver that says "this asset X exists in this point in space, so put it there on these coordinates". That happens at the start of the graphics pipeline, long before the rasterization step that will determine what is subpixel detail and what isn't. Whether something ends up being lost subpixel detail or not has no bearing whatsoever on draw calls or the CPU cost of draw calls, the act of placing that asset in 3D vector space is the draw call. So no, changing resolution alone has zero impact on draw calls, because draw calls have no relationship to what ends up as visible pixels. Even if you set the game to 640x480 and lose tons of visible detail in the process, the draw calls to place assets in 3D space (which happens before rasterization) are still the exact same as when you set resolution to 3840x2160.
Just to expand, draw calls also happen before GPU culling. The CPU has to place the asset in 3D vector space, before the GPU can decide whether to render it or not (because it fell outside of the camera view, or because it's obscured by another asset in front of it, for example). I'm saying this to clarify that draw calls have nothing whatsoever to do with whether the asset is visible on the final rendered frame or not. Even if it's not visible, whether from being culled or from being lost as subpixel detail, it still costs draw calls.

 

[poshflamingos]

Someone made car analogy earlier in the comments. If I were to make car analogy it would be more like this: the whole car is your PC, the engine is your GPU and tires are your CPU. You don't test engine performance with cheap, crappy tires on the wheels, the same way you don't test how well your tires hold on the road with a 1.0L engine either.

Your comment is great, but dear god, car analogies need to die.

 

[human7]

Yes, it takes work. So you go do that work then.

And that's the problem that I'm saying you (or anyone) can't solve. Until you can convince the people who took the poll to "do more work", the results of the poll will continue to have a strong response in favor of testing at multiple resolutions.

 

[Aranarth]

I still find it amazing people who are missing the point.

Computer are a SYSTEM of parts.

What are we testing? THE CPU.
How do we testing ONLY THE CPU? by isolating it from the system.
How do we do that?! by giving the system sufficient, ram, powerful graphics card, speedy ssd, etc.
Having done that now what are we testing? CPU performance in games!

In the past we would have done at 720p but now we do it one step higher at 1080p.

Anyone not understand this?

WE ARE NOT TESTING THE VIDEO CARD! We are NOT testing the system!

 

[GoldenGoat]

Good explanation of things. Probably would be more convincing if the author was not telling people they are wrong. People don’t like to be told they are wrong and can get defensive and then close their mind. If you make a solid case, some people might decide they were wrong on their own, but maybe not if they are instinctively getting defensive and closing their minds.

I think these people don’t care which cpu is the best. They just want to know how the cpu they want is going to handle the conditions they want to run it in. They might be less interested in a benchmark and more interested in a review.

I get laptops because of travel. I take whatever cpu Dell puts in their Alienware area 51. I don’t have to figure it out because they do it for me.