-
Notifications
You must be signed in to change notification settings - Fork 187
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_get_surface_capabilities2 #530
Conversation
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.
Nice! Good use of Default::default()
for vk::SurfaceCapabilities2KHR
, but I think you need to do the same for vk::SurfaceFormat2KHR
.
I don't think rustfmt
is going to be happy with fp()
and name()
on a single line though?
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.
Looks totally right to me now!
7fac872
to
eaedadc
Compare
By the way, don't forget to add a note to (We should setup a PR template listing these necessary items later) |
…sical_device_surface_capabilities2` Version 2 of `get_physical_device_surface_capabilities` and the matching `vk::SurfaceCapabilitiesKHR` struct exist solely to provide an `sType` and `pNext` field to allow extending the original query with additional data via extension structs. However, this API when introduced in #530 only returns the default-initialized struct making it just as constrained as `get_physical_device_surface_capabilities()`. Solve this by taking `vk::SurfaceCapabilities2KHR` as `&mut` just like any similar API.
Version 2 of `get_physical_device_surface_capabilities` and the matching `vk::SurfaceCapabilitiesKHR` struct exist solely to provide an `sType` and `pNext` field to allow extending the original query with additional data via extension structs. However, this API when introduced in #530 only returns the `default()`-initialized struct making it just as constrained as `get_physical_device_surface_capabilities()`. Solve this by taking `vk::SurfaceCapabilities2KHR` as `&mut` just like any similar API. And just like this, do the same for the remaining: - `AccelerationStructure::get_acceleration_structure_build_sizes()` - `ExternalMemoryFd::get_memory_fd_properties()` - `ExternalMemoryWin32::get_memory_win32_handle_properties()` In case these structs get extended somewhere down the line, which the Vulkan API allows for.
Version 2 of `get_physical_device_surface_capabilities` and the matching `vk::SurfaceCapabilitiesKHR` struct exist solely to provide an `sType` and `pNext` field to allow extending the original query with additional data via extension structs. However, this API when introduced in #530 only returns the `default()`-initialized struct making it just as constrained as `get_physical_device_surface_capabilities()`. Solve this by taking `vk::SurfaceCapabilities2KHR` as `&mut` just like any similar API. And just like this, do the same for the remaining: - `AccelerationStructure::get_acceleration_structure_build_sizes()` - `ExternalMemoryFd::get_memory_fd_properties()` - `ExternalMemoryWin32::get_memory_win32_handle_properties()` In case these structs get extended somewhere down the line, which the Vulkan API allows for.
…ut` (#744) * extensions/khr: Take the remaining `p_next`-containing structs as `&mut` Version 2 of `get_physical_device_surface_capabilities` and the matching `vk::SurfaceCapabilitiesKHR` struct exist solely to provide an `sType` and `pNext` field to allow extending the original query with additional data via extension structs. However, this API when introduced in #530 only returns the `default()`-initialized struct making it just as constrained as `get_physical_device_surface_capabilities()`. Solve this by taking `vk::SurfaceCapabilities2KHR` as `&mut` just like any similar API. And just like this, do the same for the remaining: - `AccelerationStructure::get_acceleration_structure_build_sizes()` - `ExternalMemoryFd::get_memory_fd_properties()` - `ExternalMemoryWin32::get_memory_win32_handle_properties()` In case these structs get extended somewhere down the line, which the Vulkan API allows for. * extensions/khr/acceleration_structure: Use `mem::zeroed()` in place of `vk::AccelerationStructureCompatibilityKHR::default()`
No description provided.