-
Notifications
You must be signed in to change notification settings - Fork 404
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
codegen: Update 'create' criteria #4138
codegen: Update 'create' criteria #4138
Conversation
Determine whether or not a command is expected to return a result in a pointer based on parameter type rather than a hard-coded list of command names. Closes KhronosGroup#4136.
CI Vulkan-ValidationLayers build queued with queue ID 18022. |
CI Vulkan-ValidationLayers build # 7365 running. |
CI Vulkan-ValidationLayers build # 7365 passed. |
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.
Reading the spec a little closer, it looks like this is not the right approach.
vkGetWinrtDisplayNV
is not a create call. It should return the same handle when called multiple times with the same arguments, and the returned handle should be one of the VkDisplayKHR
handles enumerated by vkGetPhysicalDeviceDisplayPropertiesKHR
. Check out ValidationObject::WrapDisplay
and Validation::MaybeWrapDisplay
to see some of the existing code deal with these handles.
Then perhaps rather than an "allow list," we should have a "block list" of commands that return pointers that should not be wrapped? |
Sure, we sort of already have that with |
@ncesario-lunarg could you rebase this PR? It's using the old CI flow which is impacting up the github actions cache. |
Closing due to age / staleness / impacting CI caching If still valuable please open new PR |
Determine whether or not a command is expected to return a result in a
pointer based on parameter type rather than a hard-coded list of command
names.
Closes #4136.