Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

41–50 of 100 posts

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

#41

Post by Keyframe »

zokier wrote: post #32
Keyframe wrote: post #27

Earlier quoted context omitted.

If OP or anyone else wants to see this firsthand.. well shit, I feel old now, but.. try an exercise into assembly programming of commodore 64. Get a VICE emulator and dig into it for a few weeks. It's real easy to get into, CPU (6502 based), video chip (VIC II), sound chip (famous SID), ROM chips.. they all love in this address space (yeah, not mentioning pages), CPU has three registers.. it's also real fun to get in…

Is my understanding correct that compared to those historical architectures, modern GPUs are a lot more asynchronous? What I mean that these days you'd issue a data transfer or program execution on the GPU, they will complete at its own pace and the CPU in the meanwhile continues executing other code; in contrast in those 8 bitters you'd poke a video register or whatev and expect that to have more immediate effect al…

There were interrupts telling you when certain things happened. If anything, it was asynchronous. Big thing is also that you had to tally the cost of what you eere doing. There was a budget of how many cycles you got per line, per screen and then fit whatever you had to in that. With playing sound it was common to draw color when you fed the music into SID so you could tell, like a crude debug/ad hoc printf, how many cycles your music routines ate.

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

#42

Post by Keyframe »

vletal wrote: post #30
Keyframe wrote: post #27

Earlier quoted context omitted.

If OP or anyone else wants to see this firsthand.. well shit, I feel old now, but.. try an exercise into assembly programming of commodore 64. Get a VICE emulator and dig into it for a few weeks. It's real easy to get into, CPU (6502 based), video chip (VIC II), sound chip (famous SID), ROM chips.. they all love in this address space (yeah, not mentioning pages), CPU has three registers.. it's also real fun to get in…

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?

40s are new thirties, my friend. Also, painkillers help.

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

#43

Post by tenebrisalietum »

divbzero wrote: post #7
rayiner wrote: post #3

Typically CPU and GPU communicate over the PCI Express bus. (It’s not technically a bus but a point to point connection.) From the perspective of software running on the CPU, these days, that communication is typically in the form of memory-mapped IO. The GPU has registers and memory mapped into the CPU address space using PCIE. A write to a particular address generates a message on the PCIE bus that’s received by th…

Going one deeper, how does the communication work on a physical level? I’m guessing the wires of the PCI Express bus passively propagate the voltage and the CPU and GPU do “something” with that voltage?

Older CPUs - the CPU had a bunch of A pins (address), a bunch of D pins (data).

The A pins would be a binary representation of an address, and the D pins would be the binary representation of data.

A couple of other pins would select behavior (read or write) and allow handshaking.

Those pins were connected to everything else that needed to talk with the CPU on a physical level, such as RAM, I/O devices, and connectors for expansion. Think 10-base-T networking where multiple nodes are physically modulating one common wire on an electrical level. Same concept, but you have many more wires (and they're way shorter).

Arbitration logic was needed so things didn't step on each other. Sometimes things did anyway and you couldn't talk to certain devices in certain ways or your system would lock up or misbehave.

Were there "switches" to isolate and select among various banks of components? Sure, they are known as "gate arrays" - those could be ASICs or implemented with simple 74xxx ICs.

Things like NuBus and PCI came about - the bus controller is directly connected and addressable to the CPU as a device, but everything else is connected to the bus controller, so now the new-style bus isn't tied to the CPU and can operate at a different speed and CPU and bus speed are now decoupled. (This was done on video controllers in the old 8-bit days as well - to get to video RAM you had to talk to the video chip, and couldn't talk to video RAM directly on some 8-bit systems).

PCIE is no longer a bus, it's more like switched Ethernet - there's packets and switching and data goes over what's basically one wire - this ends up being faster and more reliable if you use advanced modulation schemes than keeping multiple wires in sync at high speeds. The controllers facing the CPU still implement the same interface, though.

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

#44

Post by chubot »

BTW I believe memory maps are set up by the ioctl() system call on Unix (including OS X), which is kind of a "catch all" hole poked through the kernel. Not sure about Windows.

I didn't understand that for a long time ...

I would like to see a "hello world GPU" example. I think you open() the device and the ioctl() it ... But what happens when things go wrong?

Similar to this "Hello JIT", where it shows you have to call mmap() to change permissions on the memory to execute dynamically generated code.

https://blog.reverberate.org/2012/12/hello-jit-world-joy-of-...

I guess one problem is that this may be typically done in vendor code and they don't necessarily commit to an interface? They make you link their huge SDK

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

#45

Post by _3u10 »

throw82473751 wrote: post #15
divbzero wrote: post #7

Earlier quoted context omitted.

Going one deeper, how does the communication work on a physical level? I’m guessing the wires of the PCI Express bus passively propagate the voltage and the CPU and GPU do “something” with that voltage?

Voltages yes.. usually its all binary digital signals, running serial/parallel and following some communication protocol. Maybe you should have a look at something really simple/old like UART communication to get some idea how this works and then study next how this is scaled up over PCIE to understand the chat between CPU/GPU? Or maybe not, one does not need all the details, so often just scaled concepts :) https://…

https://pcisig.com/sites/default/files/files/PCI_Express_Ele... It doesn’t say QAM explicitly but it has all the QAM terminology like 128 codes. Inter symbol interference etc. I’m not an RF guy by any stretch but it sounds like QAM to me.

This is an old spec. I think it’s like equivalent to QAM-512 for PCIe 6

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

#46

Post by rayiner »

throw82473751 wrote: post #15
divbzero wrote: post #7

Earlier quoted context omitted.

Going one deeper, how does the communication work on a physical level? I’m guessing the wires of the PCI Express bus passively propagate the voltage and the CPU and GPU do “something” with that voltage?

Voltages yes.. usually its all binary digital signals, running serial/parallel and following some communication protocol. Maybe you should have a look at something really simple/old like UART communication to get some idea how this works and then study next how this is scaled up over PCIE to understand the chat between CPU/GPU? Or maybe not, one does not need all the details, so often just scaled concepts :) https://…

PCI-E isn't QAM. It's NRZ (a type of pulse amplitude modulation with just two amplitude levels), with 8/10b, 64/66b, or 128/130b encoding, and then scrambled to reduce long runs of 0s or 1s. I think PCI-E 6.0 uses PAM-4 with 4 amplitude levels.

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

#47

Post by throwmeariver1 »

arduinomancer wrote: post #22
throwmeariver1 wrote: post #11

Everyone in tech should read the book "Understanding the Digital World" by Brian W. Kernighan.

Is it very in-depth or more for layman readers?

Most normal people and junior devs would get a red head when reading it, techies and seniors would nod along and sometimes say "uh... so that's how it really works". It's in between but a good primer on the essentials.

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

#48

Post by simne »

zokier wrote: post #32
Keyframe wrote: post #27

Earlier quoted context omitted.

If OP or anyone else wants to see this firsthand.. well shit, I feel old now, but.. try an exercise into assembly programming of commodore 64. Get a VICE emulator and dig into it for a few weeks. It's real easy to get into, CPU (6502 based), video chip (VIC II), sound chip (famous SID), ROM chips.. they all love in this address space (yeah, not mentioning pages), CPU has three registers.. it's also real fun to get in…

Is my understanding correct that compared to those historical architectures, modern GPUs are a lot more asynchronous? What I mean that these days you'd issue a data transfer or program execution on the GPU, they will complete at its own pace and the CPU in the meanwhile continues executing other code; in contrast in those 8 bitters you'd poke a video register or whatev and expect that to have more immediate effect al…

It depends.

First, in modern systems you usually don't have direct access to GPU, but call syscall and than happen magic, something like this. And they all are multilayered architecture, mean, now normal, when systrace dump of some exception lists few hundreds functions, imagine how this slow.

This is because all modern systems except consoles, are direct descendants of business minicomputers, in which where most important, they could simultaneously run wallet and text processor (or electronic table, or email, etc), and these programs will not see each others memory, so errors in text will not lead to lost money from wallet.

Second, modern systems behave like NUMA architectures, or some people even named them distributed architectures, mean, that only CPU computing in userspace is fast.

In many cases you have choice, to do magic in sync way or async, but in any case, syscalls are extremely slow, in some cases could be few magnitudes slower than userspace CPU computing.

Sometimes lifesaver some sort of message passing architecture, so you send message to GPU and immediately could do your tasks without any waits at all (kernel periodically check messages mailboxes of all processes and when happen your turn it will read your message and do things and write answer).

But message passing is now rare, mostly as I know, used paradigm of direct syscall, and async means, kernel release your process just after receive syscall, sync means, your process will be released only after syscall finished processing data.

In 8bit systems, cpu frequency where very low, sometimes fraction of bus speed and there where very few layers, basically userlevel program could directly access hardware. So even formally their behavior named synchronous, but in reality they where very fast in most cases, except understandable waits, like when Atari ANTIC access videoram when you also trying to do that.

Reliability issues in 8bit and in consoles solved very simple ways - first, most where capable to run only one program, and second, console software where extremely reliable, and expensive, much more reliable than business software, sometimes exceeds reliability of military software or mainframe system software.

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

#49

Post by amelius »

monkeybutton wrote: post #12
rayiner wrote: post #3

Typically CPU and GPU communicate over the PCI Express bus. (It’s not technically a bus but a point to point connection.) From the perspective of software running on the CPU, these days, that communication is typically in the form of memory-mapped IO. The GPU has registers and memory mapped into the CPU address space using PCIE. A write to a particular address generates a message on the PCIE bus that’s received by th…

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)
Post reply on HN