Modulevulkan-utils-0.5.11.0Haskell2010

Vulkan.Utils.RenderPass

The classic render-pass drawing path: a RenderPass over one or more colour attachments (and an optional depth attachment), framebuffers over the swapchain image views, and a vanilla pipeline that targets the render pass.

This is one of two self-contained alternatives — see Vulkan.Utils.DynamicRendering for the VK_KHR_dynamic_rendering path, which needs neither a render pass nor framebuffers. Pick one and import only it.

1 type
4 values

Packagevulkan-utils-0.5.11.0
Exports5
LanguageHaskell2010
LicenceBSD-3-Clause
SourceRenderPass.hs

Render pass

2 declarations

valueallocateRenderPass

:: MonadResource m
=> Device
-> Vector (Format, ImageLayout)
Colour attachments: (format, finalLayout).
-> Maybe Format
Optional depth attachment format.
-> m (ReleaseKey, RenderPass)

A render pass with colors colour attachments (each (format, finalLayout)) and an optional depth attachment, all cleared on load and stored on completion, in a single graphics subpass. Attachment indices are the colours 0..N-1 then the depth attachment at N — the colour-then-depth order the framebuffer's attachments must follow. The external dependency synchronizes colour output and, when present, the depth fragment tests.

valueallocateColorRenderPass

:: MonadResource m
=> Device
-> Format
Color attachment format.
-> ImageLayout
Final layout.
-> m (ReleaseKey, RenderPass)

The single-colour render pass: one attachment cleared on load and stored, ending in finalLayout (e.g. PRESENT_SRC_KHR for swapchains, TRANSFER_SRC_OPTIMAL for offscreen images). The common special case of allocateRenderPass.

Pipeline

3 declarations

datadata PipelineConfig

Attachment + fixed-function knobs for a render-pass pipeline.

Construct with zero and override what differs, e.g. zero { RenderPass.colorFormats = [fmt], RenderPass.depthFormat = Just d }. The attachment shape — colorFormats count and whether depthFormat is present — MUST match the render pass; the formats themselves live in the render pass, so only the count and depth presence are read here.

Constructors

PipelineConfig
- colorFormats :: [Format]
  Colour attachment formats; only the count is read (must match the render pass).
- depthFormat :: Maybe Format
  Optional depth attachment; only its presence is read (must match the render pass).
- vertexInput :: PipelineVertexInputStateCreateInfo '[]
  Vertex input (bindings + attributes); zero for none.
- dynamicStates :: Maybe (Vector DynamicState)
  Dynamic states; Nothing defaults layout-aware (see Vulkan.Utils.DynamicState).
- layout :: Maybe PipelineLayout
  Pipeline layout for descriptor sets / push constants; Nothing uses a transient empty layout (shaders take no resources). A supplied layout stays owned by the caller, who must keep it alive for the pipeline's lifetime.

Instances1Zero

Zero PipelineConfigDefined in vulkan-utils-0.5.11.0 · Vulkan.Utils.RenderPass

valueallocatePipeline

:: (MonadResource m, MonadFail m)
=> Device
-> RenderPass
-> PipelineConfig
-> Vector (SomeStruct PipelineShaderStageCreateInfo)
-> m (ReleaseKey, Pipeline)

A vanilla vertex+fragment pipeline targeting renderPass (subpass 0). The PipelineConfig attachment shape MUST match renderPass. Whatever dynamic state is selected MUST be set before drawing. Intended to be used qualified, e.g. RenderPass.allocatePipeline.

valueallocatePipelineFromShaders

:: (MonadResource m, MonadUnliftIO m, MonadFail m, Specialization spec)
=> Device
-> RenderPass
-> PipelineConfig
-> spec
Specialization shared by every stage; () for none.
-> [(ShaderStageFlagBits, ByteString)]
-> m (ReleaseKey, Pipeline)

allocatePipeline from (stage, SPIR-V) pairs: compile each into a shader module, build the pipeline, then release the now-redundant module handles.

spec is one specialization shared by every stage (see Vulkan.Utils.Pipeline.Specialization); pass () for none.