1
\$\begingroup\$

I am not an EE, and so I'm running this conjecture on breaking out the GPU from the CPU by folks who have better knowledge than me. Perhaps you can point out something I don't know about modern CPU architecture.

Many modern processors provide integrated graphics, with the exception of some AMD processors which provide additional cores in some models (Ryzen 5 2600) and integrated graphics in others (Ryzen 5 2400G). Off-chip graphics currently use a PCI-Express bus, while on-chip graphics appear to the OS as some kind of IO device on some kind of bus (details unimportant: figuring out bus and device is what your OS does).

Per my understanding, a CPU may execute extended instructions such as for FPU; whereas a graphics chipset is a self-contained computing platform performing I/O on a working set on its own. Software does not intermix GPU instructions with CPU instructions, and the GPU doesn't operate on the same RAM; rather the GPU has its own processing frequency, its own instruction stream, and its own RAM space.

This suggests to me that a GPU off CPU would be sensible. Just as modern PCI-Express graphics adapters use a generic interface, a GPU chip could use a standardized socket interface. The CPU could connect it to a bus and provide RAM; while the output pins could route to whatever chipset encodes to HDMI, DVI, or other video output port.

A CPU could assign the GPU's video range to a DMA-mapped area of RAM, or it could allocate a separate RAM channel (e.g. one or two RAM slots) to a second MMU which services the GPU, thus avoiding contention with the CPU. An MMU capable of shared access can also disable its own access to a RAM slot and enable a secondary MMU, making this configurable. The CPU would allow the GPU DMA access to system RAM so it could copy data into its own memory space just like a graphics card.

This seems to leave one trade-off: the VRAM would be regular system RAM, rather than GDDR5 or LPDDR4 or whatever the manufacturer wants to stick on their card.

If the above is correct, then there's no real advantage to integrating the GPU with the CPU on non-embedded systems; whereas providing a GPU socket would allow pairing better CPUs with separate low-cost GPUs. A desktop PC doesn't make sense as a SoC, while a dedicated socket for a GPU makes sense because every PC needs some kind of graphics and the interface is routinely standardized across PCI-Express.

Integrating the MMU and north/south bridge makes plenty of sense due to the specific hardware interdependence and large amounts of data passed between each continuously: this saves latency.

Likewise, graphics card DMA would go across the MMU in the CPU, tightly-coupling these. The MMU would expose a chunk of RAM just like it works with integrated graphics; if the GPU wants to manage virtual memory, it can treat that as physical RAM and integrate its own MMU, thus avoiding the overhead of an off-chip MMU. This seems no different than on-die GPU.

Does all of this make sense, or is there some enormous advantage I'm missing (besides separate package cost) having the GPU on the same die instead of plugged into a nearby socket?

\$\endgroup\$
9
  • 1
    \$\begingroup\$ Could you please summarize the question? I tried to read it twice and could not crystallize it. \$\endgroup\$
    – Eugene Sh.
    Sep 24, 2018 at 19:39
  • \$\begingroup\$ Having the GPU as a separate chip used to be the norm. Integrating them onto a single chip allows communication between them to be much faster. \$\endgroup\$ Sep 24, 2018 at 19:40
  • 3
    \$\begingroup\$ it's the same argument that's been going on since the dawn of computing - tightly coupled is cheaper, faster and lower power while the requirements are stable, but off chip is more versatile and scalable and should we have a standard interface? The two design styles aim for different sweet spots in different markets. \$\endgroup\$
    – Neil_UK
    Sep 24, 2018 at 19:45
  • 3
    \$\begingroup\$ Sockets are surprisingly expensive, and effectively the standard GPU socket is the PCIe socket. Either you care about graphics and want a large separate GPU, or you don't and want something cheap and minimally adequate on die. \$\endgroup\$
    – pjc50
    Sep 24, 2018 at 19:53
  • 1
    \$\begingroup\$ A lot of what you write about sounds like the kind of discussion which went on in the late 90's when graphics cards were making the PCI->AGP move. And others have already said, PCIe is currently the standard GPU socket. It's probably more standard than the current CPU sockets are. \$\endgroup\$
    – brhans
    Sep 25, 2018 at 2:08

3 Answers 3

8
\$\begingroup\$

I think you're misunderstanding the situation a bit. There already is a specialized socket for GPUs -- that's what PCI Express x16 is! Like AGP before it, PCI Express is a fast bus designed to support communication between the CPU and GPU. (It also happens to be a PCI replacement, which is convenient for other peripherals.)

Integrated GPU/CPU combos target low-end and low-power systems. They're designed to be cheap and run cool. The nature of these systems is that their users fundamentally don't care about the GPU. It's just there to accelerate the graphics of the OS and maybe do some light gaming. Intel's GPUs were already on the low-performance end, so this was a good niche for them to target. AMD followed suit to compete in that space. If you care about GPU performance, you buy a discrete GPU.

So what does having a motherboard socket instead of a PCIx slot get you? Sharing system RAM is a very bad idea because high-end GPUs actually do need a ton of RAM. You'd need to cram another large heat sink/fan combo on the motherboard. And you'd end up basically reinventing PCI Express to communicate with the GPU.

\$\endgroup\$
4
  • \$\begingroup\$ True. I just feel a dedicated bank of system RAM and use of the on-board output ports takes up less space and incurs less expense than buying a whole daughterboard with its own RAM banks. Sharing a RAM module would introduce delays waiting for memory RAS/CAS and bus access; the MMU can directly map a whole module and now you have the same physical architecture as a daughterboard with dedicated RAM. You get to select GPU+CPU separately with just a chip, not a whole card. I don't see how this would have less performance than on-die; it WOULD cost more and require its own cooling. \$\endgroup\$
    – John Moser
    Sep 27, 2018 at 14:22
  • 1
    \$\begingroup\$ Motherboards are already pretty dense, though. You'd need another 2-4 RAM slots and space for the chip itself (and a giant heatsink/fan), and then you'd have to route hundreds of signals. On top of that, you have to add more power supplies to the motherboards and a couple more sockets for PSU connectors. (They'll have to handle the highest power needed for the fastest GPU regardless of what you actually use.) Then double all that for SLI/Crossfire support. You'd also need to standardize on a socket, and we haven't even done that with CPUs. \$\endgroup\$
    – Adam Haun
    Sep 27, 2018 at 16:13
  • \$\begingroup\$ I have 4 RAM slots on my motherboard, which take 16GB RAM chips. I hardly think 64GB with another 32GB-64GB is a notable use case for what would essentially replace on-CPU GPU. Remember you can still just use PCI-Express; and on-die GPUs contradict some of your points. As well, a standard GPU socket (or generic coprocessor socket) would be less specialized than a CPU: it takes DMA transfer and runs its own execution units. There's a reason this works over PCI. A CPU has a more-complex task. \$\endgroup\$
    – John Moser
    Sep 28, 2018 at 17:10
  • \$\begingroup\$ As well as needing lots of RAM, GPUs need a ton of memory bandwidth. That means a lot of traces for separate memory channels, and my understanding is that it's (much?) easier to run them at high speed without huge power if they're all physically close so the traces can be short and their full layout controlled. \$\endgroup\$ Feb 7, 2023 at 2:23
1
\$\begingroup\$

Yes, it should be possible to make pluggable GPU, but why? I think memory-sharing is going to be a biggest problem: AFAIK, there are no current standards around for that, so manufacturer would either have to make one from scratch (a lot of work), or only sell a few GPU models per CPU. Either way, you would have to send extremely high speed memory connections over multiple physical connectors and deal with all sorts of random memory chips users might insert. I do not think this will work very well at all.

And if you decided to bundle the memory with GPU, then you can just use PCI Express for the bus, and maybe change a connector a bit to add video output lines. Then you get a mobile video card -- those exist, MXM is the latest standard. Examples:

\$\endgroup\$
3
  • \$\begingroup\$ Your answer seems to miss the fact that not only is it possible but it is often done. How can you argue that it will not work very well? \$\endgroup\$ Sep 24, 2018 at 21:07
  • \$\begingroup\$ Eh? in the modern computers, the memory is much faster than interconnect. For example, PCIe 30 x16 is ~16GB/sec, while DDR4 PC4-21333 is 21GB/sec per stick. So sure, you can technically share video memory over PCIe, but this will be a sever performance hit. \$\endgroup\$
    – theamk
    Sep 25, 2018 at 3:18
  • \$\begingroup\$ Fair enough. I was thinking of adding a specific standard for GPUs, not a specialized socket to fit the motherboard chipset. Same deal as PCI-e. Intel/AMD/nVidia GPU paired to any CPU. Essentially, a GPU daughterboard takes up a lot more space than a GPU chip, comes with its own RAM, ports, etc. A GPU chip would use the motherboard's own ports and route directly to system RAM—either a whole module (fast) or a sectioned area (RAS/CAS delays introduced by sharing with CPU). That's a cheaper expansion. As far as I understand, GPU to RAM is critical; GPU to CPU is much less critical. \$\endgroup\$
    – John Moser
    Sep 27, 2018 at 14:21
0
\$\begingroup\$

Does all of this make sense, or is there some enormous advantage I'm missing (besides separate package cost) having the GPU on the same die instead of plugged into a nearby socket?

There is an advantage, the first one is size which for laptops having the CPU and GPU in the same package reduces the size somewhat. It reduces layout constraints on the motherboard (all of those traces are in the same package, not on the PCB). The other benefit is with both dies in the same package they can share a heatsink, which also saves space (which the industry trends smaller especially with newer laptops and tablets).

As far as the architecture, they could also share memory, and it would be more advantageous to move the GPU to a direct processor link. As for now everything is still routed through the north bridge chipset (which is more commonly on die with the CPU). You also get shorter traces between dies, which saves time, as for now the changes are mostly physical as the data is still routed through the north bridge and PCI lanes on most CPU/GPU chips.

enter image description here Source: https://www.pcworld.com/article/2600325/intel-turns-its-attention-to-desktop-performance-unveils-8-core-haswell-e-processor.html

\$\endgroup\$
1
  • \$\begingroup\$ Ah yeah, you're saving a little space in laptops. My impression is the GPU is a batch processor—it's its own computing system—and transfer rate is more important than transfer latency. At 60fps, you have roughly six million cycles between frames at 350MHz, which means 50,000 cycles of latency to update positional information in rendering a scene is not even 1% of the available time; transferring tons of data slowly, on the other hand, is a huge problem. \$\endgroup\$
    – John Moser
    Sep 27, 2018 at 14:35

Not the answer you're looking for? Browse other questions tagged or ask your own question.