Conversation
| data_ptr, | ||
| mem::align_of::<f32>() as u64, | ||
| vertex_buffer_mem_requirements.size, | ||
| ); |
There was a problem hiding this comment.
Align isn't doing anything useful here.
There was a problem hiding this comment.
What do you recommend instead? I did it this way because this is what I saw in the ash examples. (and I changed it again to use vertex_buffer_mem_requirements.alignment for the second argument in the force push I just did but I suspect that may have been incorrect after doing some more research)
There was a problem hiding this comment.
You shouldn't need to do anything special at all. Memory allocated according to the requirements of a vertex buffer will necessarily satisfy the buffer's GPU-side alignment requirements. I believe the CPU-side alignment should also be implicitly satisfied. Writing data starting at any location other than the start of the buffer, or with a non-dense stride, would constitute a mismatch with the vertex attribute layout declared in the pipeline.
There was a problem hiding this comment.
(unfortunately the ash examples, and indeed most introductory vulkan examples, aren't great; there's a PR in need of review to improve them)
There was a problem hiding this comment.
Would it be sound to construct an &mut [T] from gpu memory or should I always go through ptr:;write?
There was a problem hiding this comment.
I see Align does create a slice but my concern is that the data in the buffer may not be valid for reads. I think I'll use std::ptr::copy for now.
There was a problem hiding this comment.
Creating a slice to uninitialized memory would be unsound, yeah. copy_nonoverlapping should be preferred.
7770d9f to
61c7938
Compare
Example now renders in 3D using the tracked HMD position and shows cubes at the location of each hand controller.
Example now renders in 3D using the tracked HMD position and shows cubes at the location of each hand controller.