Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use Encase's Layouting Independent of Uploading #16

Open
cwfitzgerald opened this issue Aug 22, 2022 · 6 comments
Open

Use Encase's Layouting Independent of Uploading #16

cwfitzgerald opened this issue Aug 22, 2022 · 6 comments

Comments

@cwfitzgerald
Copy link

cwfitzgerald commented Aug 22, 2022

In rend3's vertex pulling rewrite I need to deal with sparse updates of buffers a lot. Because of that I'm not actually writing out the entire buffer all at once. I end up uploading individual items that changed into the byte offsets into the buffer they are supposed to be.

I would love to have a definition like this:

#[derive(ShaderType)]
pub struct DirectionalLightShader {
    header: DirectionalLightHeader,
    #[runtime]
    lights: Vec<DirectionalLight>,
}

But because I can't upload the whole thing at once, I can't actually just use WriteInto here. What I would love is an API that would give me an offset into the structure for a given member. Maybe something like

/// Raw Value because it's just a plain member
let offset: u64 = DirectionalLightShader::Offsets::HEADER
/// Vectors require you to give the index to get the full index
let offset: u64 = DirectionalLIghtShader::Offsets::LIGHTS::index(2);

This would let me use encase's layout even though I need my own custom weird layout system. Not at all attached to the syntax, just what it would let me accomplish.

@teoxoy
Copy link
Owner

teoxoy commented Aug 23, 2022

Could you point me at some code that would use this? Is this for the sparse copy compute shader you are using (where you write the new data in a new buffer and then copying it in the proper spots in the destination buffer)?

@cwfitzgerald
Copy link
Author

cwfitzgerald commented Aug 25, 2022

Yeah that's the intended use case - using sparse copies to update a buffer that is laid out like https://github.com/BVE-Reborn/rend3/blob/trunk/rend3-routine/shaders/src/structures.wgsl#L48-L51. The above struct is what I ideally would be the equivalent encase declaration.

@fayalalebrun
Copy link

I am writing a particle physics simulator and this would also be very useful for me. I have several very large arrays of structs on GPU memory, and I need to write to a few elements at a time, sometimes even just a single field of a struct. It is also desirable to get the value that was stored there previously, though that would probably happen on the next frame.

@teoxoy
Copy link
Owner

teoxoy commented May 6, 2023

Actually, a variation of this feature should already be available. The ShaderType trait has an associated constant METADATA with offsets/stride.

Polishing this API would be a next step but I'd like to see how people use it first.

Let me know if you come up with something (using METADATA) that could provide a direction for the polished API.

cc @cwfitzgerald

@james7132
Copy link
Contributor

james7132 commented Mar 23, 2024

The actual Metadata structs I think aren't documented in any form. The latest version on doc.rs doesn't even show the METADATA constant on the trait.

I'm also interested in this as we're looking into preallocating buffer space for parallelizing buffer writes in Bevy (see bevyengine/bevy#12489)

@teoxoy
Copy link
Owner

teoxoy commented Mar 31, 2024

The metadata was meant to be internal to encase but it seems people are interested in exposing it somehow.

The main question is how would the API look like? I can see it looking quite differently depending on how it will be used.

It might be worth experimenting with an API outside encase (which would use the metadata) at first.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants