- cross-posted to:
- games@lemmy.world
- cross-posted to:
- games@lemmy.world
"These price increases have multiple intertwining causes, some direct and some less so: inflation, pandemic-era supply crunches, the unpredictable trade policies of the Trump administration, and a gradual shift among console makers away from selling hardware at a loss or breaking even in the hopes that game sales will subsidize the hardware. And you never want to rule out good old shareholder-prioritizing corporate greed.
But one major factor, both in the price increases and in the reduction in drastic “slim”-style redesigns, is technical: the death of Moore’s Law and a noticeable slowdown in the rate at which processors and graphics chips can improve."
You’ve got that a bit backwards. Integrated memory on a desktop computer is more “partitioned” than shared - there’s a chunk for the CPU and a chunk for the GPU, and it’s usually quite slow memory by the standards of graphics cards. The integrated memory on a console is completely shared, and very fast. The GPU works at its full speed, and the CPU is able to do a couple of things that are impossible to do with good performance on a desktop computer:
When two processing devices try and access the same memory there are contention problems as the memory cannot be accessed by two devices at the same time (well, sorta: parallel reads are fine, it’s when one side is writing that there can be problems), so one of the devices has to wait, so it’s slower than dedicated memory but the slowness is not constant since it depends on the memory access patterns of both devices.
There are ways to improve this: for example, if you have multiple channels on the same memory module then contention issues are reduced to the same memory block, which depends on the block-size, though this also means that parallel processing on the same device - i.e. multiple cores - cannot use the channels being used by a different device so it’s slower.
There are also additional problems with things like memory caches in the CPU and GPU - if an area of memory cached in one device is altered by a different device that has to be detected and the cache entry removed or marked as dirty. Again, this reduces performance versus situations where there aren’t multiple processing devices sharing memory.
In practice the performance impact is highly dependent on if an how the memory is partitioned between the devices, as well as by the amount of parallelism in both processing devices (this latter because of my point from above that memory modules have a limited number of memory channels so multiple parallel accesses to the same memory module from both devices can lead to stalls in cores of one or both devices since not enough channels are available for both).
As for the examples you gave, they’re not exactly great:
I don’t think that direct access by the CPU to manipulate GPU data is at all a good thing (by the reasons given on top) and to get proper performance out of a shared memory setup at the very least the programming must done in a special way that tries to reduce collisions in memory access, or the whole thing must be setup by the OS like it’s done on PCs with integrated graphics, were a part of the main memory is reserved for the GPU by the OS itself when it starts and the CPU won’t touch that memory after that.
Can you explain to me what the person you are replying to meant by ‘integrated memory on a desktop pc’?
I tried to explain why this phrase makes no sense, but apparently they didn’t like it.
…Standard GPUs and CPUs do not share a common kind of RAM that gets balanced between space reserved for CPU-ish tasks and GPU-ish tasks… that only happens with an APU that uses LPDDR RAM… which isn’t at all a standard desktop PC.
It is as you say, a hierarchy of assets being called into the DDR RAM by the CPU, then streamed or shared into the GPU and its GDDR RAM…
But the GPU and CPU are not literally, directly using the actual same physical RAM hardware as a common shared pool.
Yes, certain data is… shared… in the sense that it is or can be, to some extent, mirrored, parellelized, between two distinct kinds of RAM… but… not in the way they seem to think it works, with one RAM pool just being directly accessed by both the CPU and GPU at the same time.
… Did they mean ‘integrated graphics’ when they … said ‘integrated memory?’
L1 or L2 or L3 caches?
???
I still do not understand how any standard desktop PC has ‘integrated memory’.
What kind of ‘memory’ on a PC… is integrated into the MoBo, unremovable?
???
Hah, now you made me look that stuff up since I was talking anchored on my knowledge of systems with multiple CPUs and shared memory, since that was my expectation about the style of system architecture of the PS5, since in the past that’s how they did things.
So, for starters I never mentioned “integrated memory”, I wrote “integrated graphics”, i.e. the CPU chip comes together with a GPU, either as two dies in the same chip package or even both on the same die.
I think that when people talk about “integrated memory” what they mean is main memory which is soldered on the motherboard rather than coming as discrete memory modules. From the point of view of systems architecture it makes no difference, however from the point of view of electronics, soldered memory can be made to run faster because soldered connections are much closer to perfect than the mechanical contact connections you have for memory modules inserted in slots.
(Quick explanation: at very high clock frequencies the electronics side starts to behave in funny ways as the frequency of the signal travelling on the circuit board gets so high and hence the wavelength size gets so small that it’s down to centimeters or even milimeters - around the scale of the length of circuit board lines - and you start getting effects like signal reflections and interference between circuit lines - because they’re working as mini antennas so can induce effects on nearby lines - hence it’s all a lot more messy than if the thing was just running at a few MHz. Wave reflections can happen in connections which aren’t perfect, such as the mechanical contact of memory modules inserted into slots, so at higher clock speeds the signal integrity of the data travelling to and from the memory is worse than it is with soldered memory whose connections are much closer to perfect).
As far as I know nowadays L1, L2 and L3 caches are always part of the CPU/GPU die, though I vaguelly remember that in the old days (80s, 90s) memory cache might be in the form of dedicated SRAM modules on the motherboard.
As for integrated graphics, here’s some reference for an Intel SoC (system on a chip, in this case with the CPU and GPU together in the same die). If you look at page 5 you can see a nice architecture diagram. Notice how memory access goes via the memory controller (lower right, inside the System Agent block) and then the SoC Ring Interconnect which is an internal bus connecting everything to everything (so quite a lot of data channels). The GPU implementation is the whole left side, the CPU is top and there is a cache slice (at first sight an L4 cache) at the bottom shared by both.
As you see there, in integrated graphics the memory access doesn’t go via the CPU, rather there is a memory controller (and in this example a memory cache) for both and memory access for both the CPU and the GPU cores goes through that single controller and shares that cache (but lower level caches are not shared: notice how the GPU implementation contains its own L3 cache - bottom left, labelled “L3$”)
With regards to the cache dirty problems I mentioned in the previous post, at least that higher level (L4) cache is shared so instead of cache entries being made invalid because of the main memory being changed outside of it, what you get is a different performance problem were there is competiton for cache usage between the areas of memory used by the CPU and areas of memory used by the GPU (as the cache is much smaller than the actual main memory, it can only contain copies of part of the main memory, and if two devices are using different areas of the main memory they’re both causing those areas to get cached but the cache can’t fit both so depending on the usage pattern it might constantly be ejecting entries for one area of memory to make room for entries for the other area of memory and back, which in practice makes it as slow as not having any cache there - there are lots of tricks to make this less of a problem but it’s still slower than if there was just one processing device using that cache such as you get with each processing device having its own cache and its own memory).
As for contention problems, there are generally way more data channels in an internal interconnect as the one you see there than in the data bus to the main memory modules, plus that internal interconnect will be way faster, so the contention in memory access will be lower for cached memory but with cache misses (memory locations not in cache and hence that have to be loaded from main memory) that architecture will still suffer from two devices sharing the main memory hence that memory’s data channels having to be shared.
addie said:
Then I wrote my own reply to them, as you did.
And then I also wrote this, under your reply to them:
And now you are saying:
I mean, I do genuinely appreciate your detailed, technical explanations of these systems and hardware and their inner functions…
But also, I didn’t say you said integrated memory.
I said the person you are replying to, addie, said integrated memory.
I was asking you to perhaps be able to explain what they meant… because they don’t seem to know what they’re trying to say.
But now you have misunderstood what I said, what I asked, lol.
You replied to addie … I think, as if they had written ‘integrated graphics’. But they didn’t say that. They said ‘integrated memory’.
And… unless I am … really, really missing something… standard desktop PCs… do not have any kind of integrated memory, beyond like… very, very small areas where the mobo bios is stored, but that is almost 100% irrelevant to discussion about video game rendering capabilities.
As you say, you have to go back 20+ years to find desktop PCs with Mobos that have their own SRAM… everything else is part of the GPU or CPU die, and thus … isn’t integrated. As GPUs and CPUs are removable, swappable, on standard desktop PCs.
Eitherway, again, I do appreciate your indepth technical info!
Well, I wasn’t sure if you meant that I did say that or if you just wanted an explanation, so I both clarified what I said and I gave an explanation to cover both possibilities :)
I think the person I was replying to just got confused when they wrote “integrated memory” since as I explained when main memory is “integrated” in systems like these, that just means it’s soldered on the motherboard, something which really makes no difference in terms of architecture.
There are processing units with integrated memory (pretty much all microcontrollers), which in means they come with their own RAM (generally both Flash Ram and SRAM) in the same integrated circuit package or even the same die, but that’s at the very opposite end of processing power of a PC or PS5 and the memory amounts involved tend to be very small (a few MB or less).
As for the “integrated graphics” bit, that’s actually the part that matters when it comes to performance of systems with dedicate CPU and GPU memory vs systems with shared memory (integrated in the motherboard or otherwise, since being soldered on the motherboard or coming as modules doesn’t really change the limitations of each architecture) which is what I was talking about back in the original post.
I… uh… what?
Integrated memory, on a desktop PC?
Genuinely: What are you talking about?
Typical PCs (and still many laptops)… have a CPU that uses the DDR RAM that is… plugged into the Mobo, and can be removed. Even many laptops allow the DDR RAM to be removed and replaced, though working on a laptop can often be much, much more finnicky.
GPUs have their own GDDR RAM, either built into the whole AIB in a desktop, or inside of or otherwise a part of a laptop GPU chip itself.
These are totally different kinds of RAM, they are accessed via distinct busses, they are not shared, they are not partitioned, not on desktop PCs and most laptops.
They are physically and design distinct, set aside, and specialized to perform with their respective processor.
The kind of RAM you are talking about, that is shared, partitioned, is LPDDR RAM… and is incompatible with 99% of desktop PCs
…
Also… anything, on a desktop PC, that gets loaded and processed by the GPU… does at some point, have to go through the CPU and its DDR RAM first.
The CPU governs the actual instructions to, and output from, the GPU.
A GPU on its own cannot like, ask an SSD or HDD for a texture or 3d model or shader.
(addition to the quote is mine)
Like… there is GPU Direct Storage… but basically nothing actually uses this.
https://www.pcworld.com/article/2609584/what-happened-to-directstorage-why-dont-more-pc-games-use-it.html
Maybe it’ll take off someday, maybe not.
Nobody does dual GPU SLI anymore, but I also remember back when people thought multithreading and multicore CPUs would never take off, because coding for multiple threads is too haaaaarrrrd, lol.
…
Anyway, the reason that emulators have problems doing the things you describe consoles a good at… is because consoles have finetuned drivers that work with only a specific set of hardware, and emulators have to reverse engineer ways of doing the same, which will work on all possible pc hardware configurations.
People who make emulators generally do not have direct access to the actual proprietary driver code used by console hardware.
If they did, they would much, much more easily be able to… emulate… similar calls and instruction sets on other PC hardware.
But they usually just have to make this shit up on the fly, with no actual knowledge of how the actual console drivers do it.
Reverse engineering is astonishingly more difficult when you don’t have the source code, the proverbial instruction manual.
Its not that desktop PC architecture … just literally cannot do it.
If that were the case, all the same issues you bring up that are specific to emulators… would also be present with console games that have proper ports to PC.
While occasionally yes, this is sometimes the case, for some specific games with poor quality ports… generally no, not this is not true.
Try running say, an emulated Xbox version of Deus Ex: Invisible war, a game notoriously handicapped by its console centric design… try comparing the PC version of that, on a PC… to that same game, but emulating the Xbox version, on the same exact PC.
You will almost certainly, for almost every console game with a PC port… find that the proper PC version runs better, often much, much better.
The problem isn’t the PC’s hardware capabilities.
The problem is that emulation is inefficient guesswork.
Like, no shade at emulator developers whatsoever, its a miracle any of that shit works at all, reverse engineering is astonishingly difficult, but yeah, reverse engineering driver or lower level code, without any documentation or source code, is gonna be a bunch of bullshit hacks that happen to not make your PC instantly explode, lol.