Module wgpu 

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 most 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 prelude — use pebble::wgpu::prelude::*; — rather than reaching straight for backend.device.create_*/wgpu::*Descriptor: the binding and buffers modules it re-exports are all builders (BindGroupLayoutBuilder, BufferBuilder, BindGroupBuilder, …) — chained .method(...) calls that fold in bookkeeping (duplicate @binding(N) detection, dynamic-offset alignment) a hand-written descriptor won’t give you for free.

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.

buffers

Buffer and bind-group construction — three builders, one per thing being built:

compute

cubemap

instance

layout

material

mesh

mipmap

prelude

use pebble::wgpu::prelude::*; for everything needed to construct 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 MaterialDescriptor/ ComputeDescriptor.

samplers

texture_array

textures

window