How a modern GPU works ?

I'm not sure if this will explicitly answer your question (it's been a long time since I read it) but it's worth a read either way.
https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-graphics-pipeline-2011-index/

edit - I forgot about this thread https://forum.beyond3d.com/threads/books-on-gpu-architecture-and-programming.52653/ it included the link I gave you and some other resources.

 

I thought I'd post this here, another article - this time from nvidia:
https://developer.nvidia.com/content/life-triangle-nvidias-logical-pipeline

 

Here comes the noob question

If it creates 3 vertices thats a triangle, and thats geometry isnt it ?

 

The vertex shader has no concept of geometry to begin with. The input is a vertex and associated parameters and the output is a vertex and associated parameters, so it's 1:1. So the vertex shader doesn't really create vertexes either, it's more like it changes them.

The vertexes could be ended up used as part of one triangle, multiple triangles (vertex shared as a corner of adjacent triangles), no triangles (if it was clipped or culled) or higher level geometry that's converted into triangles later.

 

For sake of completeness... This presentation describes how to create vertexes using the vertex shader using dx11. Starts on the 7th slide.
http://amd-dev.wpengine.netdna-cdn....12/10/Vertex-Shader-Tricks-Bill-Bilodeau.ppsx

 

I stand corrected, thanks. This just goes to show how much barriers in the traditional pipeline have been broken down (I'm sure it's more so in DX12) Do you know if this capability has been added to any recent OpenGL too?

 

No clue, I was searching for papers here http://developer.amd.com/resources/documentation-articles/conference-presentations/ a while ago and came across that paper. I was pretty surprised myself, its a pretty useful feature especially on that era of API... draw call number limitations.

 

You should make a separate thread for that link since it has more to do with a render technique than how a GPU works. If you want some presentations on render techniques I'll post them in that thread.

 

A common misconception is that vertex shader stage runs first and transforms all the vertices. This is not how it goes.

Assuming indexed triangle rendering (the most common one):
Primitive assembler reads 3 indices from the index buffer. GPU checks the "post transform vertex cache" (also known as parameter cache) for each index, and runs the vertex shader for those vertices that did not exist in the cache. When all the 3 vertices of a triangle are transformed, the transformed vertex positions go to a fixed function unit that first determines the rough coverage of the triangle (*) and then fine (2x2 quad) coverage of the triangle (*). This results in variable amount of pixel shader instances (grouped in 2x2 quads). GPU starts to execute these pixel shader instances immediately, while still continuing the primitive assembler work and vertex shader work (and generating new pixel shader instances based on triangle coverage) at the same time. In the end the pixel shader output is tested against triangle coverage (not all pixels in 2x2 tile are inside the triangle), against depth and stencil. Pixels that fail the test are rejected.

Both vertices and pixels are actually grouped to waves/warps before execution (32 elements on NVIDIA hardware, 64 elements on AMD hardware, 8/16/32 on Intel hardware). This adds a little bit latency to the pipeline, but simplifies the GPU execution a lot, since the later stages don't need to process/book-keep single vertices/pixels.

(*) In these stages the pixel shader instances might be culled by hierarchical depth buffering and by early depth/stencil test.

 

Right! I was thinking why depth/stencil checks came after pixel shading work had already been kicked off! There's early-Z and such to cut down on the unnecessary workload.

Anyway, why is it that depth check (not counting early Z stuff) is located at pretty much the very end of the pipe? Is it just easier to build the GPU that way, or is it maybe just some historical reason, IE, a carry-over from the classical Silicon Graphics rendering pipe or somesuch ("it's always been that way")?

Cheers!

 

That is the OpenGL (well probably even the preceding IrisGL**) model of the SGI machines***. It permits using the texture to control visibility of the polygon with a fixed pipeline processing order.

Of course, it is a pain from a performance perspective since most of the scene doesn't require alpha testing.


**but I don't have time to go an check through the ancient documentation.
***possibly other early work station systems, e.g, Apollo,Sun, HP, as well but someone else would need to check.

 

It might, though, and it is roughly what happens on tile based renderers (where geometry work from one render pass overlaps raster work from the previous render pass).

 

Came across this: http://openglinsights.com/bendingthepipeline.html#ProgrammableVertexPulling