Most of these slides don't seem to work. Can't tell if they require GL extensions I don't have, need to run in Chrome Canary, or what. (Firefox, GeForce GTX 670)
On a more pedantic note, the 'programmable graphics pipeline' slides are so inaccurate that it makes me slightly uncomfortable. It's okay to generalize some so that people get the idea of what's going on, but you're leaving out a lot of important details that help make it clearer why things work the way they do in modern 3d hardware.
For a starting point, look at how the modern pipeline is described here:
http://fgiesen.wordpress.com/2011/07/03/a-trip-through-the-g...
Even with geometry shaders left out of the picture, you've got something like 6 'stages' in the pipeline, entirely ignoring all the incredibly complex magic that lives in the driver (and for WebGL apps, in the browser).
It might be better to instead show the flow of data through the CPU/GPU instead of showing pipeline stages - for example:
vertex buffers, index buffers, shaders, and draw calls that tie them together
primitives constructed from the indices and vertices
quads/spans/fragments/etc created from the primitives by the rasterizer
the z-buffer - what goes into it, where, who writes to it and reads from it
the pixel shader - what inputs it actually takes and what it produces
the actual output color data being written to the framebuffer
Really just pedantry at this point, but I don't think the existing pipeline diagram in the slides really says much useful.
If I had to pick one important lesson to convey when talking about modern pipelines, it would probably be how incredibly, massively parallel they are. hundreds or thousands of pixels/quads might be getting shaded at any given time, which is important to understand if you're trying to do interesting things with the GPU - it's not going to behave like your CPU and it may degrade in strange ways if you make the wrong demands.
On a more pedantic note, the 'programmable graphics pipeline' slides are so inaccurate that it makes me slightly uncomfortable. It's okay to generalize some so that people get the idea of what's going on, but you're leaving out a lot of important details that help make it clearer why things work the way they do in modern 3d hardware.
For a starting point, look at how the modern pipeline is described here: http://fgiesen.wordpress.com/2011/07/03/a-trip-through-the-g... Even with geometry shaders left out of the picture, you've got something like 6 'stages' in the pipeline, entirely ignoring all the incredibly complex magic that lives in the driver (and for WebGL apps, in the browser).
It might be better to instead show the flow of data through the CPU/GPU instead of showing pipeline stages - for example:
vertex buffers, index buffers, shaders, and draw calls that tie them together
primitives constructed from the indices and vertices
quads/spans/fragments/etc created from the primitives by the rasterizer
the z-buffer - what goes into it, where, who writes to it and reads from it
the pixel shader - what inputs it actually takes and what it produces
the actual output color data being written to the framebuffer
Really just pedantry at this point, but I don't think the existing pipeline diagram in the slides really says much useful.
If I had to pick one important lesson to convey when talking about modern pipelines, it would probably be how incredibly, massively parallel they are. hundreds or thousands of pixels/quads might be getting shaded at any given time, which is important to understand if you're trying to do interesting things with the GPU - it's not going to behave like your CPU and it may degrade in strange ways if you make the wrong demands.