4 ms·

By the way, let me ask a couple of stupid questions about GPUs: Do RISCV-style free GPU projects exist or would they be unviable because of some specific prope

By the way, let me ask a couple of stupid questions about GPUs: Do RISCV-style free GPU projects exist or would they be unviable because of some specific properties of the GPU nature? Why even bother implementing actual rendering in hardware when you can just implement fast general-purpose calculations and use them to accelerate software rendering? CPU-based software rendering did pretty well for the first versions of Unreal and Half-Life, I imagine it could also make sense today if accelerated with something like CUDA.

als0 5y ago
Intel had a project called Larrabee where they put a lot of small but general purpose x86 cores on a GPU card. I've heard that it was a flop because certain GPU operations weren't fast enough on those little cores - you still needed some hardware acceleration. It wasn't a total failure though, Intel managed to pivot it from a GPU project into a moderately successful datacenter product, the Xeon Phi. Of course, time has passed and maybe it's worth revisiting the idea again. The biggest barrier for anyone making a purchasable GPU is the current patent minefield dominated by Nvidia, Imagination, and others.
Arelius 5y ago
> Do RISCV-style free GPU projects exist or would they be unviable because of some specific properties of the GPU nature? Not that I know of, I don't think they are specifically unviable, but even RiscV is relatively new and in it's infancy, and CPU's in a sense are a subset of GPUs (modern GPUs have pretty comprehensive computation ISAs) and additionally, there exists a much more viable market for low-end CPUs that doesn't exist for GPUs in microcontrollers. > Why even bother implementing actual rendering in hardware when you can just implement fast general-purpose calculations and use them to accelerate software rendering? The answer is sort of a mixture of A. That's what we have and B. because custom hardware is very hard to beat. Do read up on Larrabee[1] So, GPU's have been converging on being more and more programmable, there are a few parts that are still much faster done in silicon, and very widely used, specifically rasterization (Though, software can be a win with e.g. micropolygons, See UE4's Nanite), Texture Sampling, and we're starting to see BVH traversal in the case of ray-tracing. And rasterization specifically is the one that pretty much dictates the structure of the render pipeline, with vertex/fragment shaders, etc and is broadly what makes it's hard to fit it into a "general-purpose" pipeline with specialized instructions. And just keep in mind, Cuda is basically just a compute shader, and a compute shader itself is basically just a fragment shader without rasterization stuck on the front and without render target blending stuck on the end, and that's also specifically the history of how we got to general-purpose GPU computation ala Cuda. [1]https://brightsideofnews.com/an-inconvenient-truth-intel-larrabee-story-revealed/ https://brightsideofnews.com/an-inconvenient-truth-intel-lar...
- deleted 5y ago
  [deleted]
- deleted 5y ago
  [deleted]
peepoodo 5y ago
Unviable, GPU shines at what they do because they hide memory latency. They do that by having N threads in flight for M computes unit with N > M by a sufficiently large factor (for instance N = 5M or more like 10M ...). In flight means all states including all register values are save inside the GPU usually in its cache. So at any point in time among the N threads they are M that are ready to execute (ie not waiting on memory) and those do execute. Anytime a thread need to lookup memory, like accessing a texture for instance, the memory lookup is schedule and the thread is put to sleep but its states stays in the GPU. But overall they are always M threads not waiting. This is why if you do performance analysis on GPU in some basic cases the memory lookup operation looks like they are free (ie takes no time). On the CPU when you context switch between thread the kernel save the CPU states (all register values and ancillary states) to main memory. Which means that switching thread on a CPU core means writing current thread context to memory and reading next thread context from memory. So it even worsen the memory latency issues. If you design a CPU capable of holding many threads context within silicon (on die memory) you might get closer to a GPU. But you do not get much from doing so for CPU workload. Also at which point does your design is more a GPU then a CPU ?
- zozbot234 5y ago
  > If you design a CPU capable of holding many threads context within silicon (on die memory) you might get closer to a GPU. From a pure programming model POV, this is just SMT which RISC-V supports quite handily - the native "core"-like abstraction is specifically pointed out as a 'hardware thread', "hart" for short. Now, clearly GPGPU adds some features that are not encompassed by this model, such as vartious sorts of "scratchpads"/"memories" often with restricted addressing. But the general feature is accounted for.
lmeyerov 5y ago
sort of: -- risc-v was created to support data parallel / vector codes, even though the open thing is what took off, and all sorts of cool stuff being built (not an expert but def a fan!) -- ... but the reason nvidia >> amd, intel, google tpu in practice is the compounding ecosystem investment over the years: compilers, libs, and now, even rest of the chip/network . Ex: Intel & AMD & IBM tried to push OpenCL for example soon after CUDA, yet ~no one runs AI stuff that way, the ecosystem just isn't there in practice.
Const-me 5y ago
> when you can just implement fast general-purpose calculations and use them to accelerate software rendering? They are optimizing for different things. CPUs are optimized for single-threaded performance, i.e. lower latency. They only have a few cores, but these cores are spending billions of transistors implementing cache hierarchy, reordering instructions, predicting branches with neural networks, predicting indirect branches, prefetching data from RAM, executing instructions speculatively with the ability to rollback, etc. All these things are very complicated, but they do help with latency. GPUs don't care about latency. They only care about throughput on massively parallel workloads. For all these cases when a CPU needs to do something smart to minimize latency, GPU cores simply switch to another thread to do something else in the meantime. That's how they have count of cores measured in hundreds if not thousands. One more thing, high-end CPUs run at ~4GHz to minimize latency, GPUs at 1-2GHz to maximize power efficiency. The result is about an order of magnitude difference in throughput. Ryzen 9 5950X peaks at 1.8 TFlops FP32, yet similarly priced Radeon RX 6800 XT peaks at 17 TFlops.
- qwerty456127 5y ago
  I didn't mean using a CPU for rendering. I meant building a GPU without graphics-specific functions. Imagine a 3D graphics driver/engine which takes a normal GPU of today and uses its CUDA/OpenCL functions to calculate everything it needs to render graphics without using the GPU's OpenGL/Direct3D functions. I wonder if such an engine could be viable and if we could design a GPU which would have no actual graphics-specific functions (only implementing e.g OpenCL) and still empower the graphics engine in a reasonable degree.
  - photojosh 5y ago
    IANA GPU expert, but AFAIK modern GPUs are pretty much are that already: massively parallel general-purpose CPUs. It's the GPU driver layer that takes either the compute or graphics instructions and converts them into the particular instruction set/microcode used by the "CPUs" in the GPU. In a sense that code is "recompiled" (but may be cached) every time a "program" is run. [0] is a post that talks about reverse-engineering the interface to the GPU in the Apple M1, a lot of which consists of what I've just described, so reading that series might help understand. [0]: https://rosenzweig.io/blog/asahi-gpu-part-1.html https://rosenzweig.io/blog/asahi-gpu-part-1.html
dwrodri 5y ago
Here is one: https://vortex.cc.gatech.edu/ https://vortex.cc.gatech.edu/

als0 5y ago

Intel had a project called Larrabee where they put a lot of small but general purpose x86 cores on a GPU card. I've heard that it was a flop because certain GPU operations weren't fast enough on those little cores - you still needed some hardware acceleration. It wasn't a total failure though, Intel managed to pivot it from a GPU project into a moderately successful datacenter product, the Xeon Phi. Of course, time has passed and maybe it's worth revisiting the idea again. The biggest barrier for anyone making a purchasable GPU is the current patent minefield dominated by Nvidia, Imagination, and others.

Arelius 5y ago

> Do RISCV-style free GPU projects exist or would they be unviable because of some specific properties of the GPU nature? Not that I know of, I don't think they are specifically unviable, but even RiscV is relatively new and in it's infancy, and CPU's in a sense are a subset of GPUs (modern GPUs have pretty comprehensive computation ISAs) and additionally, there exists a much more viable market for low-end CPUs that doesn't exist for GPUs in microcontrollers. > Why even bother implementing actual rendering in hardware when you can just implement fast general-purpose calculations and use them to accelerate software rendering? The answer is sort of a mixture of A. That's what we have and B. because custom hardware is very hard to beat. Do read up on Larrabee[1] So, GPU's have been converging on being more and more programmable, there are a few parts that are still much faster done in silicon, and very widely used, specifically rasterization (Though, software can be a win with e.g. micropolygons, See UE4's Nanite), Texture Sampling, and we're starting to see BVH traversal in the case of ray-tracing. And rasterization specifically is the one that pretty much dictates the structure of the render pipeline, with vertex/fragment shaders, etc and is broadly what makes it's hard to fit it into a "general-purpose" pipeline with specialized instructions. And just keep in mind, Cuda is basically just a compute shader, and a compute shader itself is basically just a fragment shader without rasterization stuck on the front and without render target blending stuck on the end, and that's also specifically the history of how we got to general-purpose GPU computation ala Cuda. [1]https://brightsideofnews.com/an-inconvenient-truth-intel-larrabee-story-revealed/ https://brightsideofnews.com/an-inconvenient-truth-intel-lar...

deleted 5y ago
[deleted]
deleted 5y ago
[deleted]

peepoodo 5y ago

Unviable, GPU shines at what they do because they hide memory latency. They do that by having N threads in flight for M computes unit with N > M by a sufficiently large factor (for instance N = 5M or more like 10M ...). In flight means all states including all register values are save inside the GPU usually in its cache. So at any point in time among the N threads they are M that are ready to execute (ie not waiting on memory) and those do execute. Anytime a thread need to lookup memory, like accessing a texture for instance, the memory lookup is schedule and the thread is put to sleep but its states stays in the GPU. But overall they are always M threads not waiting. This is why if you do performance analysis on GPU in some basic cases the memory lookup operation looks like they are free (ie takes no time). On the CPU when you context switch between thread the kernel save the CPU states (all register values and ancillary states) to main memory. Which means that switching thread on a CPU core means writing current thread context to memory and reading next thread context from memory. So it even worsen the memory latency issues. If you design a CPU capable of holding many threads context within silicon (on die memory) you might get closer to a GPU. But you do not get much from doing so for CPU workload. Also at which point does your design is more a GPU then a CPU ?

zozbot234 5y ago
> If you design a CPU capable of holding many threads context within silicon (on die memory) you might get closer to a GPU. From a pure programming model POV, this is just SMT which RISC-V supports quite handily - the native "core"-like abstraction is specifically pointed out as a 'hardware thread', "hart" for short. Now, clearly GPGPU adds some features that are not encompassed by this model, such as vartious sorts of "scratchpads"/"memories" often with restricted addressing. But the general feature is accounted for.

lmeyerov 5y ago

sort of: -- risc-v was created to support data parallel / vector codes, even though the open thing is what took off, and all sorts of cool stuff being built (not an expert but def a fan!) -- ... but the reason nvidia >> amd, intel, google tpu in practice is the compounding ecosystem investment over the years: compilers, libs, and now, even rest of the chip/network . Ex: Intel & AMD & IBM tried to push OpenCL for example soon after CUDA, yet ~no one runs AI stuff that way, the ecosystem just isn't there in practice.

Const-me 5y ago

> when you can just implement fast general-purpose calculations and use them to accelerate software rendering? They are optimizing for different things. CPUs are optimized for single-threaded performance, i.e. lower latency. They only have a few cores, but these cores are spending billions of transistors implementing cache hierarchy, reordering instructions, predicting branches with neural networks, predicting indirect branches, prefetching data from RAM, executing instructions speculatively with the ability to rollback, etc. All these things are very complicated, but they do help with latency. GPUs don't care about latency. They only care about throughput on massively parallel workloads. For all these cases when a CPU needs to do something smart to minimize latency, GPU cores simply switch to another thread to do something else in the meantime. That's how they have count of cores measured in hundreds if not thousands. One more thing, high-end CPUs run at ~4GHz to minimize latency, GPUs at 1-2GHz to maximize power efficiency. The result is about an order of magnitude difference in throughput. Ryzen 9 5950X peaks at 1.8 TFlops FP32, yet similarly priced Radeon RX 6800 XT peaks at 17 TFlops.

qwerty456127 5y ago
I didn't mean using a CPU for rendering. I meant building a GPU without graphics-specific functions. Imagine a 3D graphics driver/engine which takes a normal GPU of today and uses its CUDA/OpenCL functions to calculate everything it needs to render graphics without using the GPU's OpenGL/Direct3D functions. I wonder if such an engine could be viable and if we could design a GPU which would have no actual graphics-specific functions (only implementing e.g OpenCL) and still empower the graphics engine in a reasonable degree.
- photojosh 5y ago
  IANA GPU expert, but AFAIK modern GPUs are pretty much are that already: massively parallel general-purpose CPUs. It's the GPU driver layer that takes either the compute or graphics instructions and converts them into the particular instruction set/microcode used by the "CPUs" in the GPU. In a sense that code is "recompiled" (but may be cached) every time a "program" is run. [0] is a post that talks about reverse-engineering the interface to the GPU in the Apple M1, a lot of which consists of what I've just described, so reading that series might help understand. [0]: https://rosenzweig.io/blog/asahi-gpu-part-1.html https://rosenzweig.io/blog/asahi-gpu-part-1.html

dwrodri 5y ago

Here is one: https://vortex.cc.gatech.edu/ https://vortex.cc.gatech.edu/