-
Notifications
You must be signed in to change notification settings - Fork 190
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
extensions: Add VK_KHR_maintenance4 #489
Conversation
63af709
to
5dadadd
Compare
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.
Should we keep this function similar to get_image_sparse_memory_requirements2 (Vulkan 1.1) with just an out: &mut [] array and separate _len function?
I think it's best to be consistent there, yeah.
5dadadd
to
c9d50f9
Compare
&mut count, | ||
out.as_mut_ptr(), | ||
); | ||
assert_eq!(count, out.len() as u32); |
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.
@Ralith I slipped in an assert_eq
here without mentioning. I have a change locally to apply this to the other functions of this sort - do you think it's worth adding that everywhere consistently?
It seems very unlikely for this to ever change, hence an assert might be a good idea in the strange event that a driver happens to overwrite it after all (ie. playing around with beta drivers etc).
Originally introduced in [#489] this inserts the array-length equality check everywhere else: in the supposedly invalid and inexistant event where Vulkan suddenly returns less items (`count` has been modified) than were originally queried through respective `_len()` functions (or more likely: a slice of invalid length passed by the user) and some elements at the end of the slice are left uninitialized, panic. Wherever there is valid concern or possibility for this to happen - or to circumvent assertions and panics altogether - mutable references to mutable slices should be passed allowing the length to be promptly updated. [#489]: #489 (comment)
Originally introduced in [#489] this inserts the array-length equality check everywhere else: in the supposedly invalid and inexistant event where Vulkan suddenly returns less items (`count` has been modified) than were originally queried through respective `_len()` functions (or more likely: a slice of invalid length passed by the user) and some elements at the end of the slice are left uninitialized, panic. Wherever there is valid concern or possibility for this to happen - or to circumvent assertions and panics altogether - mutable references to mutable slices should be passed allowing the length to be promptly updated. [#489]: #489 (comment)
Originally introduced in [#489] this inserts the array-length equality check everywhere else: in the supposedly invalid and inexistant event where Vulkan suddenly returns less items (`count` has been modified) than were originally queried through respective `_len()` functions (or more likely: a slice of invalid length passed by the user) and some elements at the end of the slice are left uninitialized, panic. Wherever there is valid concern or possibility for this to happen - or to circumvent assertions and panics altogether - mutable references to mutable slices should be passed allowing the length to be promptly updated. [#489]: #489 (comment)
Trying a new approach for getter functions with
pNext
structures. seems like this could work for the single item inget_device_image_memory_requirements
,but it is probably a bit too weird for the array inget_device_image_sparse_memory_requirements
:Length ofnext
array provides the count, so you'll have to fill that withNone
(ie.vec![None; get_device_image_sparse_memory_requirements_len()]
) if nopNext
pointers are used;Slice is an array of borrows, so you'll need to create your (list of) next object(s) in one place, and create a new vector or slice just to hold the borrows to it;Slice could perhaps be an iterator instead.Never mind,
SparseImageMemoryRequirements2
currently doesn't have anything that extends it. Should we keep this function similar toget_image_sparse_memory_requirements2
(Vulkan 1.1) with just anout: &mut []
array and separate_len
function?