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
prelude — use 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
materialandcompute— 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 beFRAGMENT/VERTEX/VERTEX_FRAGMENT; a compute entry is always exactlyCOMPUTE). Every constructor below takesvisibilityexplicitly rather than guessing a default per module —build_material/build_computevalidate 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
bitflagscrate isn’t worth it. Each mirrors itswgpucounterpart’s bit layout exactly, so converting into wgpu is justfrom_bits_truncate. - instance
- layout
- material
- mesh
- mipmap
- prelude
use pebble::wgpu::prelude::*;for everything needed to construct and render custom GPU resources against aWGPUBackend— a camera’s uniform buffer, a compute pass’s storage buffers, anything built by hand inside aLazyResourceorAssetimpl that isn’t already covered byMaterial/Compute.- render_
bundle - render_
pass - samplers
- texture_
array - texture_
format - Mirrors
wgpu::TextureFormatexactly (every variant, including the nestedAstcblock/channel), so a texture’s format never needs a rawwgpu::TextureFormat— not even for exotic/compressed formats. Convert either direction via.into(). - texture_
view - textures
- vertex_
format - Mirrors
wgpu::VertexFormat/VertexStepMode/VertexAttributeso a custom vertex struct’s layout (beyond the built-inVertex/InstanceVertex) can be built with zero raw wgpu. Unlikewgpu::VertexBufferLayout(which borrows a'staticattribute slice),VertexBufferLayoutowns its attributes — simpler to build, converted to wgpu’s borrowed shape internally bybuild_materialin a scope that doesn’t need'static. - window