8 ms·
RV64X: A Free, open-source GPU for RISC-V
- yjftsjthsd-h 6y agoI'm not clear: Is this proposing that we make risc-v CPUs that also perform the work of a GPU, or is this a way to make a risc-v GPU (standalone)?
- oregontechninja 6y agoIt looks like you could have C+GPU cores. I bet you could still split the gpu portion out into its own separate thing if you wished.
- Zenst 6y agoSomehow this all reminded me of https://en.wikipedia.org/wiki/Larrabee_(microarchitecture) https://en.wikipedia.org/wiki/Larrabee_(microarchitecture) It's the whole - full core on a GPU aspect, which probably isn't a bad idea for a few reasons, could even offload much of the driver onto it and with that, make platform drivers much more manageable...maybe.
- sitkack 6y agoFrom a high enough level they are architecturally similar. But these x86 cores don't scale _down_ to 500-1000 logic elements per core. This is an architectural level, not a microarchitectual level design (yet).
- xiphias2 6y agoSIMD instructions were a mistake in CPU instruction set design. Vector instructions have register size independent code which makes vector programming from CPUs much more approachable and binary compatible.
- zeckalpha 6y agoVector instructions are a type of SIMD
- throwaway81523 6y agoI think SIMD referred to Intel SSE*/AVX/etc., where the vectors are of fixed length. That meant new instructions had to keep getting introduced for new sizes of vectors.
- zeckalpha 6y agoSIMD as a term predates those Intel instructions by 30 years.
- phkahler 6y agoAVX style vectors IMHO should have been used for all those vec3 and vec4 operations that are used in graphics applications. They should not have been used for general parallelization of loops - although they have had some success in that. GPUs have geometrically relevant vectors as basic data types. I wish language designers would realize the value in that, but they are too concerned with abstraction. RISC-V vectors are meant for the abstract general parallel concepts, but could also help with graphics code. There really seems to be a disconnect around which types of vectors are good for which uses.
- incrudible 6y ago> AVX style vectors IMHO should have been used for all those vec3 and vec4 operations that are used in graphics applications. That is the naive application of SIMD, which many have attempted. It does not lead to a meaningful speedup. To get a good speedup from SIMD, you need SOA or AOSOA layout. Ergonomically this is already similar to vector instructions.
- phkahler 6y ago>> That is the naive application of SIMD, which many have attempted. It does not lead to a meaningful speedup. How can it not provide a meaningful speedup? If I have 3- or 4-element vectors a,b, and c, with scalars u,v. I want to compute: a = ub + vc; These should be first class data types, passed by value, and that line of code should take 2 SIMD instructions at most. That should also not require a fancy vectorizing compiler to do the analysis to find the parallelism because the data types map directly to the ISA vector registers. GPUs have this, the benefit should be very real.
- hajile 6y agoYou’d have two separate sets of cores. The general purpose cores will have all the usual extensive you’d expect. Meanwhile, the GPU cores will be simple cores with huge vector engines. This honestly seems somewhat similar to RDNA at a high level where you have a large SIMD unit with a scalar cores for branching and one-off calculations. The big payoff is cohesiveness. Your RISC-V GPU shares the same memory model as your CPU. This should have a payoff in easy integration. Likewise, sharing a good permission model can probably help with all those GPU exploits in third-party code (like webGL).
- avocactus57 6y agoIn terms of similarity with RDNA, you mean large cache memory which can store bigger matrixes?
- xiphias2 6y agoThe article doesn't write about mixed precision machine learning. Will it be available? I would really love to see a RISC-V laptop using vector extensions beating the Apple M1 core in everything (though I know that it will take a lot of time to get to 5nm process node).
- ece 6y agoIt mentions support for INT8 for ML/AI. FP16 and BF16 support isn't explicitly mentioned, but it does support 8/16/32-bit fixed/float scalars and vectors, so it could be added later.
- xiphias2 6y agoSo the answer is no :( Anyways I expect RISC-V to appear in Chinese mobile phones before laptops as the main unit. It would be fun to run Android on this RV64X architecture....I guess that's the goal.
- ece 6y agoI think a FP16 or BF16 ALU could be added sooner rather than later, but getting something equivalent to the performance of say a Nvidia 1050 or 1080 (first consumer cards to have FP16 and INT8 from Nvidia I think) would take a couple of iterations.. Cheap phones running Android would be a great start for RV64/RV64X though.
- girvo 6y agoI wonder what company would put in the hundreds of millions to design a RISC-V processor on 5nm? I’m not being facetious — I wonder if there will be a future where we see that! It would be super exciting.
- samus 6y agoChinese companies will take that step for sure once China manages to bring domestic advanced nodes into production. It doesn't make sense to have domestic semiconductor and then use a proprietary ISA like ARM or x86(_64) again.
- meekrohprocess 6y agoVery cool. It's interesting that they are planning to start with Vulkan support, followed by OpenGL/DX/etc. I guess it makes sense; the RISC-V crowd might possibly skew towards early adoption over backwards-compatibility. It would be really cool to see some implementations from places like SiFive/GigaDevice/etc. Imagine how easy driver support could be if everyone used and contributed to the same open IPs...
- moonchild 6y agoThey can also take advantage of zink to implement opengl, at least on platforms that support mesa; and use wine's implementations of direct3d. I expect that, in the future, gl and d3d will be implemented entirely on top of vulkan, and thus be more portable and make it easier to make GPUs and graphics drivers.
- mrec 6y ago> I expect that, in the future, gl and d3d will be implemented entirely on top of vulkan I'm not sure whether you're talking about the "official" Microsoft D3D libs here, but I very much doubt that'll ever happen. They don't like dependencies they can't control. The Excel team used to maintain their own compiler because they didn't want to be dependent on the Visual C++ team who worked in the same building. Same with Apple and Metal.
- pjmlp 6y agoThe GP probably means the Wine implementation. Vulkan is not even supported on UWP or Win32 sandboxes, the ICD mechanism its drivers use from the OpenGL days is only allowed in classical Win32 mode.
- asiachick 6y agoIf they wanted to provide OpenGL ES support (all mobile devices) they could just use ANGLE which will provide OpenGL ES support on top of vulkan https://github.com/google/angle https://github.com/google/angle
- userbinator 6y agoPrevous attempts at taking a regular CPU architecture and turning it into a GPU haven't worked so well --- it's what Intel attempted many years ago --- so I'm not too optimistic about how this will turn out. Then again, the boring and uniform nature of RISC-V may be more suitable to mass parallelisation in a GPU than as a CPU. The name is slightly reminiscent of https://en.wikipedia.org/wiki/File:RIVA_TNT2_VANTA_GPU.jpg https://en.wikipedia.org/wiki/File:RIVA_TNT2_VANTA_GPU.jpg
- zeckalpha 6y agoThis doesn’t quite seem like that as the implementation of the instructions isn’t yet specified. Even if it is integrated, it can use dedicated VRAM and not have to use the CPU’s ALU.
- anp 6y agoFWIW, NVIDIA have been adopting RISC-V as the internal ISA for their GPUs: https://riscv.org/wp-content/uploads/2017/05/Tue1345pm-NVIDIA-Sijstermans.pdf https://riscv.org/wp-content/uploads/2017/05/Tue1345pm-NVIDI.... It’s definitely a different architectural approach than described in OP though.
- deleted 6y ago[deleted]
- yaantc 6y agoNo, it's not the GPU ISA. Complex chips tend to embed management cores, for example to handle power management or various configuration operations across the chip. NVidia used a proprietary ISA (Falcon) for such cores, and moved to RISC V. But this is independent from the GPU ISA itself, which remains NVidia proprietary. So in the end, in their embedded SoC you can find (at least) 3 ISAs: ARM for CPU, NVidia proprietary for the GPU, and RISC V for NVidia management cores. And it's likely there are more, for example for audio DSP and other IPs embedded programmable units.
- djmips 6y agoIt's not the internal ISA of their GPU but of a CPU they use in their designs.
- nynx 6y agoI'd like to see more MIMD or MISD architecture exploration. 2048 core basic riscv processors anyone?
- villgax 6y agoWish GPUs came with upgradable RAM slots like SODIMMs in laptops
- userbinator 6y agoThey used to, some of them in the 90s had expandable VRAM: https://upload.wikimedia.org/wikipedia/commons/f/f8/DIAMONDSTEALTH3D2000-top.JPG https://upload.wikimedia.org/wikipedia/commons/f/f8/DIAMONDS... https://upload.wikimedia.org/wikipedia/commons/6/6b/Matrox_Millennium_G200_SGRAM_REV_A_1998.jpg https://upload.wikimedia.org/wikipedia/commons/6/6b/Matrox_M... http://vgamuseum.info/images/palcal/profi/665_elsa_xl_top_hq.jpg http://vgamuseum.info/images/palcal/profi/665_elsa_xl_top_hq...
- dathinab 6y agoAfter apple setting a precedence with packaged RAM I fear in the future upgradeable RAM might become rare on everything but high end workstations. I hope this will not happen, but especially certain laptop companies always wanted to have non upgradeable RAM and only stepped back because users where to unhappy about it. But now they will point to Apple and tell you that's necessary for fast low power laptops with long battery live.
- pjmlp 6y agoWhat precedence? Do you think we could extend the memory of most 8 and 16 bit home computers? If we wanted to upgrade our computers, beyond plugging stuff on the external expansion port, we had to buy a new model. The PC was the precedence, and only due to IBM losing control of it. Now with laptops and tablets becoming the standard consumer computers, we are back into the 80-90's computer form models, just instead of plugging them into the TV, the screen comes along for the ride. And actually it was great, because it meant developers had to learn to extract all the juice of the computers people had, instead of expecting us to spend money upgrading.
- villgax 6y agoThe screen point is quite valid, a decade of 1080p everywhere just went by on laptops
- phendrenad2 6y agoIt'll be interesting to see if this goes the Larrabee route (a flat array of CPUs which share everything) or the traditional GPU route (multiple levels of shared resources).
- airocker 6y agoNaive question but can you not target just one use case: ml, graphics etc to begin with? Something like tpu? Why does it need support every use case of a gpu in the initial design?
- samus 6y agoMultiple reasons might apply: - Focusing on one use case might make it difficult to generalize the design later. Lessons learned might not carry over, and the platform will get anchored into particular design choices. This only gets worse the more the solution gets deployed. - Having a product that can do both makes it simpler to do applications that combine multiple computational loads. Else, the data has to be transferred to another device. This seems unattractive since graphics, ML and massively parallel scientific computations are more similar to each other than to what CPUs are used for. - Development budget gets fragmented, which is a disadvantage since the different use cases might not correspond to markets that are large enough to support each product. - One of the platforms might just die off. Users that use both would be stuck in between and would have to find a solution, and most likely it will be NVidia/AMD again.