Thread

Testing WebGPU data layouts with Facet

78 points · 6 comments · luu

Loading the complete thread in the background. This saved snapshot is available now. Refresh

brinepot · 1790763683 · focus · HN ↗
Spent too much time debugging alignment issues with Vulkan buffers. WebGPU having good tools like Facet from the start is a huge win.
jauntywundrkind · 1790764016 · focus · HN ↗
This is so good. And it's so absurd how programming languages so frequently treat types as a compile time check. Still. After so so long.
It's great having tools like Facet around to add runtime type information in. I wish TypeScript was seeing progress but there's seemingly no progress or traction in 5 years+, just some early experiments which died out.
flohofwoe · 1790765356 · focus · HN ↗
FWIW, there's a WebGPU extension which 'harmonizes' uniform buffer struct layout with other address spaces, but currently it's only implemented in Chromium-based browsers:
Ticket: <a href="https://github.com/gpuweb/gpuweb/issues/4973" rel="nofollow">https://github.com/gpuweb/gpuweb/issues/4973
Caniuse: <a href="https://caniuse.com/?search=uniform_buffer_standard_layout" rel="nofollow">https://caniuse.com/?search=uniform_buffer_standard_layout
The std140-style layout restrictions are basically a leftover when GPUs used vec4 "register tables" for uniform data.
1. mkeeter · 1790771941 · focus · HN ↗
  Nice, I'll keep an eye on that!
  Right now, I'm targeting everything (native / Firefox / Chrome / Safari), so minimizing use of extensions; this also means I get to run head-long into fun cross-platform behavior differences [1][2][3]
  [1] <a href="https://github.com/gfx-rs/wgpu/issues/8785" rel="nofollow">https://github.com/gfx-rs/wgpu/issues/8785
  [2] <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1870699" rel="nofollow">https://bugzilla.mozilla.org/show_bug.cgi?id=1870699
  [3] <a href="https://github.com/mkeeter/halfspace/issues/1#issuecomment-3593059692" rel="nofollow">https://github.com/mkeeter/halfspace/issues/1#issuecomment-3...
77rushi77 · 1790765815 · focus · HN ↗
[dead]
genxy · 1790773153 · focus · HN ↗
> facet is a library for Rust which provides run-time reflection. By annotating your struct with #[derive(facet::Facet)], you get a SHAPE associated type which can be inspected at runtime.
<a href="https://github.com/facet-rs/facet" rel="nofollow">https://github.com/facet-rs/facet
> The core crates give types a SHAPE associated constant with their kind, layout, fields, documentation, attributes, and type-specific operations. facet-reflect builds, reads, and mutates values through those shapes while preserving their invariants.
> Serialization and integration crates build on that reflection layer: JSON, TOML, YAML, MessagePack, Postcard, ASN.1, XDR, CSV, XML, URL-encoded forms, SQLite, Axum, schema generation, structural diffing, and more.
Side by side comparison with SERDE <a href="https://facet.rs/guide/serde/" rel="nofollow">https://facet.rs/guide/serde/
scoopr · 1790775379 · focus · HN ↗
Nice, always good to have some extra checking.
While most of the time you want the memcpy semantics, but I wonder if naga could be used to compute a facet SHAPE from the shader. Maybe it could be used to "serialise" the cpu format to gpu format, without them needing to be padding/repr-compatible (or even field-reorder-compatible!).
Another option of course would be to parse the struct with naga and just always generate the rust counterpart, then it should always be compatible and up-to-date, but then you have codegen in your build step.
flipflowdev · 1790781426 · focus · HN ↗
[dead]
xyzsparetimexyz · 1790850987 · focus · HN ↗
An even better approach is to have a proc macro that parses wgsl and writes the rust struct definitions for you. That way this failure case can't happen.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.