extensions/khr: Add VK_KHR_pipeline_binary extension#944
Conversation
e46d73b to
a97aa7d
Compare
a97aa7d to
0b62cd5
Compare
|
Our It's quite unfortunate that the |
69cf5ec to
dd71365
Compare
19c3eb3 to
7be4595
Compare
7be4595 to
83d7496
Compare
| /// Calls `f` at most twice until it does not return [`vk::Result::ERROR_NOT_ENOUGH_SPACE_KHR`], | ||
| /// ensuring all available binary data has been read into the vector. | ||
| /// | ||
| /// The first call happens with a [`Vec`] of capacity `4096`. If this is not adequate, `f` is |
There was a problem hiding this comment.
Not really a blocker, but I'd like to see some sort of reference for why we think 4KiB in particular makes sense here rather than, say, 128B, or 1MiB.
| count > data.capacity(), | ||
| "Implementation should have updated the value to be higher than the initial request" | ||
| ); | ||
| data.reserve(count); |
There was a problem hiding this comment.
Vec::reserve takes the number of additional bytes, so this will over-allocate. We should pass count - data.capacity() (probably via a temporary to keep borrowck happy).
| count > data.capacity(), | ||
| "Implementation should have updated the value to be higher than the initial request" | ||
| ); | ||
| data.reserve(count); |
There was a problem hiding this comment.
nit: We don't expect to reallocate this any further, so Vec::reserve_exact would be a little better.
No description provided.