Type safety

[andrewbaxter]

Hello! I've been hacking at the cube example. I just spent 2 hours where nothing was rendered... I thought I was going crazy since even checking every vertex/tex/index value against the example one by one nothing was different. It turned out the culprit was that I accidentally made the vertex index vec element type usize instead of u16 (implicitly, due to type deduction), and I have no idea what sort of memory accesses were going on but I guess they weren't right.

I have limited experience with graphics in general, but just looking at the interfaces it feels like this is probably a risk every time you use arrays/buffers/whatever. It kind of blindsided me since type safety is less of a problem in JS (my only recent experience) which only has 1 number type and apparently the webgl api is able to introspect and do the memory stuff correctly.

So... to get to the core of my question, is there any way I can make this a safe experience? Prevent crazy casting, check shader layout mismatches, get warned at compile time or, failing that, at runtime?

TBH I've been looking to dig in here for a long time, and I had previously looked at Vulkano, but I'm not really sure which library I need and since this seemed like the most popular I thought I'd start here.

[andrewbaxter]

Okay, after getting over that speed bump I'm getting lots of other errors so I think the answer is that it's pretty type safe.

I reread the readme and it does mention "safe", but what does that mean? Is the usize vs u16 issue above a bug? There's other stuff, like array stride, where the api (I assume) prioritizes speed over safety (1d array vs nested arrays, or some type that encodes multi dimensions), etc.

[SludgePhD]

"Safe" means "memory-safe", in the sense that nothing will corrupt the host process' memory, and that no undefined behavior can occur (at least that's the goal).

Communication between the host and device happens via buffers that are just treated as bags-of-bytes by WebGPU, so both sides have to agree on the specific format of those bytes, and that's the problem you were running into.

And yeah, this does mean that this part of the API isn't very type-safe. You can either write your own layer on top of wgpu that adds type safety on top of its raw buffers, or use something like encase to do it for you.

[andrewbaxter]

Oh thanks! I hadn't heard of encase, that sounds very relevant! I'll check it out.

What you said makes a lot of sense. Do you know if this is the official project stance? I think you're probably right in any case...

[andrewbaxter]

Ah, I found a similar issue here: #5470

The argument is that buffers hold arbitrary byte data, so any type checks would prevent some use case. I guess this is based on the fact that the analysis is one-sided (i.e. the rust has no idea what the shader code is doing). IIUC rust reads/writes data but has no idea how it's being used, the shader reads/writes data and just assumes it's in the right format, and naga also just checks internal consistency? There's no extra metadata passed between rust and naga?

It looks like encase on the other hand checks internal consistency on the rust side (offsets, alignment, stride, etc) but again without correspondence on the shader side... IIUC.

So with naga and encase, you can get rid of data layout/access errors but there's still the possibility of doing correctly structured accesses on the wrong structure in the shader/rust code.

[andrewbaxter]

Ah, encase wouldn't help with my original usize issue - it doesn't support u16 and instructs to use bytemuck for that case: teoxoy/encase#1

Edit: The use case of encase seems pretty limited. It doesn't help with texture sizes or types, it doesn't help with getting the right vertex format attributes for members of a struct or stride, and it seems to introduce some false negatives on stuff like Vecs (or maybe this is just an awkward interaction with wgpu).

[kpreid]

The argument is that buffers hold arbitrary byte data, so any type checks would prevent some use case.

In particular, it can be desirable to store multiple types of data in one buffer (sometimes called "sub-allocation"), to have less overhead from buffer management, so having a type system that works only for “this buffer contains only (vertex|index|uniform) data matching this struct” is undesirable. Now, this doesn't actually prevent all possible type checking systems — just like in Rust where you can store other data types in a Vec<MaybeUninit<u8>> if you want to. But the point of #5470 as I see it is that the space hasn't been explored enough to build one particular solution into wgpu — yet.

The way to improve the situation would be to write and/or use libraries and modules that do offer some sort of type safety for buffers. You can start small — for example, I have a little wrapper type in my graphics code that wraps a byte slice to allow a typed push into it:

/// Wraps a byte slice to present a `Vec::push()`-like interface.
#[derive(Debug)]
pub(crate) struct MapVec<'buf, T> {
    unwritten: &'buf mut [u8],
    len: usize,
    _phantom: PhantomData<fn(&T)>,
}

impl<'buf, T: bytemuck::NoUninit> MapVec<'buf, T> {
    pub fn new(buffer: &'buf mut [u8]) -> Self {
        Self {
            unwritten: buffer,
            len: 0,
            _phantom: PhantomData,
        }
    }

    /// Returns the number of elements pushed so far.
    pub fn len(&self) -> usize {
        self.len
    }

    /// Push an element if possible, and return whether there was room to do so.
    #[must_use]
    pub fn push(&mut self, value: &T) -> bool {
        let Some(to_write) = self.unwritten.split_off_mut(..size_of::<T>()) else {
            return false;
        };
        to_write.copy_from_slice(bytemuck::bytes_of(value));
        self.len += 1;
        true
    }
}

This is a small step towards more type safety; it doesn't provide any way to ensure the slice passed to new() should have Ts written into it, but that could be added. Lots of small steps, and seeing how they work in practice, can add up to a complete solution. Write abstractions based on experience. Don’t let “there isn’t already a solution for everything” stop you from making your own improvements to your actual situation.

[andrewbaxter]

In particular, it can be desirable to store multiple types of data in one buffer (sometimes called "sub-allocation")

IIUC this is referring to the custom memory allocator stuff that was a point of vulkan?

[andrewbaxter]

Ah! Here on the other hand it the project aims for complete safety (although maybe they also only mean WRT invalid memory accesses) https://github.com/gfx-rs/wgpu/wiki/Debugging-wgpu-Applications - this references area: validation Issues related to validation, diagnostics, and error handling

So... it is a goal, but it's not a cornerstone of the project so it's WIP?

[andrewbaxter]

I just found wgsl_bindgen which seems like a much more integrated alternative to encase. It removes a ton of the tightly coupled parameters based on shader meta from naga. I don't think it handles texture layout. I'm still poking at it to see what it all does, but it seems like exactly the sort of type-safe low-level abstraction over wgpu I was looking for.