Skip to main content

Module wgpu

Module wgpu 

Source
Expand description

A ready-to-use wgpu Backend implementation (backend::WGPUPlugin), plus a higher-level descriptor-based material/mesh/texture/compute layer built on top of it so apps never touch raw wgpu types directly.

Building something this layer doesn’t already cover (a camera, a custom compute buffer, anything constructed by hand inside a LazyResource/ Asset impl)? Start with preludeuse pebble::wgpu::prelude::*; — rather than reaching for a hand-written wgpu::*Descriptor: the binding and buffers modules it re-exports are all builders (BindGroupLayoutBuilder, BufferBuilder, BindGroupBuilder, …) producing opaque types (buffer::Buffer, textures::GPUTexture, samplers::Sampler, material::RenderPipeline, buffers::BindGroup, …) instead of raw wgpu ones — chained .method(...) calls that fold in bookkeeping (duplicate @binding(N) detection, dynamic-offset alignment) a hand-written descriptor won’t give you for free.

Pass and dispatch recording are opaque too: ActiveFrame::begin_pass hands back a render_pass::RenderPass (not a raw wgpu::RenderPass), and WGPUBackend::create_command_encoder/ CommandEncoder::compute_pass cover standalone compute dispatch the same way. WGPUBackend’s device/queue/surface fields are pub(crate) — every builder here takes &WGPUBackend directly instead — and even the value types (texture formats, shader stages, buffer/texture usage flags, blend and depth/stencil state, vertex formats) are mirrored as Pebble’s own types (texture_format::TextureFormat, flags::ShaderStages, …) rather than re-exporting wgpu’s. Nothing in this module’s public surface names a raw wgpu::* type.

Modules§

backend
binding
Shared bind-group vocabulary for material and compute — a material’s own bind group and a compute pass’s own bind group are described the same way, differing only in which shader stage(s) can see each entry (a material entry can be FRAGMENT/VERTEX/VERTEX_FRAGMENT; a compute entry is always exactly COMPUTE). Every constructor below takes visibility explicitly rather than guessing a default per module — build_material/ build_compute validate it’s appropriate for the pipeline kind they’re building, panicking with a clear message otherwise.
buffer
buffers
Buffer and bind-group construction — three builders, one per thing being built:
compute
compute_pass
cubemap
flags
Hand-rolled bitflag mirrors for wgpu’s flag-style types — small enough (at most a couple dozen bits) that pulling in the bitflags crate isn’t worth it. Each mirrors its wgpu counterpart’s bit layout exactly, so converting into wgpu is just from_bits_truncate.
instance
layout
material
mesh
mipmap
prelude
use pebble::wgpu::prelude::*; for everything needed to construct and render custom GPU resources against a WGPUBackend — a camera’s uniform buffer, a compute pass’s storage buffers, anything built by hand inside a LazyResource or Asset impl that isn’t already covered by Material/ Compute.
render_bundle
render_pass
samplers
texture_array
texture_format
Mirrors wgpu::TextureFormat exactly (every variant, including the nested Astc block/channel), so a texture’s format never needs a raw wgpu::TextureFormat — not even for exotic/compressed formats. Convert either direction via .into().
texture_view
textures
vertex_format
Mirrors wgpu::VertexFormat/VertexStepMode/VertexAttribute so a custom vertex struct’s layout (beyond the built-in Vertex/InstanceVertex) can be built with zero raw wgpu. Unlike wgpu::VertexBufferLayout (which borrows a 'static attribute slice), VertexBufferLayout owns its attributes — simpler to build, converted to wgpu’s borrowed shape internally by build_material in a scope that doesn’t need 'static.
window