30 ms·

A similar approach to demonstrate a GPU would be great. Any recommendations? Well, let me rephrase. A GPU these days has two distinct features, graphics-proces

A similar approach to demonstrate a GPU would be great. Any recommendations? Well, let me rephrase. A GPU these days has two distinct features, graphics-processing, and GPGPU. I'm less interested in the graphics part (since that pipeline could be studied in software, and in hardware, it's very specialized/ASICy). So I'm really interested in the massively-parallel GPGPU aspect of a GPU.

sgtnoodle 7y ago
I am speaking out of ignorance, but my understanding is that modern graphics pipelines consist of software "shader" programs running on the GPGPU hardware. The GPU makers aren't including vast numbers of compute cores just as a bonus feature, they're how the graphics part works. Each little core runs the same shader program to render its set of pixels, reading and writing out to different offsets in shared memory buffers. The "general purpose" use basically boils down to writing a shader program that does useful math rather than draw pretty pictures.
- namibj 7y ago
  There is fixed hardware for 5 main purposes. 1. Output framebuffer. 2. Polygon rasterization (often limited to points and triangles). 3. Texture sampling. This is accessible in CUDA (I have ~zero experience with other GPGPU systems). 4. Afaik also for blending. This might have stopped now. 5. Video codecs (MPEG-2, H.263, H.264, H.265, VP8, VP9, soon AV1) decoding, and also encoding for some of them. Nvidia RTX also include ray tracing hardware that handles that task more efficienly (I presume by using fixed logic for dispatching memory/cache-aware computations like e.g. content-addressable memory and such). Most things are handled by the shader cores. They are 1024bit SIMD with lane-masking until Volta, and a more flexible/arbitrary fork/join since Turing (not all Turing has the ray tracing hardware), which also brought a scalar execution port with it (like amd64 getting traditional RAX/RDX/etc. with their opcodes after only having AVX instructions). AMD GCN afaik has a quite explicit SIMD architecture, with a scalar execution port since inception. Also 1024bit iirc.
  - fizixer 7y ago
    Hey thanks for the very useful reply. Now that you mention, could you point to any reading resource for getting into the nitty gritty of the fixed hardware part of the GPU? From my interactions with some folks, I'm under the impression that this stuff is kept proprietary and both nVidia and AMD don't reveal the details. I'm just wondering if there are some general principles related to the fixed hardware aspect of the graphics pipeline of a GPU, that are compiled in a text or review paper or something. Thanks in advance.
msla 7y ago
As long as we're wishing... These kinds of projects always take you up to where CPUs were in the early 1950s on Large Systems or the 1970s in the home computing world: Single-issue processors with no memory protection or privilege levels. They work, in that you can write useful software for those systems, but taken as a way to explain how CPUs work in a holistic fashion they fall well short. They simply aren't complex enough to explain why Meltdown happens, for example: Since there is no concept of privilege to begin with, you can't use them to explain privilege level violations. More prosaically, you can't explain a "cold cache" when the processor doesn't have a cache which can be cold. This is demoralizing for the poor sods who think they're going to learn how CPUs work and end up with a CPU design which is decades out of date and no way to extend it to even a thirty-year-old design. "You can't get there from here" is the bane of tutorials which explain the basics and then stop.
- jacobush 7y ago
  Still, understanding any general purpose CPU gets you most of the way. Virtual memory and memory protection isn't terribly far off, could be implemented using paging. A very simple feature complete system could be made. A very basic model, yet working. A union between theory and practice- Heartbleed is because of memory and cache shenanigans. More like how things can get wrong if you optimize too hard. While important, it feels like another line of thinking.
- tyingq 7y ago
  That seems a bit harsh. You have to start somewhere, and this teaches basic stuff like an ALU, Clock, Accumulator, etc. Some homebrew CPUs have memory bank switching. Moving to an FPGA based CPU might be the next step. There are soft CPUs with cache, MMU, etc. (https://github.com/SpinalHDL/VexRiscv https://github.com/SpinalHDL/VexRiscv for example)
  - namibj 7y ago
    The picorv32 project offers a RISC-V core that only lacks MMU/privileges, but the memory interface should make a cache quite easy to add. The gate count won't be that bad, considering it's only ~700 LUTs in Xilinx 7-series FPGA. I think it'd fit in <10k gates, not counting the registers.

sgtnoodle 7y ago

I am speaking out of ignorance, but my understanding is that modern graphics pipelines consist of software "shader" programs running on the GPGPU hardware. The GPU makers aren't including vast numbers of compute cores just as a bonus feature, they're how the graphics part works. Each little core runs the same shader program to render its set of pixels, reading and writing out to different offsets in shared memory buffers. The "general purpose" use basically boils down to writing a shader program that does useful math rather than draw pretty pictures.

namibj 7y ago
There is fixed hardware for 5 main purposes. 1. Output framebuffer. 2. Polygon rasterization (often limited to points and triangles). 3. Texture sampling. This is accessible in CUDA (I have ~zero experience with other GPGPU systems). 4. Afaik also for blending. This might have stopped now. 5. Video codecs (MPEG-2, H.263, H.264, H.265, VP8, VP9, soon AV1) decoding, and also encoding for some of them. Nvidia RTX also include ray tracing hardware that handles that task more efficienly (I presume by using fixed logic for dispatching memory/cache-aware computations like e.g. content-addressable memory and such). Most things are handled by the shader cores. They are 1024bit SIMD with lane-masking until Volta, and a more flexible/arbitrary fork/join since Turing (not all Turing has the ray tracing hardware), which also brought a scalar execution port with it (like amd64 getting traditional RAX/RDX/etc. with their opcodes after only having AVX instructions). AMD GCN afaik has a quite explicit SIMD architecture, with a scalar execution port since inception. Also 1024bit iirc.
- fizixer 7y ago
  Hey thanks for the very useful reply. Now that you mention, could you point to any reading resource for getting into the nitty gritty of the fixed hardware part of the GPU? From my interactions with some folks, I'm under the impression that this stuff is kept proprietary and both nVidia and AMD don't reveal the details. I'm just wondering if there are some general principles related to the fixed hardware aspect of the graphics pipeline of a GPU, that are compiled in a text or review paper or something. Thanks in advance.

msla 7y ago

As long as we're wishing... These kinds of projects always take you up to where CPUs were in the early 1950s on Large Systems or the 1970s in the home computing world: Single-issue processors with no memory protection or privilege levels. They work, in that you can write useful software for those systems, but taken as a way to explain how CPUs work in a holistic fashion they fall well short. They simply aren't complex enough to explain why Meltdown happens, for example: Since there is no concept of privilege to begin with, you can't use them to explain privilege level violations. More prosaically, you can't explain a "cold cache" when the processor doesn't have a cache which can be cold. This is demoralizing for the poor sods who think they're going to learn how CPUs work and end up with a CPU design which is decades out of date and no way to extend it to even a thirty-year-old design. "You can't get there from here" is the bane of tutorials which explain the basics and then stop.

jacobush 7y ago
Still, understanding any general purpose CPU gets you most of the way. Virtual memory and memory protection isn't terribly far off, could be implemented using paging. A very simple feature complete system could be made. A very basic model, yet working. A union between theory and practice- Heartbleed is because of memory and cache shenanigans. More like how things can get wrong if you optimize too hard. While important, it feels like another line of thinking.
tyingq 7y ago
That seems a bit harsh. You have to start somewhere, and this teaches basic stuff like an ALU, Clock, Accumulator, etc. Some homebrew CPUs have memory bank switching. Moving to an FPGA based CPU might be the next step. There are soft CPUs with cache, MMU, etc. (https://github.com/SpinalHDL/VexRiscv https://github.com/SpinalHDL/VexRiscv for example)
- namibj 7y ago
  The picorv32 project offers a RISC-V core that only lacks MMU/privileges, but the memory interface should make a cache quite easy to add. The gate count won't be that bad, considering it's only ~700 LUTs in Xilinx 7-series FPGA. I think it'd fit in <10k gates, not counting the registers.