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

Tiny GPU: A minimal GPU implementation in Verilog

github.com

Post reply on HN
Print view View original

21–30 of 79 posts

Re: Tiny GPU: A minimal GPU implementation in Verilog

#21

Post by [deleted] »

JoachimS wrote: post #16
IshKebab wrote: post #12

Earlier quoted context omitted.

You might want to pick a more realistic goal! An FPGA capable of accelerating LLMs is going to cost at least tens of thousands, probably hundreds.

Depends heavily on what system it is supposed to provide acceleration for. If it is a MCU based on a simple ARM Cortex M0, M0+, M3 or RISC-V RV3I, then you could use an iCE40 or similar FPGA to provide a big acceleration by just using the DSPs and the big SPRAM. Basically add the custom compute operations and space that doesn't exist in the MCU, operations that would take several, many instructions to do in SW. Also,…

[deleted]

Re: Tiny GPU: A minimal GPU implementation in Verilog

#22

Post by JoachimS »

rjsw wrote: post #20
JoachimS wrote: post #16

Earlier quoted context omitted.

Depends heavily on what system it is supposed to provide acceleration for. If it is a MCU based on a simple ARM Cortex M0, M0+, M3 or RISC-V RV3I, then you could use an iCE40 or similar FPGA to provide a big acceleration by just using the DSPs and the big SPRAM. Basically add the custom compute operations and space that doesn't exist in the MCU, operations that would take several, many instructions to do in SW. Also,…

Or use one of the combined CPU+FPGA chips like the AMD/Xilinx Zynq, there are plenty of low cost dev boards for them.

Sure, a good example of a step between a really tiny system and 100k+ systems.

Re: Tiny GPU: A minimal GPU implementation in Verilog

#23

Post by pjc50 »

n4r9 wrote: post #6
tossandthrow wrote: post #4

Earlier quoted context omitted.

I think the establishing term is AIA, AI Accelerator.

That would ignore applications like crypto mining, which I'm guessing is still a biggie. What is it exactly that sets these units apart from CPUs? Something to do with the parallel nature of the hardware?

The distinction that seems to be important is the warp-thread architecture: multiple compute units sharing a single program counter, but instead of the SIMD abstraction they are presented as conceptually separate threads.

Also they tend to lack interrupt mechanisms and virtualization, at least at the programmer API level (usually NVIDIA systems have these but managed by the proprietary top level scheduler).

Re: Tiny GPU: A minimal GPU implementation in Verilog

#27

Post by gpderetta »

Lichtso wrote: post #9
Narishma wrote: post #3

Yet another "GPU" providing no graphics functionality. IMO theses should be called something else.

The first question is why is there a divide between CPUs and GPUs in the first place. Yes, the gap is closing and both categories are adding features of one another but there still is a significant divide. IMO it has to do with Amdahl's law [0]. In that sense CPUs should be called Latency-Optimizing-Processors (LOPs) and GPUs should be called Throughput-Optimizing-Processors (TOPs). More specifically [1] we could als…

The observation that graphic hardware and general purpose CPUs converge and diverge is not new: http://cva.stanford.edu/classes/cs99s/papers/myer-sutherland... .

But as you observe, we are stuck in a local optimum where GPUs are optimized for throughput and CPUs for latency sensitive work.

Re: Tiny GPU: A minimal GPU implementation in Verilog

#29

Post by novaRom »

I did something similar many years ago in VHDL. There was a site called opencores for different open source HDL projects. I wonder if is there any good HPC level large scale distributed HDL simulator exists today? It makes sense to utilize modern GPUs for making RTL level simulations.

Re: Tiny GPU: A minimal GPU implementation in Verilog

#30

Post by Jasper_ »

> Since threads are processed in parallel, tiny-gpu assumes that all threads "converge" to the same program counter after each instruction - which is a naive assumption for the sake of simplicity.

> In real GPUs, individual threads can branch to different PCs, causing branch divergence where a group of threads threads initially being processed together has to split out into separate execution.

Whoops. Maybe this person should try programming for a GPU before attempting to build one out of silicon.

Not to mention the whole SIMD that... isn't.

(This is the same person who stapled together other people's circuits to blink an LED and claimed to have built a CPU)

Post reply on HN