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

extensions: Add VK_KHR_maintenance4 #489

Merged
merged 1 commit into from
Nov 11, 2021
Merged

extensions: Add VK_KHR_maintenance4 #489

merged 1 commit into from
Nov 11, 2021

Conversation

MarijnS95
Copy link
Collaborator

@MarijnS95 MarijnS95 commented Nov 10, 2021

Trying a new approach for getter functions with pNext structures. seems like this could work for the single item in get_device_image_memory_requirements, but it is probably a bit too weird for the array in get_device_image_sparse_memory_requirements:

  • Length of next array provides the count, so you'll have to fill that with None (ie. vec![None; get_device_image_sparse_memory_requirements_len()]) if no pNext 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 to get_image_sparse_memory_requirements2 (Vulkan 1.1) with just an out: &mut [] array and separate _len function?

Copy link
Collaborator

@Ralith Ralith left a 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.

ash/src/extensions/khr/maintenance4.rs Outdated Show resolved Hide resolved
ash/src/extensions/khr/maintenance4.rs Outdated Show resolved Hide resolved
@MarijnS95 MarijnS95 marked this pull request as ready for review November 11, 2021 19:57
@MarijnS95 MarijnS95 requested a review from Ralith November 11, 2021 19:57
@Ralith Ralith merged commit 50d58fd into master Nov 11, 2021
@MarijnS95 MarijnS95 deleted the maintenance4 branch November 11, 2021 21:38
&mut count,
out.as_mut_ptr(),
);
assert_eq!(count, out.len() as u32);
Copy link
Collaborator Author

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).

@MarijnS95 MarijnS95 mentioned this pull request Dec 27, 2021
55 tasks
MarijnS95 added a commit that referenced this pull request Dec 27, 2021
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)
MarijnS95 added a commit that referenced this pull request Jan 5, 2022
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)
MarijnS95 added a commit that referenced this pull request Jan 5, 2022
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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants