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_get_surface_capabilities2 #530

Merged
merged 1 commit into from
Dec 29, 2021

Conversation

asnordstrand
Copy link
Contributor

No description provided.

@MarijnS95 MarijnS95 mentioned this pull request Dec 27, 2021
53 tasks
Copy link
Collaborator

@MarijnS95 MarijnS95 left a 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?

ash/src/extensions/khr/get_surface_capabilities2.rs Outdated Show resolved Hide resolved
Copy link
Collaborator

@MarijnS95 MarijnS95 left a 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!

@MarijnS95
Copy link
Collaborator

By the way, don't forget to add a note to ./Changelog.md, see the other new extensions in there for examples.

(We should setup a PR template listing these necessary items later)

@MarijnS95 MarijnS95 merged commit 8f05905 into ash-rs:master Dec 29, 2021
MarijnS95 added a commit that referenced this pull request Jan 22, 2022
Broken links that snuck in (most recently in #530 and #537) while the
CI was not testing the documentation have also been corrected, to allow
it to succeed again (and to have proper docs in the first place).
Ralith pushed a commit that referenced this pull request Jan 22, 2022
…559)

Broken links that snuck in (most recently in #530 and #537) while the
CI was not testing the documentation have also been corrected, to allow
it to succeed again (and to have proper docs in the first place).
MarijnS95 added a commit that referenced this pull request Apr 16, 2023
…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.
MarijnS95 added a commit that referenced this pull request May 2, 2023
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.
MarijnS95 added a commit that referenced this pull request May 2, 2023
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.
MarijnS95 added a commit that referenced this pull request May 3, 2023
…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()`
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.

2 participants