Live data from Hacker News

Ask HN: How does a CPU communicate with a GPU?

news.ycombinator.com

71–80 of 100 posts

Re: Ask HN: How does a CPU communicate with a GPU?

#71
post #69

Earlier quoted context omitted.

Oh! I know this one! PCI itself is comprised of several layers, from a physical layer, to a link layer, to a transaction layer and application layers. At the physical level we're literally pushing the limits of semiconductor physics as an industry. :-) There's all sorts of tricks, like 8b10b encodings[1] to address error handling and recovery, and then different ways to itself transmit the PCI signal. You can, for ex…

8b10b is like, 3 PCI generations old (PCI 2)! The next thing was 128b130b (PCI 3-5) and apparently 6 is moving to 242B/256B.

Fascinating. So I guess I date myself there. But - it makes sense having read a bit. There’s remarkable complexity. “Strong statistical bounds” is again a reason for me to say “it is amazing anything works, anywhere.” I say this typing on a capacitive piece of glass that happens to be a multitouch display, glued to a battery, a quad core processor, and a very precisely arranged lump of sand and gold that’s able to literally shout into the microwave aether to a thingie on a pole in the middle of the air, which then is relaying (encrypted btw) data to some box somewhere that results in an interrupt occurring, a cpu servicing that, and many other things happening many times to result in random people somewhere eventually reading this message.

We’ve come pretty far from the telegraph, haven’t we?

Re: Ask HN: How does a CPU communicate with a GPU?

#72

TL;DR: bi-directional memory access with some means to notify the other part about "something has changed". It's not that different for any other PIC/E device, be it a network card or a disk/HBA/RAID controller. If you want to understand how it came to this - look at the history of ISA, PCI/PCI-X, a short stint for AGP and finally PCI-E. Other comments provides a good ELI15 for the topic. A minor note about "bus" - f…

I find it very interesting that you mention looking at the history of ISA's first in order to understand the current iteration of the technology. I was reading the RISC-V privileged ISA recently and the amount of seemingly arbitrary registers and behaviours that must be implemented to support a UNIX-like OS is crazy, and that got me thinking about the history behind all of these things that the hardware must support…

Ha! I definitely meant ISA bus, as others had mentioned.

Kudos to swetland and phendrenad2!

Re: Ask HN: How does a CPU communicate with a GPU?

#73

Woah there, my dude. Let's try to understand a simple model first. A CPU can access memory. When a CPU performs loads & stores it initiates transactions containing the address of the memory. Therefore, it is a bus master--it initiates transactions. A slave accepts transactions and services them. The interconnect routes those transactions to the appropriate hardware, e.g. the DDR controller, based on the system addres…

Yeah, your explanation really hits the nail in regards to what I was trying to understand - MMIO coupled with all of that bus dynamic of a master and slave going on. It's clear to me now that my knowledge gap resides in not knowing enough about interconnects. Thanks a lot! I do wonder, why aren't interconnects more emphasized in the courses I took? All I've seen was just oversimplified pictures of the process. Your e…

> Yeah, your explanation really hits the nail in regards to what I was trying to understand

:)

There's a lot of knowledge, and acronyms, and BS out there. E.g. there is no need to discuss PCIe here. It's much easier, and enjoyable, to cultivate a simple understanding of fundamentals. Build up from there. Reduce it down to your own simple model.

Interconnects focus on the transfer of data between components in the system. Topics like topology, switching/routing, and performance come into play. But, for the purposes of the simple model described above, all you really need to grasp is topology. I.e., how are things connected and where is data flowing?

The memory model is another extension to the simple model described above. Both the CPU and the GPU have access to DRAM memory (shared memory). The CPU can send transactions to the GPU, and the GPU can interrupt the CPU. These are all different paths thru the system. But, remember that we described a very specific order of events that need to happen for shared memory communication between CPU and GPU. E.g. (1) the CPU sends transactions to the DDR controller to store some information in DRAM memory, and then (2) sends a transaction to the GPU to inform the GPU that it can now (3) send transactions to the DDR controller to retrieve that information from DRAM memory. But what if (1) and (3) happen much faster than (2)? The GPU will get old data, not the new data that was written by the CPU. Managing these order of events in the system is what the memory model is all about. What if shared memory exists not only in DRAM memory but also in caches elsewhere in the system?

Edit:

Back to your question of "how a CPU tells a GPU to start executing a program"...

In the simple model, you could imagine something like: (1) CPU stores the shader program in DRAM memory. (2) CPU writes a GPU register informing the GPU of what address the shader program is located at in DRAM memory. (3) CPU also informs the GPU of the size of the shader program. (4) GPU loads the shader program from DRAM memory. (5) GPU starts executing shader program.

Re: Ask HN: How does a CPU communicate with a GPU?

#74
post #63

While we're here: is there any reasonable prospect of keeping one's GPU from being able to read and write to literally anywhere in physical memory? I.e., a practical way a kernel and driver might be able to forward to the GPU only commands and shaders that can access only your process memory, and nobody else's, and your process's pixels, and no other process's pixels, when they live in GPU RAM? For all I know, this i…

> is there any reasonable prospect of keeping one's GPU from being able to read and write to literally anywhere in physical memory?

This is the purpose of an IOMMU.

> I.e., a practical way a kernel and driver might be able to forward to the GPU only commands and shaders that can access only your process memory, and nobody else's, and your process's pixels, and no other process's pixels, when they live in GPU RAM?

So IOMMU and the GPU's MMU.

> For all I know, this is the norm for all GPUs

What?

> but I wonder why it is hard, then, for VMs to share a GPU.

Engineering is hard.

Re: Ask HN: How does a CPU communicate with a GPU?

#75
post #49

Earlier quoted context omitted.

IMO memory-mapped IO is the coolest thing since sliced bread. It's a great example in computing where many different kinds of hardware can all be brought together under a relatively simple abstraction.

relatively simple until you get into cache coherence (not an issue if you mark the memory as volatile)

Memory mapped IO is never cached as far as I know, so at least that's not a concern.

Re: Ask HN: How does a CPU communicate with a GPU?

#76
post #75
post #49

Earlier quoted context omitted.

relatively simple until you get into cache coherence (not an issue if you mark the memory as volatile)

Memory mapped IO is never cached as far as I know, so at least that's not a concern.

You'd still have to tell the compiler it's volatile if you were writing into the DMA buffer directly for some reason. GP just used the wrong words to say what they meant.

Re: Ask HN: How does a CPU communicate with a GPU?

#77

Woah there, my dude. Let's try to understand a simple model first. A CPU can access memory. When a CPU performs loads & stores it initiates transactions containing the address of the memory. Therefore, it is a bus master--it initiates transactions. A slave accepts transactions and services them. The interconnect routes those transactions to the appropriate hardware, e.g. the DDR controller, based on the system addres…

In a SoC (all phones) and most laptops with "integrated graphics", that's the way it works. Basically a multi-processor system with shared memory. It is actually more common in the wild than the PCIe model, where the GPU has dedicated memory.

Re: Ask HN: How does a CPU communicate with a GPU?

#78
post #49

Earlier quoted context omitted.

IMO memory-mapped IO is the coolest thing since sliced bread. It's a great example in computing where many different kinds of hardware can all be brought together under a relatively simple abstraction.

relatively simple until you get into cache coherence (not an issue if you mark the memory as volatile)

The volatile keyword in C has nothing to do with cache coherence and does not prevent cache coherence issues.

It just forces the compiler to generate all memory accesses on this variable. And if this variable is in a cached memory region, then it opens the door to very usual cache coherency problems

Re: Ask HN: How does a CPU communicate with a GPU?

#79
post #30

Earlier quoted context omitted.

Nice exercise. Similarly I learned most about basic computer architecture by programing 8050 in ASM as well as C. And I'm 32. Am I old yet? I'm not right? Right?

Sorry pal! I remember playing Halo in my early 20's, and chatting with a guy from LA who was 34. Wow, he's so old, why was he still playing video games. Here I sit in my late 30's...still playing games when I have time, denying that I'm old, despite the noises I make getting up and random aches and pains.

OK. I am definitely old...

- I have mostly no joy playing video games anymore these days.

- I found myself refusing some contemporary stuff in favour of stuff "I am used to".

Damn! I was always looking at my dad, not understanding that very same things :) Now I am a dad myself...

Re: Ask HN: How does a CPU communicate with a GPU?

#80

Woah there, my dude. Let's try to understand a simple model first. A CPU can access memory. When a CPU performs loads & stores it initiates transactions containing the address of the memory. Therefore, it is a bus master--it initiates transactions. A slave accepts transactions and services them. The interconnect routes those transactions to the appropriate hardware, e.g. the DDR controller, based on the system addres…

In a SoC (all phones) and most laptops with "integrated graphics", that's the way it works. Basically a multi-processor system with shared memory. It is actually more common in the wild than the PCIe model, where the GPU has dedicated memory.

:)
Post reply on HN