
GL 3.2 machine
Posted Tuesday, 22 September, 2009 - 15:11 by Inertia inBy dropping fixed-functionality OpenGL lost quite some weight, namely
Evaluators & Vertex Arrays
Feedback & Selection
Immediate mode Vertex conversion
Matrix Control
Lighting
Texture Coordinate Generation, Fog
So what's left is
Vertex Array Control & Primitive Assembly
Clipping, Perspective & Viewport
Rasterization
Per-Fragment Ops
Framebuffer Control
Pixel Conversions
A diagram of what is left is quite compact now and I'd like to add this to the book/manual, but first I'd like to gather some feedback and suggestions. Free your mind.
| Attachment | Size |
|---|---|
| OpenGL machine diagram v2.png | 154.61 KB |


Comments
Re: GL 3.2 machine
Whistles!
Nice overview of the pipeline. The sequence looks logical - I don't recall the exact ordering of steps between pixel ownership and masking but looks out of the ordinary (I can cross-check against my copy of the redbook, if you wish).
I'm a little curious about the pixel ownership test - do drivers actually evaluate fragments and discard them afterwards? (I distinctly recall my old R300 video card rendering faster when the window was partially off-screen, suggesting that those pixels where completely skipped). The OpenGL FAQ states that the implementation details differ between drivers and FBOs make things even more complicated (and I'm too lazy to crack open my copy of the specs).
Also, the "readback control" section is missing
GL.BlitFramebuffer()(or I'm officially blind). :-)Re: GL 3.2 machine
The way I understand it, the pixel ownership test is the same concept as GL.Scissor but uses the GL Context as constraint. It would make sense to move pixel ownership and scissor before the fragment shader, but afaik this is not the case. Only viewport clipping and triangle culling are running before the fragment shader is.
This diagram is lacking the Transform Feedback functionality by design, that should be dealt with in a separate graphic in a separate chapter. Geometry shaders are there, but it may not be obvious enough that they're optional.
Edit: samplers, textures and shaders are quite abstract, the current program and uniforms should be merged.
Re: GL 3.2 machine
How would you change the diagram so it shows properly that several VS/GS/FS may be executed at the same time? Atm it displays a rather sequential execution...
Re: GL 3.2 machine
Do you need to show that in the card? Conceptually, the pipeline *is* sequential - it doesn't matter whether the driver executes parts in parallel or in series, as the result must be the same in either case.
It might be worth adding the potential feedback loops as simple arrows looping from the framebuffer to the top (transform feedback) and the fragment shader (texture feedback - this is allowed but undesirable).
Re: GL 3.2 machine
True, maybe it should be ignored for the sake of simplicity.
[Transform Feedback]
The way I understand the specs, this extension would belong between the 2 primitive assembly and the clipping stage (i.e. it can only save the vertex or geometry shader output). I don't really want the extension in the diagram though, it's a solution used by very few applications and it's sole presence will be more confusing than helping.
[texture feedback]
I'm not quite sure yet in how far textures should become part of this. Maybe I need to formulate more clearly what I'm trying to do:
Re: GL 3.2 machine
I've uploaded the diagram again with minor changes: commands that initate pipeline operations have a different border style than state-related commands and sRGB conversion was missing. Uniforms and the active program were merged for clarity.
GL.BlitFramebuffer will not be added, since it only uses pixel ownership and scissor test from the fragment ops and skips all other steps (would also be confusing, since there is no reference to FBO besides the draw- and readbuffer commands).
I'm unsure how to proceed with deprecated functions, mark them with a different color? (this is overly complicated with the UML editor used, so I'd really like to do this only once).
Re: GL 3.2 machine
Funny coincidence that nvidia released slides with a similar diagram a week later :)
http://www.slideshare.net/Mark_Kilgard/opengl-32-and-more
A good read if you're curious about GL 3.2 extensions and porting DirectX/XNA applications to OpenGL. Does anyone know where to obtain an audio bootleg of the presentation?
Re: GL 3.2 machine
Only viewport clipping and triangle culling are running before the fragment shader is.
This is not entirely correct, Radeon 3xxx and Geforce 8xxx include "Early-Z" which may discard fragments before execution of the fragment shader under certain circumstances. However this is not exposed in OpenGL or DirectX and works behind the scenes, so it does not belong into the diagram.
Re: GL 3.2 machine
I think early-Z is supported as far back as the initial GLSL capable cards (R300 and FX 5x00 series).
Early-Z is why it's highly beneficial to do a z-only pass before rendering any complex shaders. Note that if your fragment shader discards any fragments, early-Z will be disabled for the current pass and all subsequent passes.
Re: GL 3.2 machine
Not sure about availability, but Hierarchical-Z, Early-Z and the likes needed to be mentioned. Besides the shader itself, the state set by GL.DepthMask(false) appears to be the toggle that enables these optimizations. However this is not part of GL spec and will not become part of the diagram, but I wanted to clarify my not-entirely-correct statement.