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

Expose readonly size/usage on wgpu::Buffer #2904

Closed
swiftcoder opened this issue Jul 21, 2022 · 2 comments · Fixed by #2923
Closed

Expose readonly size/usage on wgpu::Buffer #2904

swiftcoder opened this issue Jul 21, 2022 · 2 comments · Fixed by #2923
Labels
area: api Issues related to API surface good first issue Good for newcomers help required We need community help to make this happen. type: enhancement New feature or request

Comments

@swiftcoder
Copy link
Contributor

Is your feature request related to a problem? Please describe.

Per the draft spec, it appears that GPUBuffer is supposed to expose it's size and usage via readonly properties:
https://gpuweb.github.io/gpuweb/#buffer-interface

As of wgpu-rs 0.13.1, on the rust side neither of these properties are currently visible to application code. Also the wgpu::Buffer type doesn't appear to be caching the size at all.

Describe the solution you'd like

Keep a cached copy of the size on wgpu::Buffer, and expose member functions to provide readonly access to both the size and usage fields.

Describe alternatives you've considered

The application can always track these attributes externally, since they are immutable after construction, but I'd hate to permanently incur that added burden on application code.

@cwfitzgerald cwfitzgerald added type: enhancement New feature or request help required We need community help to make this happen. good first issue Good for newcomers area: api Issues related to API surface labels Jul 21, 2022
@kpreid
Copy link
Contributor

kpreid commented Jul 21, 2022

I've heard that WebGPU and/or wgpu intentionally don't provide “getters” for most state, so that the data flow is primarily CPU-to-GPU without ever pausing to fetch data back or requiring wgpu to speculatively retain information in case it is needed.

However, even not considering that the spec does specify to expose buffer sizes, they would be especially useful, because whenever a buffer has dynamically sized contents, it may be useful to understand the buffer's size as a “capacity” (in the sense of Vec::capacity()), potentially use less than all of the buffer, and consult the size to determine whether allocating a new buffer is necessary.

@swiftcoder
Copy link
Contributor Author

and consult the size to determine whether allocating a new buffer is necessary.

Yep, that's exactly the case I'm running into. I have an unpredictable number of mesh instances, and the instance data buffer sometimes needs to grow to accommodate additional instances

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: api Issues related to API surface good first issue Good for newcomers help required We need community help to make this happen. type: enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants