marsultor/learn-wgpu
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: fix pipeline stage ordering per WebGPU/Vulkan spec

Browse Source
This commit is contained in:
Krishna Ayyalasomayajula
2026-05-30 20:17:09 -05:00
parent d7fc299d5a
commit 7f47641fdb
1 changed files with 11 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
docs/concepts/graphics-pipeline.md
View File

@@ -43,7 +43,17 @@ The GPU takes vertices in the order you submitted them and groups them into [[pr
### Stage 3: Rasterizer ### Stage 3: Rasterizer
[[rasterizer]](GLOSSARY.md#rasterizer) — hardware stage that converts triangles into fragments. > **Note:** The 5-stage model above is a simplification for conceptual clarity. The actual WebGPU and Vulkan pipelines define 11+ stages, including fixed-function vertex post-processing stages between the programmable stages. This section covers the essential stages relevant to writing shaders and configuring pipelines.
Before rasterization proper, the GPU performs several fixed-function vertex post-processing steps on the clip-space positions output by the vertex shader:
- **Perspective Division:** The clip-space `vec4` position is divided by its `w` component, converting it to normalized device coordinates (NDC) in the range [-1, 1].
- **Clipping:** Primitives that fall entirely outside the NDC cube are discarded. Primitives that partially intersect are clipped and retriangulated.
- **Viewport Transform:** NDC coordinates are mapped to window pixel coordinates based on the configured viewport dimensions.
These stages are automatic and happen in hardware. You do not write code for them.
Then the [[rasterizer]](GLOSSARY.md#rasterizer) takes over — the hardware stage that converts triangles into fragments.
For each submitted triangle, the rasterizer determines which screen pixels the triangle covers. For each covered pixel, it generates one [[fragment]](GLOSSARY.md#fragment) — a "potential pixel" carrying interpolated data. For each submitted triangle, the rasterizer determines which screen pixels the triangle covers. For each covered pixel, it generates one [[fragment]](GLOSSARY.md#fragment) — a "potential pixel" carrying interpolated data.
@@ -69,8 +79,6 @@ Per-fragment operations:
- **Stencil test:** Mask drawing to specific screen regions via a stencil buffer. We disable this. - **Stencil test:** Mask drawing to specific screen regions via a stencil buffer. We disable this.
- **Blend:** Combine the new fragment color with the existing framebuffer color. We use REPLACE — the fragment color overwrites whatever was there. - **Blend:** Combine the new fragment color with the existing framebuffer color. We use REPLACE — the fragment color overwrites whatever was there.
Before the output merge, the GPU performs the [[viewport transform]](GLOSSARY.md#viewport-transform): mapping NDC coordinates to window pixel dimensions. This step is automatic and configured by your surface dimensions.
After the output merge, the final color is written to the framebuffer. When you [[load op]](GLOSSARY.md#loadop) is `Clear`, the framebuffer is filled with your background color before the render pass begins. [[Storeop]](GLOSSARY.md#storeop) determines whether you keep or discard the results after the render pass. After the output merge, the final color is written to the framebuffer. When you [[load op]](GLOSSARY.md#loadop) is `Clear`, the framebuffer is filled with your background color before the render pass begins. [[Storeop]](GLOSSARY.md#storeop) determines whether you keep or discard the results after the render pass.
## Why This Matters For The Rainbow Triangle ## Why This Matters For The Rainbow Triangle