-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Add GpuArrayBuffer and BatchedUniformBuffer #8204
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
code and comment quality is good. the code broadly looks right but i really need an example to kick it around properly. i don't think the feature needs an example in the repo but maybe you have something you've been using while building it that i could look at?
crates/bevy_render/src/render_resource/batched_uniform_buffer.rs
Outdated
Show resolved
Hide resolved
I have some messy code here that uses GpuList for MeshUniforms. If it's not helpful, I can write up a separate example. The next step after this PR will be to use GpuList for mesh MeshUniforms, and then materials. |
Reminder to myself that I need to add robswain to the commit authors. |
I kind of fixed the commit history... good enough ig? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a few small changes. Otherwise LGTM. I look forward to using this. :)
One nice to have though I'm not sure how to do it - it would be useful to have a nice shader abstraction for it. I suppose the shader side will be either:
var<uniform> my_list: array<T, #{T_BATCH_SIZE}>;
or
var<storage> my_list: array<T>;
but either way, the array will be indexed into, so the interface should be the same. So we need a way of setting the binding type to either uniform
or storage
, and if uniform then setting the array size. Currently I think one could do that like this:
#ifdef T_BATCH_SIZE
var<uniform> my_list: array<T, #{T_BATCH_SIZE}u>;
#else
var<storage> my_list: array<T>;
#endif
#[derive(Clone, Copy, Debug, Default, PartialEq, Eq, PartialOrd, Ord)] | ||
struct MaxCapacityArray<T>(T, usize); | ||
|
||
impl<T> ShaderType for MaxCapacityArray<T> | ||
where | ||
T: ShaderType<ExtraMetadata = ArrayMetadata>, | ||
{ | ||
type ExtraMetadata = ArrayMetadata; | ||
|
||
const METADATA: Metadata<Self::ExtraMetadata> = T::METADATA; | ||
|
||
fn size(&self) -> ::core::num::NonZeroU64 { | ||
Self::METADATA.stride().mul(self.1.max(1) as u64).0 | ||
} | ||
} | ||
|
||
impl<T> WriteInto for MaxCapacityArray<T> | ||
where | ||
T: WriteInto + RuntimeSizedArray, | ||
{ | ||
fn write_into<B: BufferMut>(&self, writer: &mut Writer<B>) { | ||
debug_assert!(self.0.len() <= self.1); | ||
self.0.write_into(writer); | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This code was written by @teoxoy so we need to add credit for them to the commit that introduces it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! If this is ready for production I can merge the branch in encase and do a release.
Let me know!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It works fine for us. :) There is that other aspect of being able to start the next dynamic offset binding of a uniform buffer at the next dynamic offset alignment if not all space is used, and ensure that the final binding is full-size. I don't know if that would clash with this and basically immediately deprecate this approach. If so maybe you'd prefer that we use a solution in bevy for what we need and add the long-term and more flexible solution to encase when someone gets to it. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I won't block the PR on this. We can figure it out over time. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried to rebase to give credit on the original commit but due to merges it was a pain. I instead added a comment and a co-authored-by so that when the squash merge is done, the credit will follow along with it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, we can further iterate and see what we come up with. Thanks for the credit!
Sadly we don't have a macro system (nor am I sure if we'd want one, those are easy to abuse...), so I'm not sure how we'd do that. Maybe some kind of custom thing in our shader parser, like this: var<gpu_list> my_list: GpuList<T>; that the parser replaces with the appropriate stuff, before passing it to naga. |
Co-authored-by: Robert Swain <robert.swain@gmail.com>
Co-authored-by: Robert Swain <robert.swain@gmail.com>
Co-authored-by: Robert Swain <robert.swain@gmail.com>
Co-authored-by: Robert Swain <robert.swain@gmail.com>
Co-authored-by: Robert Swain <robert.swain@gmail.com>
Co-authored-by: Robert Swain <robert.swain@gmail.com>
Co-authored-by: Robert Swain <robert.swain@gmail.com>
Co-authored-by: Robert Swain <robert.swain@gmail.com>
Co-authored-by: Robert Swain <robert.swain@gmail.com>
Co-authored-by: Robert Swain <robert.swain@gmail.com>
JMS55 confirmed on Discord that I can commit the two outstanding proposals and rebase this PR to get it merged as they are busy with other things at the moment. |
Co-authored-by: François <mockersf@gmail.com>
Haven't reviewed it yet, so might be missing context, but I do think I'd prefer GpuArrayBuffer. GpuList also confused me for the longest time when seeing the PR title and I didn't really look into it because I thought it was something about listing gpus. |
Due to popular demand, GpuList -> GpuArrayBuffer. I think this PR is ready to go now :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
couple of tiny nits, but otherwise LGTM
Co-authored-by: IceSentry <IceSentry@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's get this merged after this docs change, pending another approval.
crates/bevy_render/src/render_resource/batched_uniform_buffer.rs
Outdated
Show resolved
Hide resolved
crates/bevy_render/src/render_resource/batched_uniform_buffer.rs
Outdated
Show resolved
Hide resolved
Co-authored-by: robtfm <50659922+robtfm@users.noreply.github.com>
# Objective This is a minimally disruptive version of #8340. I attempted to update it, but failed due to the scope of the changes added in #8204. Fixes #8307. Partially addresses #4642. As seen in #8284, we're actually copying data twice in Prepare stage systems. Once into a CPU-side intermediate scratch buffer, and once again into a mapped buffer. This is inefficient and effectively doubles the time spent and memory allocated to run these systems. ## Solution Skip the scratch buffer entirely and use `wgpu::Queue::write_buffer_with` to directly write data into mapped buffers. Separately, this also directly uses `wgpu::Limits::min_uniform_buffer_offset_alignment` to set up the alignment when writing to the buffers. Partially addressing the issue raised in #4642. Storage buffers and the abstractions built on top of `DynamicUniformBuffer` will need to come in followup PRs. This may not have a noticeable performance difference in this PR, as the only first-party systems affected by this are view related, and likely are not going to be particularly heavy. --- ## Changelog Added: `DynamicUniformBuffer::get_writer`. Added: `DynamicUniformBufferWriter`.
# Objective This is a minimally disruptive version of bevyengine#8340. I attempted to update it, but failed due to the scope of the changes added in bevyengine#8204. Fixes bevyengine#8307. Partially addresses bevyengine#4642. As seen in bevyengine#8284, we're actually copying data twice in Prepare stage systems. Once into a CPU-side intermediate scratch buffer, and once again into a mapped buffer. This is inefficient and effectively doubles the time spent and memory allocated to run these systems. ## Solution Skip the scratch buffer entirely and use `wgpu::Queue::write_buffer_with` to directly write data into mapped buffers. Separately, this also directly uses `wgpu::Limits::min_uniform_buffer_offset_alignment` to set up the alignment when writing to the buffers. Partially addressing the issue raised in bevyengine#4642. Storage buffers and the abstractions built on top of `DynamicUniformBuffer` will need to come in followup PRs. This may not have a noticeable performance difference in this PR, as the only first-party systems affected by this are view related, and likely are not going to be particularly heavy. --- ## Changelog Added: `DynamicUniformBuffer::get_writer`. Added: `DynamicUniformBufferWriter`.
Objective
Vec<T>
to a GPUarray<T>
.Solution
BatchedUniformBuffer
to bevy main, as a fallback for WebGL2, which doesn't support storage buffers.array<T>
in a shader, you get anarray<T, N>
, and have to rebind every N elements via dynamic offsets.GpuArrayBuffer
to abstract overStorageBuffer<Vec<T>>
/BatchedUniformBuffer
.Future Work
Add a shader macro kinda thing to abstract over the following automatically: #8204 (review)
Changelog
GpuArrayBuffer
,GpuComponentArrayBufferPlugin
,GpuArrayBufferable
, andGpuArrayBufferIndex
types.DynamicUniformBuffer::new_with_alignment()
.