gpu-rendering-guidelisted

# GPU Rendering Guidelines (Explicit-API Architecture) API-agnostic architecture for a low-level GPU renderer. The concepts hold across explicit APIs (Vulkan, D3D12, Metal, WebGPU); names differ but the model is the same. For one API's concrete how-to use the matching API skill (e.g. **gpu-rendering-vulkan-guide**); for the general allocator principle behind GPU memory, see **memory-management-guide**. ## Requirements - Target an explicit, low-level API where the app owns memory, synchronization, and pipeline state, not a driver that hides them. - Assume validation/debug layers and a frame debugger are available during development. ## Essentials - **Declare, don't sequence** - Passes declare resource reads/writes; the graph derives order, barriers, and layout transitions, see [references/render-graph.md](references/render-graph.md) - **Shaders are build artifacts** - Author → compile to a binary intermediate offline → reflect for layouts, see [references/shader-system.md](references/shader-system.md) - **You own GPU memory** - Sub-allocate from a few large blocks; never one allocation per resource, see [references/gpu-memory-strategy.md](references/gpu-memory-strategy.md) - **You own synchronization** - Nothing is implicit; barriers, queue waits, and fences are explicit, see [references/synchronization.md](references/synchronization.md) ## Architecture - **Render graph** - Per-frame DAG that prunes dead passes, orders work, and aliases transient targets, see [reference