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:

• First, when loading models into the GPU memory, even with SSDs the disk read is by far the slowest part and hence the bottleneck, so as long as things are being done in parallel (i.e. whilst the data is loaded from disk to CPU memory, already loaded data is also being copied from CPU memory to GPU memory) you won't see that much difference between loading to CPU memory and then from there to GPU memory and direct loading to GPU memory. Further, the manipulation of models in shared memory by the CPU introduces the very performance problems I was explaining above, namely contention problems from both devices accessing the same memory blocks and GPU cache entries getting invalidated because the CPU altered that data in the main memory.
• Second, if I'm not mistaken tone mapping is highly parallelizable (as pixels are independent - I think, but not sure since I haven't actually implemented this kind of post processing), which means that the best by far device at parallel processing - the GPU - should be handling it in a shader, not the CPU. (Mind you, I might be wrong in this specific case if the algorithm is not highly parallelizable. My own experience with doing things via CPU or via shaders running in the GPU - be it image shaders or compute shaders - is that in highly parallelizable stuff, a shader in the GPU is way, way faster than an algorithm running in the CPU).

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.

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.

Normally, compressed game assets are loaded from the SSD to RAM via the Win32 API. Once in RAM, the CPU then decompresses those assets. The decompressed game assets are then moved from RAM to the graphics card’s VRAM (ie, GDDR RAM), priming the assets for use in games proper.

(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.