7 ms·

For anyone interested in computer graphics this is an absolutely wonderful series which is still very relevant despite being 11 years old. As an aside, I menti

For anyone interested in computer graphics this is an absolutely wonderful series which is still very relevant despite being 11 years old. As an aside, I mentioned this series earlier today on the Graphics Programming Discord server and now it's on the front page of HN? edit: on the other hand, searching the server it seems this article is linked there every few days, so it might just be coincidence

psychphysic 4y ago
Possibly the wrong place/person to ask, but is there a resource on how to mcguyver calculation from a graphics card.
- Agentlien 4y ago
  Definitely not the wrong place nor person, but what do you mean by mcguyver in this context? If you want to use it for general purpose computation not tied to rendering I would suggest CUDA. If you want to play with rendering try shadertoy.com
  - psychphysic 4y ago
    Thanks for replying! I'll try shadertoy.com Basically how would one use a GPU to compute something without CUDA/OpenCL mostly for curiosity but say I wanted to use a PS2s graphics chip to perform a calculation. How was/is that actually done?
    - Agentlien 4y ago
      PS2 was before the GPGPU age and its GPU is fixed functionality, so it's not suitable for general calculations. Your problem would have to align perfectly with the computations done for regular rendering. If we instead look at something more modern like an early GeForce with programmable shaders what was typically done was to set up your regular rendering of a full screen quad and write a pixel shader which performs your desired computations instead of actual lighting calculations. APIs such as CUDA and OpenCL were introduced to allow people who weren't making games to make GPU calculations without pretending that they were colour calculations.
      - psychphysic 4y ago
        Thanks for the detailed answer!
      - mewse 4y ago
        The PS2 was actually kind of ahead of its time in this regard, with programmable vector units right there in the middle of the rendering pipeline; you could actually write the equivalent of vertex shaders and even simple geometry shaders *long* before those were available on standard home GPUs. (although you had to code them in assembly) No fragment shaders, though, it's true.
        Agentlien 4y ago
        I knew there were programmable vector units and fixed functionality for fragments. Seeing other responses here I feel I underestimated how flexible it was, not having worked with it myself.
    - 33985868 4y ago
      TL;DR yes and no (thanks to DSPs, technically some were an integral part of the GPU): In the era of semi-programmable graphics pipelines, of which there was the N64, PS2 and GameCube, you would not be able to solve general-purpose problems using only that pipeline: given a handful of colour mixing formulas, registers, textures and vertices to control the pixels to write back to memory, I fail to come up with any tangible problem you could hack them into solving. However, what the 3D generation of video game consoles had to bundle with the hardware in order to process complex scenes at interactive frame rates were digital signal processors (DSPs). Think of them as regular processors, but with an extra vector unit, allowing you to crunch enormous amounts of data in parallel (single instruction, multiple data instructions, or SIMD). This was essential to perform geometry transformations, which benefit greatly from parallelism, in order to build graphics commands to pass down to the rasteriser. I am unsure if the SEGA Saturn and PS1's vector-accelerated instructions are sufficiently general-purpose to allow them perform any computation you wish to do, but at least starting with the Nintendo 64, you could write microcode to accelerate any task you'd like, provided you were brave enough to deal with the harsh memory constraints of microcode and obscure documentation. To give concrete examples, the PS1 came with a dedicated chip (the MDEC, or motion decoder) to decode MPEG video frames from the CD directly into the VRAM to display on screen. While the N64 doesn't have dedicated video decoding chips, its signal processor was designed in such a way to allow microcode to do an equivalent job (not to mention YUV texture decoding on the rasteriser's side). So this did not stop a talented Resident Evil 2 developer fresh out of school to write an MPEG video decoder microcode to be able to cram two CDs worth of video data (around 1 gigabyte, down to a 64 megabyte cartridge), of course with other smart decisions like data deduplication and further compression/interlacing. Another one was Rare developers writing an MP3 audio decoder microcode to store large amounts of dialogue. And finally, in recent times, a developer managed to write an H.264 video decoder microcode, for a machine that was released almost a decade prior to this codec's birth. You can also accelerate physics and anything else that would benefit from SIMD, really, and in fact, while more modern CPUs integrate SIMD instructions in their tool chest that compilers can take advantage of, the PS3's Cell processor was a brief throwback to the old hardcore ways, before GPGPU became king. You could almost treat the DSPs as the compute units of modern GPU architectures: they definitely processed the vertices, and nothing stops you from adding a "vertex shader" pass, however, because it's not directly integrated into the graphics pipeline, it's harder to emulate a true pixel shader, you might be limited to full-screen pixel shading since there's no feedback from the rasteriser about which pixels exactly get written to memory.
joenot443 4y ago
Can you share a link or some other info about said Discord? Sounds like a comfy place.
- Agentlien 4y ago
  It is. Come see for yourself: https://discord.gg/XpMH8Dn5 https://discord.gg/XpMH8Dn5
- pixelpoet 4y ago
  I left the server after 2 years or something because I couldn't stand the abysmal signal:noise ratio (of many kinds), and that's as someone who dedicated their life to CG. Just my 2c.
  - Agentlien 4y ago
    I get what you mean. I sometimes enjoy looking at the showcase channel or checking out some of the technical discussions but I quickly feel I need a break of a few months from it because there's just so much going on and a lot of it is silly.

psychphysic 4y ago

Possibly the wrong place/person to ask, but is there a resource on how to mcguyver calculation from a graphics card.

Agentlien 4y ago
Definitely not the wrong place nor person, but what do you mean by mcguyver in this context? If you want to use it for general purpose computation not tied to rendering I would suggest CUDA. If you want to play with rendering try shadertoy.com
- psychphysic 4y ago
  Thanks for replying! I'll try shadertoy.com Basically how would one use a GPU to compute something without CUDA/OpenCL mostly for curiosity but say I wanted to use a PS2s graphics chip to perform a calculation. How was/is that actually done?
  - Agentlien 4y ago
    PS2 was before the GPGPU age and its GPU is fixed functionality, so it's not suitable for general calculations. Your problem would have to align perfectly with the computations done for regular rendering. If we instead look at something more modern like an early GeForce with programmable shaders what was typically done was to set up your regular rendering of a full screen quad and write a pixel shader which performs your desired computations instead of actual lighting calculations. APIs such as CUDA and OpenCL were introduced to allow people who weren't making games to make GPU calculations without pretending that they were colour calculations.
    - psychphysic 4y ago
      Thanks for the detailed answer!
    - mewse 4y ago
      The PS2 was actually kind of ahead of its time in this regard, with programmable vector units right there in the middle of the rendering pipeline; you could actually write the equivalent of vertex shaders and even simple geometry shaders *long* before those were available on standard home GPUs. (although you had to code them in assembly) No fragment shaders, though, it's true.
      - Agentlien 4y ago
        I knew there were programmable vector units and fixed functionality for fragments. Seeing other responses here I feel I underestimated how flexible it was, not having worked with it myself.
  - 33985868 4y ago
    TL;DR yes and no (thanks to DSPs, technically some were an integral part of the GPU): In the era of semi-programmable graphics pipelines, of which there was the N64, PS2 and GameCube, you would not be able to solve general-purpose problems using only that pipeline: given a handful of colour mixing formulas, registers, textures and vertices to control the pixels to write back to memory, I fail to come up with any tangible problem you could hack them into solving. However, what the 3D generation of video game consoles had to bundle with the hardware in order to process complex scenes at interactive frame rates were digital signal processors (DSPs). Think of them as regular processors, but with an extra vector unit, allowing you to crunch enormous amounts of data in parallel (single instruction, multiple data instructions, or SIMD). This was essential to perform geometry transformations, which benefit greatly from parallelism, in order to build graphics commands to pass down to the rasteriser. I am unsure if the SEGA Saturn and PS1's vector-accelerated instructions are sufficiently general-purpose to allow them perform any computation you wish to do, but at least starting with the Nintendo 64, you could write microcode to accelerate any task you'd like, provided you were brave enough to deal with the harsh memory constraints of microcode and obscure documentation. To give concrete examples, the PS1 came with a dedicated chip (the MDEC, or motion decoder) to decode MPEG video frames from the CD directly into the VRAM to display on screen. While the N64 doesn't have dedicated video decoding chips, its signal processor was designed in such a way to allow microcode to do an equivalent job (not to mention YUV texture decoding on the rasteriser's side). So this did not stop a talented Resident Evil 2 developer fresh out of school to write an MPEG video decoder microcode to be able to cram two CDs worth of video data (around 1 gigabyte, down to a 64 megabyte cartridge), of course with other smart decisions like data deduplication and further compression/interlacing. Another one was Rare developers writing an MP3 audio decoder microcode to store large amounts of dialogue. And finally, in recent times, a developer managed to write an H.264 video decoder microcode, for a machine that was released almost a decade prior to this codec's birth. You can also accelerate physics and anything else that would benefit from SIMD, really, and in fact, while more modern CPUs integrate SIMD instructions in their tool chest that compilers can take advantage of, the PS3's Cell processor was a brief throwback to the old hardcore ways, before GPGPU became king. You could almost treat the DSPs as the compute units of modern GPU architectures: they definitely processed the vertices, and nothing stops you from adding a "vertex shader" pass, however, because it's not directly integrated into the graphics pipeline, it's harder to emulate a true pixel shader, you might be limited to full-screen pixel shading since there's no feedback from the rasteriser about which pixels exactly get written to memory.

joenot443 4y ago

Can you share a link or some other info about said Discord? Sounds like a comfy place.

Agentlien 4y ago
It is. Come see for yourself: https://discord.gg/XpMH8Dn5 https://discord.gg/XpMH8Dn5
pixelpoet 4y ago
I left the server after 2 years or something because I couldn't stand the abysmal signal:noise ratio (of many kinds), and that's as someone who dedicated their life to CG. Just my 2c.
- Agentlien 4y ago
  I get what you mean. I sometimes enjoy looking at the showcase channel or checking out some of the technical discussions but I quickly feel I need a break of a few months from it because there's just so much going on and a lot of it is silly.