18 ms·
Open source RISC-V GPGPU
- akmittal 5y agoIt great to see RISC-V making a lot of progress. A lot of research is coming from China because of US bans, but hopefully this will be good for whole world.
- zucker42 5y agoWhich U.S. bans are you talking about? Is there anywhere I can read more about this?
- grawlinson 5y agoIt'll probably be something like this[0] and this[1]. I think there are more export restrictions than these two examples. [0]: https://en.wikipedia.org/wiki/Export_of_cryptography_from_the_United_States https://en.wikipedia.org/wiki/Export_of_cryptography_from_th... [1]: https://edition.cnn.com/2020/12/18/tech/smic-us-sanctions-intl-hnk/index.html https://edition.cnn.com/2020/12/18/tech/smic-us-sanctions-in...
- deleted 5y ago[deleted]
- bee_rider 5y agoWe occasionally ban companies that make HPC parts (Intel, NVIDIA, AMD) from selling to Chinese research centers, generally citing concerns that they could be used for weapons R&D (nuclear weapons simulation for example). 2015: https://spectrum.ieee.org/us-blacklisting-of-chinas-supercomputers-may-backfire https://spectrum.ieee.org/us-blacklisting-of-chinas-supercom... 2019: https://www.yahoo.com/now/trump-bans-more-chinese-tech-211409562.html https://www.yahoo.com/now/trump-bans-more-chinese-tech-21140... 2021: https://www.bloomberg.com/news/articles/2021-04-08/u-s-adds-seven-chinese-supercomputing-firms-to-export-ban-list https://www.bloomberg.com/news/articles/2021-04-08/u-s-adds-...
- monocasa 5y agoAnd then made it's own domestic supercomputing cluster that topped the charts when it came online.
- cyounkins 5y agoI hadn't heard about this: https://en.wikipedia.org/wiki/Sunway_TaihuLight https://en.wikipedia.org/wiki/Sunway_TaihuLight
- jpgvm 5y agoYeah. People forget that capital allocation works differently in China. You ban something they want, they simply make it themselves. I think banning their access to EUV lithography via the export ban of ASML machines is going to backfire horribly on the US. China has started allocating absolutely ridiculous amounts of money to hard science and have also changed the way they fund and prioritize projects to make them more commercially targeted. The end result of this is they now have a very large number of very smart scientists with nearly infinite funding being told to solve for the rest of the fab pipeline. ASML might retain their monopoly for a few more years but I think this move will eventually result in Chinese building even better machines and likely more practical and for less money - as is the Chinese way.
- sitkack 5y agoI think the bans are strategic in that we need a capable foe. By banning the right things, it ensures that they are at parity with us. A smart colonial power doesn't cut off access 100% but rations and controls access to resources. I can't wait to buy a refrigerator sized fab on alibaba for 25k in five years.
- phkahler 5y ago>> ASML might retain their monopoly for a few more years but I think this move will eventually result in Chinese building even better machines and likely more practical and for less money - as is the Chinese way. The complexity of ASML EUV light sources is incredible. China might just use a synchrotron for that. Sure there are issues to resolve but it seems like it has to be simpler in the end.
- throwaway81523 5y agoA GPGPU in an FPGA. Interesting, but 100x slower than a commodity AMD or NVidia card.
- raphlinus 5y agoThis is a research project from Georgia Tech. There's a homepage at [0] and a paper at [1]. It is specialized to run OpenCL, but with a bit of support for the graphics pipeline, mostly a texture fetch instruction. It appears to be fairly vanilla RISC-V overall, with a small number of additional instructions to support GPU. I'm very happy to see this kind of thing, as I think there's a lot of design space to explore, and it's great that some of that is happening in academic spaces. [0]: https://vortex.cc.gatech.edu/ https://vortex.cc.gatech.edu/ [1]: https://vortex.cc.gatech.edu/publications/vortex_micro21_final.pdf https://vortex.cc.gatech.edu/publications/vortex_micro21_fin...
- hajile 5y agoIntel's Larabee/Xeon Phi shows that there's a ton of potential here. Intel's big issue is that x86 is incredibly inefficient. Implementing the base instruction set is very difficult. Trying to speed it up at all starts drastically increasing core size. This means that the SIMD to overhead ratio is pretty high RISC-V excels at tiny implementations and power efficiency. The ratio of SIMD to the rest of the core should be much higher resulting in overall better efficiency. The final design (at a high level) seems somewhat similar to AMD's RDNA with a scalar ALU doing the flow control while a very wide SIMD does the bulk of the calculations.
- bullen 5y agoI think there is another project doing RISC-V GPU: https://www.pixilica.com/graphics https://www.pixilica.com/graphics Also the latest announced RVB-ICE should have a OpenGL ES 3+ capable Vivante GC8000UL GPU (did not manage to find documentation for this exact version but all GC8000 seem to): https://www.aliexpress.com/item/1005003395978459.html https://www.aliexpress.com/item/1005003395978459.html Disclaimer: Expensive if you don't know if it's vapourware and how the drivers and linux works!
- unsigner 5y agoWe should really have another word for “chip that runs OpenCL but has no rasterizer”. I see the title was edited to call it a “GPGPU”, or a “general-purpose GPU” but it’s not a thing; GPGPU was an early moniker for when people tried to do non-graphics work on GPUs many years ago, but it was a word for techniques, never for a specific type of hardware. Plus it feels to me that “general purpose” should be something more than a GPU, while this is strictly less.
- avianes 5y agoThat term is "SIMT architecture." Modern GPUs (or GPGPUs) are based on the SIMT programming model that requires an SIMT architecture
- zozbot234 5y ago"SIMT" is not an architecture, it's just a programming model that ultimately boils down to wide SIMD instructions with conditional execution. Add that to a barrel processor that can hide memory latency across a sizeable amount of hardware threads, and you've got the basics of a GPU "core".
- avianes 5y agoSIMT is a programming model, you are right. But in the literature the term "SIMT architecture" is used to describe architectures optimized for the SIMT programming model. Just search for "SIMT architecture" in google scholar or any other search engine dedicated to academic research, you will see that it's indeed a term used for this kind of architecture.
- nine_k 5y agoVector processors? Follow the early Cray nomenclature.
- eqvinox 5y agoVPU? With network processors being called NPU these days...
- pabs3 5y agoOpenCL seems to be kind of dying (eg Blender abandoned it), I wonder what is going to replace it.
- my123 5y agoCUDA is what ended up replacing it, or rather, OpenCL had always failed to make a dent over the long term. (with AMD ROCm being a CUDA API clone, without the PTX layer)
- DeathArrow 5y agoBut is there anyone using ROCm in production? Is ROCm up to par with CUDA?
- my123 5y agoNo. It isn’t up to par. But that’s AMD’s problem. No standard spec would solve a lack of software development investment of a hardware vendor, especially for a device as complex as a GPU. (meanwhile, on the Intel side, oneAPI looks to be very serviceable, but has a problem for now: where is the fast hardware to run it on?)
- chalcolithic 5y agoWow! Just add NaNboxing support (for JavaScript and possibly other dynamic languages) and it'll be a CPU I dreamed about.
- nynx 5y agoIt’s a GPU.
- chalcolithic 5y agoYes and I wanted a GPU-style CPU that could handle all the tasks in the system so no host CPU is necessary
- sitkack 5y agoFor those unfamiliar with Nan-boxing https://anniecherkaev.com/the-secret-life-of-nan https://anniecherkaev.com/the-secret-life-of-nan > One use is NaN-boxing, which is where you stick all the other non-floating point values in a language + their type information into the payload of NaNs. It’s a beautiful hack.
- ksec 5y agoNice, instead of trying to tackle the CPU space RISC-V should really be doing more work on GPGPU space with open source drivers. Current GPU are the biggest blackbox and mystery in modern computing.
- sitkack 5y agoRISC-V (with no vectors) was the base ISA to support the real goal of making Vector processors, it was supposed to be a short side quest. Much longer than expected but 1000% worth it. RVV (RISC-V Vector Extension) is the real coup and ultimately what the base ISA is there to support. https://youtu.be/V7fuE1yXUxk?t=104 https://youtu.be/V7fuE1yXUxk?t=104 https://www.youtube.com/watch?v=oTaOd8qr53U https://www.youtube.com/watch?v=oTaOd8qr53U GPUs might be complex beasts, ultimately it is lots of FMAs (Fused Multiply Add) that do most of our calculations. https://en.wikipedia.org/wiki/Multiply%E2%80%93accumulate_operation https://en.wikipedia.org/wiki/Multiply%E2%80%93accumulate_op...
- NotCamelCase 5y agoThis is an amazing project considering the scope of work required on both sides of the aisle -- HW and SW. I find choice of RISC-V pretty interesting for this use case as it's a fixed-size ISA and there is a significant amount of of auxiliary data usually passed from drivers to HW in typical GPU settings, even for GPGPU scenarios alone. If you look at one of their papers, it shows how they pass extra texture parameters via CSRs. I think this might come to be bottleneck and limiting factor in the design for future expansions. I am currently doing a similar work (>10x smaller in comparison) on a more limited feature set, so I am really curious how it'll turn out to be.
- deleted 5y ago[deleted]
- zozbot234 5y agoRISC-V is not "fixed size", the encoding has room for larger instructions (48-bit, 64-bit or more).
- NotCamelCase 5y agoI guess you're referring to variable-length encodings support? It's fixed as in they only implement RV32IMF subset here. Even then, code density may be source of bottlenecks along the way.
- R0b0t1 5y agoI've tried looking up the hardware they run on. Anyone have a price?
- detaro 5y agoExpensive. Exact parts aren't clear, but hundreds of dollars for a single chip and 5k+ for a devkit from a quick look? But running on FPGA is really only the testing stage for putting it in an ASIC if something like this wants to be competitive in any way.
- d_tr 5y agoThe two supported FPGA families are a blessing for this kind of project, since they have hardware floating-point units. Unfortunately they are quite expensive, like the Xilinx ones with this feature...
- zackmorris 5y agoI want the opposite of this - a multicore CPU that runs on GPU or FPGA. Vortex looks really cool, but if they jump over a level of abstraction by only offering an OpenCL interface instead of access to the underlying cores, then I'm afraid I'm not interested. I just need a chip that can run at least 256 streams of execution, each with their own local memory (virtualized to appear contiguous). This would initially be for running something like Docker, but would eventually run a concurrent version of something like GNU Octave (Matlab), or languages like Julia that at least make an attempt to self-parallelize. If there is a way to do this with Vortex, I'm all ears. I've gone into this at length in my previous comments. The problem is that everyone jumped on the SIMD bandwagon when what we really wanted was MIMD. SIMD limits us to a very narrow niche of problems to solve like neural nets and rasterization. But it prevents us from discovering the emergent behavior of large stochastic networks running stuff like genetic algorithms or the elegant/simple algorithms like ray tracing. That's not handwaving, I'm being very specific here in what I'm saying, and feel that this domination of the market by a handful of profit chasers like Nvidia has set computing back at least 20 years.
- klelatti 5y agoI may be missing something here but what do you mean by a CPU that runs on a GPU? Also how does "256 streams of execution, each with their own local memory (virtualized to appear contiguous)" differ in practice from one of the recent CPUs with lots of cores - e.g. AMD / AWS Arm?
- zackmorris 5y agoWell, this all goes back to when I was heavily into C++, assembly and blitters in the mid to late 90s when I was trying to run a shareware game business. I realized almost immediately that the real bottleneck in games is memory bandwidth, not processing power. This was right at the time that Quake III came out and everyone was trying to get a Voodoo2, I think it was? CPUs with FPUs had only gone mainstream maybe 5 years before that, and people were still arguing about Pentium vs 486 DX4. I was on Mac, but I don't think I even had a PowerPC yet. Then everyone got video cards and CPU performance stopped improving almost overnight. Sure, we got 200 MHz Pentium IIs, and then Intel jumped warp speed into 1 GHz and then 2GHz and then 3 GHz... but single threaded performance wasn't any faster, and even today is only maybe 3 times faster than it was then, per clock cycle. What really happened is that all of the chip area went to branch prediction and caching. When chips went from a few million transistors to a billion, I started asking why we couldn't just put dozens or hundreds of the old CPU cores on the new chips. As we all saw though, nobody listened or cared about that. So today we have behemoth chips that still choke when the web browser has a lot of tabs open. Chips today have maybe 8 or 16 cores, and that's great. But it's 2 orders of magnitude less than the transistor budget could support. Apple's M1 is loosely trying to do what I'm asking. But it's making the mistake of having all of these proprietary/dedicated cores for SIMD stuff. I would scrap all of that, and go with a 2D array of general-purpose cores, each with their own local memories, communicating using web metaphors like content-addressable memory. In fairness, I think the reason that real multicore CPUs never caught on, is that we didn't have the languages to utilize them. But today we have Matlab and various Lisps and higher order methods that auto-parallelize loops by treating them as transformations on arrays. All of our languages should have been auto-parallelized by now anyway. And not with SIMD optimization magic, I mean by statically analyzing code and converting it all first into higher order methods, then optimizing that intermediate code (I-code) so that the block copies are spread over multiple cores and memories. I can't remember the term for this, it's basically divide and conquer though, for example if fork/join scope was limited to a single function by the runtime. Scatter gather and map reduce are other terms for this. So right now we have to deal with promises and async and other patterns (I consider patterns an anti-pattern) when we could just be using an ordinary language like Javascript or C, auto-parallelized to run on 256+ cores with something like terabytes per second of bandwidth, running many thousands of times faster than computers today, for far less effort because it appears as a single thread of execution. Then OpenCL or OpenGL or anything else could run like any other library above that, for people that prefer a higher-level interface.