-
-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
[Merged by Bors] - Documenting BufferVec
.
#4673
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.
Excellent, these are looking good. Ping @bevyengine/rendering-team for a second review.
@superdump Could you give this a second review? (not able to ping the bevy rendering-team) |
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 for contributing some much-needed clarification! I've tweaked a few bits.
/// for the [`RenderDevice`](crate::renderer::RenderDevice). | ||
/// | ||
/// "Properly formatted" means data that is [`#[repr(C)]`](https://doc.rust-lang.org/reference/type-layout.html#the-c-representation), [`Pod`] | ||
/// and `Zeroable`. Unlike the [`DynamicUniformVec`](crate::render_resource::DynamicUniformVec), |
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.
Note that since we now use encase
, the helper types were renamed to UniformBuffer
, DynamicUniformBuffer
, StorageBuffer
, and DynamicStorageBuffer
. I think I have made the necessary changes in the suggestion below.
/// If a [`Buffer`](crate::render_resource::Buffer) exists, but is too small, references to it will be discarded, | ||
/// and a new [`Buffer`](crate::render_resource::Buffer) will be created. Any previously created [`Buffer`](crate::render_resource::Buffer)s | ||
/// that are no longer referenced will be deleted by the [`RenderDevice`](crate::renderer::RenderDevice) | ||
/// once it is done using them (typically 1-2 frames). |
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.
Nice attention to detail!
Co-authored-by: Robert Swain <robert.swain@gmail.com>
…w being merged. Co-authored-by: Robert Swain <robert.swain@gmail.com>
…ce memory" Co-authored-by: Robert Swain <robert.swain@gmail.com>
@superdump Thanks for the review! (and for including commit suggestions instead of just comments :D that made it much easier to integrate the changes!) |
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.
With this minor mistake, LGTM.
Co-authored-by: Robert Swain <robert.swain@gmail.com>
bors r+ |
# Objective Documents the `BufferVec` render resource. `BufferVec` is a fairly low level object, that will likely be managed by a higher level API (e.g. through [`encase`](#4272)) in the future. For now, since it is still used by some simple example crates (e.g. [bevy-vertex-pulling](https://github.com/superdump/bevy-vertex-pulling)), it will be helpful to provide some simple documentation on what `BufferVec` does. ## Solution I looked through Discord discussion on `BufferVec`, and found [a comment](https://discord.com/channels/691052431525675048/953222550568173580/956596218857918464 ) by @superdump to be particularly helpful, in the general discussion around `encase`. I have taken care to clarify where the data is stored (host-side), when the device-side buffer is created (through calls to `reserve`), and when data writes from host to device are scheduled (using `write_buffer` calls). --- ## Changelog - Added doc string for `BufferVec` and two of its methods: `reserve` and `write_buffer`. Co-authored-by: Brian Merchant <bhmerchant@gmail.com>
Build failed: |
@bzm3r can you please format this? I'd like to merge it :) |
/// so this helper type is a good choice for them. Uniform buffers must adhere to std140 | ||
/// alignment/padding requirements, and storage buffers to std430. There are helper types for such | ||
/// buffers: | ||
/// - Uniform buffers |
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.
One small usability nit: Please update these other types' docs to point back to this more detailed one.
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.
What do you mean? Over at UniformBuffer add a link to here? Or you mean for each of the helpers, link to the others?
I definitely think we should have some bevy book docs for how to get data into your shader, and how to decide which way is appropriate for your needs.
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.
Over at UniformBuffer add a link to here?
This was my understanding, and what I would like to see.
We're going to document the bors r+ |
# Objective Documents the `BufferVec` render resource. `BufferVec` is a fairly low level object, that will likely be managed by a higher level API (e.g. through [`encase`](#4272)) in the future. For now, since it is still used by some simple example crates (e.g. [bevy-vertex-pulling](https://github.com/superdump/bevy-vertex-pulling)), it will be helpful to provide some simple documentation on what `BufferVec` does. ## Solution I looked through Discord discussion on `BufferVec`, and found [a comment](https://discord.com/channels/691052431525675048/953222550568173580/956596218857918464 ) by @superdump to be particularly helpful, in the general discussion around `encase`. I have taken care to clarify where the data is stored (host-side), when the device-side buffer is created (through calls to `reserve`), and when data writes from host to device are scheduled (using `write_buffer` calls). --- ## Changelog - Added doc string for `BufferVec` and two of its methods: `reserve` and `write_buffer`. Co-authored-by: Brian Merchant <bhmerchant@gmail.com>
BufferVec
.BufferVec
.
# Objective Documents the `BufferVec` render resource. `BufferVec` is a fairly low level object, that will likely be managed by a higher level API (e.g. through [`encase`](bevyengine#4272)) in the future. For now, since it is still used by some simple example crates (e.g. [bevy-vertex-pulling](https://github.com/superdump/bevy-vertex-pulling)), it will be helpful to provide some simple documentation on what `BufferVec` does. ## Solution I looked through Discord discussion on `BufferVec`, and found [a comment](https://discord.com/channels/691052431525675048/953222550568173580/956596218857918464 ) by @superdump to be particularly helpful, in the general discussion around `encase`. I have taken care to clarify where the data is stored (host-side), when the device-side buffer is created (through calls to `reserve`), and when data writes from host to device are scheduled (using `write_buffer` calls). --- ## Changelog - Added doc string for `BufferVec` and two of its methods: `reserve` and `write_buffer`. Co-authored-by: Brian Merchant <bhmerchant@gmail.com>
# Objective Documents the `BufferVec` render resource. `BufferVec` is a fairly low level object, that will likely be managed by a higher level API (e.g. through [`encase`](bevyengine#4272)) in the future. For now, since it is still used by some simple example crates (e.g. [bevy-vertex-pulling](https://github.com/superdump/bevy-vertex-pulling)), it will be helpful to provide some simple documentation on what `BufferVec` does. ## Solution I looked through Discord discussion on `BufferVec`, and found [a comment](https://discord.com/channels/691052431525675048/953222550568173580/956596218857918464 ) by @superdump to be particularly helpful, in the general discussion around `encase`. I have taken care to clarify where the data is stored (host-side), when the device-side buffer is created (through calls to `reserve`), and when data writes from host to device are scheduled (using `write_buffer` calls). --- ## Changelog - Added doc string for `BufferVec` and two of its methods: `reserve` and `write_buffer`. Co-authored-by: Brian Merchant <bhmerchant@gmail.com>
# Objective Documents the `BufferVec` render resource. `BufferVec` is a fairly low level object, that will likely be managed by a higher level API (e.g. through [`encase`](bevyengine#4272)) in the future. For now, since it is still used by some simple example crates (e.g. [bevy-vertex-pulling](https://github.com/superdump/bevy-vertex-pulling)), it will be helpful to provide some simple documentation on what `BufferVec` does. ## Solution I looked through Discord discussion on `BufferVec`, and found [a comment](https://discord.com/channels/691052431525675048/953222550568173580/956596218857918464 ) by @superdump to be particularly helpful, in the general discussion around `encase`. I have taken care to clarify where the data is stored (host-side), when the device-side buffer is created (through calls to `reserve`), and when data writes from host to device are scheduled (using `write_buffer` calls). --- ## Changelog - Added doc string for `BufferVec` and two of its methods: `reserve` and `write_buffer`. Co-authored-by: Brian Merchant <bhmerchant@gmail.com>
# Objective Documents the `BufferVec` render resource. `BufferVec` is a fairly low level object, that will likely be managed by a higher level API (e.g. through [`encase`](bevyengine#4272)) in the future. For now, since it is still used by some simple example crates (e.g. [bevy-vertex-pulling](https://github.com/superdump/bevy-vertex-pulling)), it will be helpful to provide some simple documentation on what `BufferVec` does. ## Solution I looked through Discord discussion on `BufferVec`, and found [a comment](https://discord.com/channels/691052431525675048/953222550568173580/956596218857918464 ) by @superdump to be particularly helpful, in the general discussion around `encase`. I have taken care to clarify where the data is stored (host-side), when the device-side buffer is created (through calls to `reserve`), and when data writes from host to device are scheduled (using `write_buffer` calls). --- ## Changelog - Added doc string for `BufferVec` and two of its methods: `reserve` and `write_buffer`. Co-authored-by: Brian Merchant <bhmerchant@gmail.com>
Objective
Documents the
BufferVec
render resource.BufferVec
is a fairly low level object, that will likely be managed by a higher level API (e.g. throughencase
) in the future. For now, since it is still used by some simpleexample crates (e.g. bevy-vertex-pulling), it will be helpful
to provide some simple documentation on what
BufferVec
does.Solution
I looked through Discord discussion on
BufferVec
, and found a comment by @superdump to be particularly helpful, in the general discussion aroundencase
.I have taken care to clarify where the data is stored (host-side), when the device-side buffer is created (through calls to
reserve
), and when data writes from host to device are scheduled (usingwrite_buffer
calls).Changelog
BufferVec
and two of its methods:reserve
andwrite_buffer
.