docs: fix pipeline and operations cross-reference anchors

This commit is contained in:
2026-05-30 20:47:23 -05:00
parent f9010f9234
commit a8c64e3643

View File

@@ -242,7 +242,7 @@ struct State {
(e.g., after a compositor restart or display hotplug), recovery requires
reconfiguring the swapchain with the window's live size — and that requires
holding a reference to the window itself.
- **`pipeline`** — the compiled [render pipeline](concepts/GLOSSARY.md#pipeline).
- **`pipeline`** — the compiled [render pipeline](concepts/GLOSSARY.md#pipeline-render).
A render pipeline is an immutable configuration combining a shader, a vertex
buffer layout, a primitive topology, and a color target setup. Switching pipelines mid-frame is expensive; most applications use a few
pipelines and change them between draw calls.
@@ -590,7 +590,7 @@ pre-blended with barycentric weights.
**`-> @location(0) vec4<f32>`** — The fragment shader must output at least one
color value at `@location(0)`. This number must match the corresponding color
target in the [render pipeline](concepts/GLOSSARY.md#pipeline) descriptor. The
target in the [render pipeline](concepts/GLOSSARY.md#pipeline-render) descriptor. The
return type is `vec4<f32>` — RGBA with linear-space components.
**`return vec4<f32>(input.vertex_color, 1.0);`** — Promotes the interpolated
@@ -718,7 +718,7 @@ let vertex_buffer = device.create_buffer_init(
## S6: Compiling the Render Pipeline
New concept: **the render pipeline is a compiled GPU configuration.** A
[render pipeline](concepts/GLOSSARY.md#pipeline) bundles every decision the GPU
[render pipeline](concepts/GLOSSARY.md#pipeline-render) bundles every decision the GPU
needs to execute a draw: which shaders to run, how to interpret vertex buffer
bytes, what [topology](concepts/GLOSSARY.md#topology) to use, whether to cull
back faces, what blend mode to apply, and where to write the output. Pipeline
@@ -1102,13 +1102,13 @@ color_attachments: &[Some(wgpu::RenderPassColorAttachment {
**`RenderPassColorAttachment` has exactly 4 fields:**
- **`view: &texture_view`** — the framebuffer we draw into. Must match the
color target format in the [render pipeline](concepts/GLOSSARY.md#pipeline).
color target format in the [render pipeline](concepts/GLOSSARY.md#pipeline-render).
- **`depth_slice: None`** — only used for 3D texture slices. Not applicable
to 2D rendering.
- **`resolve_target: None`** — only used for MSAA resolve. When multisampling
is active, the render pass writes to a multisampled buffer and resolves into
this target. We have no MSAA, so `None`.
- **`ops`** — [operations](concepts/GLOSSARY.md#render-pass) controlling load
- **`ops`** — [operations](concepts/GLOSSARY.md#operations) controlling load
and store behavior. Two sub-fields:
- **`load: LoadOp::Clear(color)`** — before drawing, fill the entire
framebuffer with this color. **This IS your background color.** Dark gray.
@@ -1133,7 +1133,7 @@ that pass the depth test). Useful for visibility-based culling.
### Binding State and Drawing
**`render_pass.set_pipeline(&self.pipeline)`** — Tells the GPU which
[render pipeline](concepts/GLOSSARY.md#pipeline) to use for subsequent
[render pipeline](concepts/GLOSSARY.md#pipeline-render) to use for subsequent
draw calls. The pipeline encapsulates the shader programs, vertex format,
primitive topology, and output configuration. Must be set before any draw call
in a render pass. Switching pipelines mid-pass is expensive and should be
@@ -1340,7 +1340,7 @@ each piece does:
Each layer adds a capability: driver connection, window binding, GPU selection,
resource management, and swapchain allocation.
- **The [render pipeline](concepts/GLOSSARY.md#pipeline):** Shaders,
- **The [render pipeline](concepts/GLOSSARY.md#pipeline-render):** Shaders,
topology, and vertex layout compiled into a GPU configuration. Created once,
reused every frame. Expensive to create, cheap to execute.