13 ms·

Introduction to GPUs with OpenGL

155 points by Seb-C 5y ago

WatchDog 5y ago
I thought the framing of CPU's as specialized, and GPU's as the opposite was a bit odd and missleading. If anything it's GPU's that are specialized to address a narrow set of problems.
- dragontamer 5y ago
  You might want to reread the paragraph. > CPUs are highly specialized in computational speed and have a broad range of low-level instructions. GPUs are quite the opposite, because they are slower and simpler, but focuses on parallelization (high number of cores), and have a more limited set of instructions. ------- The only thing I'd change is that I'd say that "CPUs are specialized in computational latency", because speed is an ambiguous word with regards to performance. Latency is more specific and a better description of how CPUs specialize. GPUs are of course the opposite: GPUs specialize in bandwidth rather than latency.
starmole 5y ago
This is a nice very high level view. But if I were to teach modern GPUs and rendering I would recommend starting with something like https://tayfunkayhan.wordpress.com/2018/11/24/rasterization-in-one-weekend-part-i/ https://tayfunkayhan.wordpress.com/2018/11/24/rasterization-...
- erwincoumans 5y ago
  another nice resource is https://github.com/ssloy/tinyrenderer/wiki https://github.com/ssloy/tinyrenderer/wiki The wiki is nice and it has a functional renderer with cpu vertex/pixel shaders, texture mapping and obj loader. A Python version is just 100 lines: https://github.com/rougier/tiny-renderer https://github.com/rougier/tiny-renderer
- Seb-C 5y ago
  That's pretty nice. I focused on the practical parts in my article, but diving into the rasterization process itself is also very interesting. Thanks for sharing!
- skywal_l 5y ago
  Scratch A Pixel is really comprehensive and very "talk to me like I am 5 years old" kind of tutorial: https://www.scratchapixel.com/ https://www.scratchapixel.com/
- ArtWomb 5y ago
  For me, I had to go deep into NVidia docs & sample code before it really clicked. And there's still a dearth of online materials for webgl 2.0 compute & webgpu. But it's still early ;)
adamnemecek 5y ago
If you are looking to use a more modern API (and language) I can recommend this wgpu/Rust tutorial https://sotrh.github.io/learn-wgpu/ https://sotrh.github.io/learn-wgpu/.
- pjmlp 5y ago
  The WebGL tutorial has the advantage of running everywhere, while WebGPU will take years to be available, assuming it does indeed get released this year across all major browsers, then it requires a Vulkan/DX 12 card anyway.
  - skocznymroczny 5y ago
    wgpu has a wgpu-native component which is a native library that exposes a C API. I use it in D for my 3D projects and it's quite nice.
    - pjmlp 5y ago
      I don't see any reason for WebGPU outside of the browser, we already have middleware engines that can take advantage of latest Vulkan/DirectX 12/Metal/LibGNM/NVN features, without being castrated in capabilities.
      - skocznymroczny 5y ago
        Compile to WASM is a popular thing nowadays. It's enticing to be able to write your app in native WebGPU and then with almost no changes in code be able to compile your app to the web browser.
        pjmlp 5y ago
        Fashion driven development more likely.
      - kvark 5y ago
        It’s true that WebGPU native could be seen as just another middleware. However, what differentiates it is: 1. Well-thought API with an actual standard 2. Large conformance test suite 3. Trivial deploy on the Web
pjmlp 5y ago
Tutorial is relatively nice, however OpenGL, OpenGL ES and WebGL aren't the same, besides sharing GL in the name. Sure the basic examples look similar, until one wants to start porting existing applications.
- moonchild 5y ago
  My understanding is that webgl is a straight port of gles, and newer versions of gles incorporate most of the interesting features of newer versions of gl.
  - pjmlp 5y ago
    WebGL 2.0 is a subset of OpenGL ES 3.0, which last version was OpenGL ES 3.2. Additionally, even the overlapping subset isn't 100% equal due to the security constraints on the browser.
- Seb-C 5y ago
  Sure, there are lots of differences between OpenGL and OpenGL ES, but the fundamental logic and architecture is pretty much the same.
- TazeTSchnitzel 5y ago
  WebGL is a JavaScript interface to OpenGL ES, with some limitations. If you only want the core feature set (no extensions), it is pretty much the same API, and with emscripten it is possible to write portable C, C++ or Rust code against the OpenGL ES API and have it work not only natively but also in the browser via WebGL. OpenGL ES is almost a subset of OpenGL, though there are also some ES-exclusive features. With some care it's possible to write code that works on both OpenGL ES (and WebGL if you want) and OpenGL. Annoyingly there isn't a name for the common subset that works in both APIs.
k_sze 5y ago
I'm mildly surprised that people still write tutorials using OpenGL nowadays. I thought the concensus is that 1) OpenGL is bad due to hidden states (and if I remember correctly, the hidden states can behave differently depending on the vendor, which exacerbates the problem), and that 2) people should move to Vulkan (or Metal, or DirectX 12).
- mschuetz 5y ago
  I think one of the main issues is that Vulkan is really bad from a usability perspective. OpenGL is too, but there is little incentive to switch from one bad API that you know how to use, to another bad API that you don't know how to use. On the other hand, I've spent time learning WebGPU in the past year and found that it was an excellent API that is an enormous quality of live improvement over OpenGL, so even if it has fewer features (due to Web, not API design), it's still something that I really want to switch to, unlike Vulkan.
  - tpxl 5y ago
    I had a really good time writing a Vulkan renderer for a project I did. There's _A LOT_ of boilerplate, but there are helpful error messages every step of the way and the API makes sense because everything is explicit, unlike OGL.
    - mschuetz 5y ago
      It's not just the boilerplate, but also seemingly noncensical things like stypes.
    - SantalBlush 5y ago
      Getting Vulkan to work is one thing. Getting Vulkan to work well is another.
- blihp 5y ago
  Don't believe the hype. OpenGL is still fine for getting started with and applications where Vulkan etc is overkill. It makes perfect sense for game engines and heavy duty applications to make the switch, but for the simple stuff stick with OpenGL where it makes sense.
flohofwoe 5y ago
This should really be titled "Introduction to WebGL". The GL programming model is very different from what's actually going on under the hood. GL it at best a faint reminder of how GPUs worked during the 90's. This is by now also over a decade old but still gives a much better idea how current GPUs work: https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-graphics-pipeline-2011-index/ https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-...
- badsectoracula 5y ago
  FWIW OpenGL only mapped to how the hardware worked for a particular vendor (Nvidia) and a very short time (~GeForce 2, IIRC). OpenGL was always a higher level API, it just is an API that provides functionality instead of being a framework (so you had to make your own). Even in SGI hardware a lot of features were done only in software and during that time on PCs most cards could barely do more than rasterization and transformations (and some not even that).
  - sharpneli 5y ago
    Even that wasn't really OpenGL anymore, even though some internal registers matched OpenGL directly. The only HW that was truly OpenGL was Silicon Graphics IRIS workstations. IrisGL was released as open standard with some minor changed with the name OpenGL.
    - badsectoracula 5y ago
      AFAIK even though from a very high level perspective they are similar, in practice IrisGL differs a lot from OpenGL - it isn't just a rename. Also AFAIK IrisGL had functions for creating windows, etc, that didn't exist in OpenGL (GLUT was meant to bridge that gap).
      - Jasper_ 5y ago
        No, IrisGL did not have any functions for creating Windows, you used libX11 and the Xt toolkit to do that.
tambarskjelve 5y ago
Some years ago, I came over a website that interactively demonstrated how a (software) 3D engine rendered rotating gears similar to glxgears in a step by step fashion. You could set the speed of the rendering process from a running animation to each and every triangle being rasterized, with depth testing and everything. I still try to look for the site, but it seems to have vanished from the internet.
lostgame 5y ago
Hmm. This isn't really much to do with a GPU, it's more of a very, very 101 intro to OpenGL. It takes me back to grade 8 or 9 when I was originally learning this stuff! Very nostalgic. But very little todo with GPU instructions themselves.
markhahn 5y ago
Talking about OpenGL feels very regressive - the 'G' in GPU is hardly "graphics" any more, so presenting through the lens of rendering is backwards. These days, GPU is more like "General (data parallel) Processing Unit", and rendering is just a relatively uninteresting special case. Think of it this way: wouldn't the world be a better place if Linux provided a way to create a GPU process without reference to displays?
- freeone3000 5y ago
  OpenMP and OpenCL support GPUs as target devices -- this is the fastest way for AMD GPUs. Nvidia has CUDA, which is faster but only for Nvidia cards.
imran0 5y ago
While there are a lot of resources available for different graphics API's, I have yet to find a good comprehensive tutorial or library for software rendering. Being interested, I would love to know if anyone has a reference at hand.
- tgflynn 5y ago
  There are a few around. https://raytracing.github.io/books/RayTracingInOneWeekend.html https://raytracing.github.io/books/RayTracingInOneWeekend.ht... https://graphicscodex.courses.nvidia.com/app.html https://graphicscodex.courses.nvidia.com/app.html https://www.gabrielgambetta.com/computer-graphics-from-scratch/index.html https://www.gabrielgambetta.com/computer-graphics-from-scrat... I can vouch for the first two as being good. I haven't actually looked at the third but I found I had a bookmark for it.
japhib 5y ago
This is a WebGL tutorial -- for OpenGL there's a fantastic tutorial at https://learnopengl.com/ https://learnopengl.com/

155 points by Seb-C 5y ago

I thought the framing of CPU's as specialized, and GPU's as the opposite was a bit odd and missleading. If anything it's GPU's that are specialized to address a narrow set of problems.

dragontamer 5y ago
You might want to reread the paragraph. > CPUs are highly specialized in computational speed and have a broad range of low-level instructions. GPUs are quite the opposite, because they are slower and simpler, but focuses on parallelization (high number of cores), and have a more limited set of instructions. ------- The only thing I'd change is that I'd say that "CPUs are specialized in computational latency", because speed is an ambiguous word with regards to performance. Latency is more specific and a better description of how CPUs specialize. GPUs are of course the opposite: GPUs specialize in bandwidth rather than latency.

starmole 5y ago

This is a nice very high level view. But if I were to teach modern GPUs and rendering I would recommend starting with something like https://tayfunkayhan.wordpress.com/2018/11/24/rasterization-in-one-weekend-part-i/ https://tayfunkayhan.wordpress.com/2018/11/24/rasterization-...

erwincoumans 5y ago
another nice resource is https://github.com/ssloy/tinyrenderer/wiki https://github.com/ssloy/tinyrenderer/wiki The wiki is nice and it has a functional renderer with cpu vertex/pixel shaders, texture mapping and obj loader. A Python version is just 100 lines: https://github.com/rougier/tiny-renderer https://github.com/rougier/tiny-renderer
Seb-C 5y ago
That's pretty nice. I focused on the practical parts in my article, but diving into the rasterization process itself is also very interesting. Thanks for sharing!
skywal_l 5y ago
Scratch A Pixel is really comprehensive and very "talk to me like I am 5 years old" kind of tutorial: https://www.scratchapixel.com/ https://www.scratchapixel.com/
ArtWomb 5y ago
For me, I had to go deep into NVidia docs & sample code before it really clicked. And there's still a dearth of online materials for webgl 2.0 compute & webgpu. But it's still early ;)

adamnemecek 5y ago

If you are looking to use a more modern API (and language) I can recommend this wgpu/Rust tutorial https://sotrh.github.io/learn-wgpu/ https://sotrh.github.io/learn-wgpu/.

pjmlp 5y ago
The WebGL tutorial has the advantage of running everywhere, while WebGPU will take years to be available, assuming it does indeed get released this year across all major browsers, then it requires a Vulkan/DX 12 card anyway.
- skocznymroczny 5y ago
  wgpu has a wgpu-native component which is a native library that exposes a C API. I use it in D for my 3D projects and it's quite nice.
  - pjmlp 5y ago
    I don't see any reason for WebGPU outside of the browser, we already have middleware engines that can take advantage of latest Vulkan/DirectX 12/Metal/LibGNM/NVN features, without being castrated in capabilities.
    - skocznymroczny 5y ago
      Compile to WASM is a popular thing nowadays. It's enticing to be able to write your app in native WebGPU and then with almost no changes in code be able to compile your app to the web browser.
      - pjmlp 5y ago
        Fashion driven development more likely.
    - kvark 5y ago
      It’s true that WebGPU native could be seen as just another middleware. However, what differentiates it is: 1. Well-thought API with an actual standard 2. Large conformance test suite 3. Trivial deploy on the Web

pjmlp 5y ago

Tutorial is relatively nice, however OpenGL, OpenGL ES and WebGL aren't the same, besides sharing GL in the name. Sure the basic examples look similar, until one wants to start porting existing applications.

moonchild 5y ago
My understanding is that webgl is a straight port of gles, and newer versions of gles incorporate most of the interesting features of newer versions of gl.
- pjmlp 5y ago
  WebGL 2.0 is a subset of OpenGL ES 3.0, which last version was OpenGL ES 3.2. Additionally, even the overlapping subset isn't 100% equal due to the security constraints on the browser.
Seb-C 5y ago
Sure, there are lots of differences between OpenGL and OpenGL ES, but the fundamental logic and architecture is pretty much the same.
TazeTSchnitzel 5y ago
WebGL is a JavaScript interface to OpenGL ES, with some limitations. If you only want the core feature set (no extensions), it is pretty much the same API, and with emscripten it is possible to write portable C, C++ or Rust code against the OpenGL ES API and have it work not only natively but also in the browser via WebGL. OpenGL ES is almost a subset of OpenGL, though there are also some ES-exclusive features. With some care it's possible to write code that works on both OpenGL ES (and WebGL if you want) and OpenGL. Annoyingly there isn't a name for the common subset that works in both APIs.

k_sze 5y ago

I'm mildly surprised that people still write tutorials using OpenGL nowadays. I thought the concensus is that 1) OpenGL is bad due to hidden states (and if I remember correctly, the hidden states can behave differently depending on the vendor, which exacerbates the problem), and that 2) people should move to Vulkan (or Metal, or DirectX 12).

mschuetz 5y ago
I think one of the main issues is that Vulkan is really bad from a usability perspective. OpenGL is too, but there is little incentive to switch from one bad API that you know how to use, to another bad API that you don't know how to use. On the other hand, I've spent time learning WebGPU in the past year and found that it was an excellent API that is an enormous quality of live improvement over OpenGL, so even if it has fewer features (due to Web, not API design), it's still something that I really want to switch to, unlike Vulkan.
- tpxl 5y ago
  I had a really good time writing a Vulkan renderer for a project I did. There's _A LOT_ of boilerplate, but there are helpful error messages every step of the way and the API makes sense because everything is explicit, unlike OGL.
  - mschuetz 5y ago
    It's not just the boilerplate, but also seemingly noncensical things like stypes.
  - SantalBlush 5y ago
    Getting Vulkan to work is one thing. Getting Vulkan to work well is another.
blihp 5y ago
Don't believe the hype. OpenGL is still fine for getting started with and applications where Vulkan etc is overkill. It makes perfect sense for game engines and heavy duty applications to make the switch, but for the simple stuff stick with OpenGL where it makes sense.

flohofwoe 5y ago

This should really be titled "Introduction to WebGL". The GL programming model is very different from what's actually going on under the hood. GL it at best a faint reminder of how GPUs worked during the 90's. This is by now also over a decade old but still gives a much better idea how current GPUs work: https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-graphics-pipeline-2011-index/ https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-...

badsectoracula 5y ago
FWIW OpenGL only mapped to how the hardware worked for a particular vendor (Nvidia) and a very short time (~GeForce 2, IIRC). OpenGL was always a higher level API, it just is an API that provides functionality instead of being a framework (so you had to make your own). Even in SGI hardware a lot of features were done only in software and during that time on PCs most cards could barely do more than rasterization and transformations (and some not even that).
- sharpneli 5y ago
  Even that wasn't really OpenGL anymore, even though some internal registers matched OpenGL directly. The only HW that was truly OpenGL was Silicon Graphics IRIS workstations. IrisGL was released as open standard with some minor changed with the name OpenGL.
  - badsectoracula 5y ago
    AFAIK even though from a very high level perspective they are similar, in practice IrisGL differs a lot from OpenGL - it isn't just a rename. Also AFAIK IrisGL had functions for creating windows, etc, that didn't exist in OpenGL (GLUT was meant to bridge that gap).
    - Jasper_ 5y ago
      No, IrisGL did not have any functions for creating Windows, you used libX11 and the Xt toolkit to do that.

tambarskjelve 5y ago

Some years ago, I came over a website that interactively demonstrated how a (software) 3D engine rendered rotating gears similar to glxgears in a step by step fashion. You could set the speed of the rendering process from a running animation to each and every triangle being rasterized, with depth testing and everything. I still try to look for the site, but it seems to have vanished from the internet.

lostgame 5y ago

Hmm. This isn't really much to do with a GPU, it's more of a very, very 101 intro to OpenGL. It takes me back to grade 8 or 9 when I was originally learning this stuff! Very nostalgic. But very little todo with GPU instructions themselves.

markhahn 5y ago

Talking about OpenGL feels very regressive - the 'G' in GPU is hardly "graphics" any more, so presenting through the lens of rendering is backwards. These days, GPU is more like "General (data parallel) Processing Unit", and rendering is just a relatively uninteresting special case. Think of it this way: wouldn't the world be a better place if Linux provided a way to create a GPU process without reference to displays?

freeone3000 5y ago
OpenMP and OpenCL support GPUs as target devices -- this is the fastest way for AMD GPUs. Nvidia has CUDA, which is faster but only for Nvidia cards.

imran0 5y ago

While there are a lot of resources available for different graphics API's, I have yet to find a good comprehensive tutorial or library for software rendering. Being interested, I would love to know if anyone has a reference at hand.

tgflynn 5y ago
There are a few around. https://raytracing.github.io/books/RayTracingInOneWeekend.html https://raytracing.github.io/books/RayTracingInOneWeekend.ht... https://graphicscodex.courses.nvidia.com/app.html https://graphicscodex.courses.nvidia.com/app.html https://www.gabrielgambetta.com/computer-graphics-from-scratch/index.html https://www.gabrielgambetta.com/computer-graphics-from-scrat... I can vouch for the first two as being good. I haven't actually looked at the third but I found I had a bookmark for it.

japhib 5y ago

This is a WebGL tutorial -- for OpenGL there's a fantastic tutorial at https://learnopengl.com/ https://learnopengl.com/