Live data from Hacker News

Libre-SoC 180nm Power ISA v3.0 ASIC Submitted to IMEC MPW

openpowerfoundation.org

61–68 of 68 posts

Re: Libre-SoC 180nm Power ISA v3.0 ASIC Submitted to IMEC MPW

#61

I can't wait to see the Vulkan implementation for this. Apparently it should be somewhat hardware-accelerated due to the vector capabilities of the core?

yes, so the "normal" way that GPUs work is: the architecture and the ISA are so staggeringly optimised they're completely incompatible and incapable of running standard (general-purpose) workloads. no MMU, vast wide SIMD engines, massive numbers of parallel memory interfaces that run really slowly but can handle (when added up) vast bandwidth far in excess of "normal" processor memory, and so on.

on top of that, because it's an entirely separate processor, to get it to do anything you actually have to have a Remote Procedure Call system, operating over Shared Memory!

oink.

so the process for running a GPU shader binary is as follows:

step 1: fire up a compiler (in userspace) step 2: compiler takes the shader IR and turns it into GPU assembler step 3: the userspace program (game, blender, whatever) triggers the linux kernel (or windows kernel) to upload that GPU binary to the GPU step 4: the kernel copies that GPU binary over Shared Memory Bus (usually PCIe) step 5: now we unwind back to userspace (with a context-switch) and want to actually run something (OpenGL call) step 6: the OpenGL call (or Vulkan) gets some function call parameters and some data step 7: the userspace library (MESA) "packs" (marshalls) those function call parameters into serialised data step 8: the userspace library triggers the linux (windows) kernel to "upload" the serialised function call parameters - again over Shared Memory Bus step 9: the kernel waits for that to happen step 10: the userspace proceeds (after a context-switch) and waits for notification that the function call has completed...

... i'm not going to bother filling in the rest of the details, you get the general idea that this is completely insane and goes a long way towards explaining why GPU Cards are so expensive and why it takes YEARS to reverse-engineer GPU drivers.

in the Libre-SOC architecture - which is termed a "Hybrid" one, the following happens:

step 1: the compiler is fired up (in userspace, just like above) step 2: compiler takes the shader IR and turns it into *NATIVE* (Power ISA with Cray-style Vectors and some custom opcodes) assembler step 3: userspace program JIT EXECUTES THAT BINARY NATIVELY RIGHT THERE RIGHT THEN

done.

did you see any kernel context-switches in that simple 3-step process? that's because there aren't any needed.

now, the thing is - answering your question a bit more - that "just having vector capabilities" is nowhere near enough. the lesson has been learned from Nyuzi, Larrabee, and others: if you simply create a high-performance general-purpoes Vector ISA, you have successfully created something that absolutely sucks at GPU workloads: about TWENTY FIVE PERCENT (one quarter) of the capability of a modern GPU for the same power consumption.

therefore, you need to add SIN, COS, ATAN2, LOG2, and other opcodes, but you need to add them with "reduced accuracy" (like, only 12 bit or so) because that's all that's needed for 3D.

you need to add Texture caches, and Texture interpolation opcodes (takes 4 pixels @ 00 01 10 11 square coordinates, plus two FP XY numbers between 0.0 and 1.0, and interpolates the pixels in 2D).

you need to add YUV2RGB and other pixel-format-conversion opcodes that are in the Vulkan Specification...

and many more.

but, we first had to actually, like, y'know, have a core that can actually execute instructions at all? :) and that's what this first Test ASIC is: a first step.

Re: Libre-SoC 180nm Power ISA v3.0 ASIC Submitted to IMEC MPW

#62
post #34

Interesting as this is, I'll look forward to version two, to see how the vector processing works.

you can get a pretty good idea right now, the simulator is functional and the unit tests include explanations in english:

https://git.libre-soc.org/?p=openpower-isa.git;a=tree;f=src/...

i'm currently in the middle of a rabbit-hole exploration of being able to do in-place RADIX-2 FFT, DCT and DFT butterflys, the target is a general purpose function to cover each of those, in around 25 Vector instructions.

not 2,000 optimised loop-unrolled instructions specifically crafted for RADIX-8, another for RADIX-16, another for RADIX-32 ..... RADIX-4096 (as is the case in ffmpeg): 25 instructions FOR ANY 2^N FFT.

btw if you're interested in "real-world" SVP64 Vector Assembler we have the beginnings of an ffmpeg MP3 CODEC inner loop:

https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=medi...

that's under 100 instructions, more than 4x less assembler for the same job in PPC64. and 6.5 times less assembler than ffmpeg's optimised x86 apply_window_float.S

you will no doubt be aware of the huge power savings that brings due to reduced L1 cache usage.

Re: Libre-SoC 180nm Power ISA v3.0 ASIC Submitted to IMEC MPW

#63
post #61

I can't wait to see the Vulkan implementation for this. Apparently it should be somewhat hardware-accelerated due to the vector capabilities of the core?

yes, so the "normal" way that GPUs work is: the architecture and the ISA are so staggeringly optimised they're completely incompatible and incapable of running standard (general-purpose) workloads. no MMU, vast wide SIMD engines, massive numbers of parallel memory interfaces that run really slowly but can handle (when added up) vast bandwidth far in excess of "normal" processor memory, and so on. on top of that, beca…

Awesome job. I tried to make a simple GPU in chisel w/ hardfloat. I also came to the conclusion that Larrabee was a joke and dedicated triangle interpolation hardware was necessary, but I didn't consider the half-float(?) or caches or other additions you had to make.

Re: Libre-SoC 180nm Power ISA v3.0 ASIC Submitted to IMEC MPW

#64
post #61

Earlier quoted context omitted.

yes, so the "normal" way that GPUs work is: the architecture and the ISA are so staggeringly optimised they're completely incompatible and incapable of running standard (general-purpose) workloads. no MMU, vast wide SIMD engines, massive numbers of parallel memory interfaces that run really slowly but can handle (when added up) vast bandwidth far in excess of "normal" processor memory, and so on. on top of that, beca…

Awesome job. I tried to make a simple GPU in chisel w/ hardfloat. I also came to the conclusion that Larrabee was a joke and dedicated triangle interpolation hardware was necessary, but I didn't consider the half-float(?) or caches or other additions you had to make.

thx phndrenad2. funny i just searched "chisel gpu" and found two: https://github.com/jbush001/ChiselGPU https://github.com/Chlorophytus/broccoli

half-float we'd like to do by using a dynamic SIMD-aware 64-bit ALU that has auto-partitioning. we do however already have an actual FP16 implementation https://git.libre-soc.org/?p=ieee754fpu.git;a=tree;f=src/iee...

or more to the point, one that is compile-time configureable with one parameter (bit-width), so the same HDL does FP16, FP32 and FP64. i'd like to make that dynmaically-SIMD-configureable but it'll take some base work in nmigen to do without massive code-explosions.

Re: Libre-SoC 180nm Power ISA v3.0 ASIC Submitted to IMEC MPW

#65

A fully open source chip, from Verilog to Fabrication is cool! It may be 180nm (1999-era technology), but that's still hugely important. The world of semiconductor design is incredibly closed source and secretive.

we use nmigen (python-based OO HDL) which through yosys generates verilog as an automatic step.

180nm is still by far and above the world's most heavily-used geometry, because the price-performance (bang per buck, however you want to put it) is so extremely high.

an 8in wafer is USD 600 and that's extremely low. any power MOSFET, power transistor, diode or other high current semiconductor you absolutely don't want small "things" (detailed tiny tracks) you want MASSIVE ones.

why on earth would you waste money on tiny features, it's like using the latest 0.15mm 3D printing nozzles to 3D print a massive 300x300x300 mm cube that's going to be used for nothing more than a foot-stool. you want a 1.2mm nozzle for that!

then any processor below 300 mhz, you can get away with 180nm. need only an 8 mhz 8-bit or 4-bit washing machine or microwave processor, or something to go in a cheap digital watch? 180nm is your best bet: you'll get tens of thousands of a 28nm 8in wafer would be about... 10x that cost, you'd end up with exactly the same transistor (or 8 mhz 8-bit processor), why would you pay more money for what you don't need?

btw the real reason why there's a chip shortage: the Automotive industry, who are cheap bar-stewards, wanted even lower than $600 per 8in wafer so they went with 360nm and cruder geometry. that's equipment that's even older than the 1990s, like 40+ years in some cases.

so then the stupidity hit, and they stopped ordering. then 18 months later they phone up these old Foundries and say, "ok, we're ready to start ordering again". and the Foundries say, "oh, we switched off the equipment, and it cooled down and got damaged (just like that massive Electric plant in S. Australia that was de-commissioned, the concrete cracked when they switched it off, and it's completely unsafe to start up again). you were our only customer for the past 30 years, so we scrapped it all. you'll have to now compete with the consumer-grade smaller geometry Fabs like everyone else".

which is something that none of the Automotive companies have told their Governments, because then they can't go crying "boo hoo hoo, we can't make chips any more at the price that we demand, waaa, waaaa, i wannnt myyy monneeeeey"

and now of course they can't use the old masks, because those were designed for 360nm and cruder geometries, they have to redesign the entire ASIC for 180nm and that's why you can't now get onto 180nm and other MPW Programmes because the frickin Automotive Industry has jammed them all to hell.

Re: Libre-SoC 180nm Power ISA v3.0 ASIC Submitted to IMEC MPW

#66
post #7

What does this mean to noobs like me?

Here are a few implications: * In a few years (maybe 5?), it might be possible to build a computer that you can trust has no intentional back doors in the CPU, but is modern enough to run software from within the last decade. * If this catches on, and is used by enough people, economies of scale might kick in, and bring costs for advanced custom chips down by an order of magnitude (if the cpu is small enough, and if…

Is the chip in question a complete CPU?

Re: Libre-SoC 180nm Power ISA v3.0 ASIC Submitted to IMEC MPW

#67

Earlier quoted context omitted.

Here are a few implications: * In a few years (maybe 5?), it might be possible to build a computer that you can trust has no intentional back doors in the CPU, but is modern enough to run software from within the last decade. * If this catches on, and is used by enough people, economies of scale might kick in, and bring costs for advanced custom chips down by an order of magnitude (if the cpu is small enough, and if…

Is the chip in question a complete CPU?

yes. it is however a test ASIC. therefore it has no on-board boot ROM, and has to have programs uploaded to it over JTAG.

Re: Libre-SoC 180nm Power ISA v3.0 ASIC Submitted to IMEC MPW

#68
post #67

Earlier quoted context omitted.

Is the chip in question a complete CPU?

yes. it is however a test ASIC. therefore it has no on-board boot ROM, and has to have programs uploaded to it over JTAG.

Is it 32 bit or 64 bit?
Post reply on HN