KhronosGroup / KhronosGroup/OpenXR-Docs

Unclear way to safely aggregate features in `xrCreateVulkanDeviceKHR`

Open
#194 5 comments 0 reactions 0 assignees View on GitHub
synced to gitlab
Dominant language
Python
Stars
181
Forks
74
PR merge metrics
No merged PRs in 30d

Description

`xrCreateVulkanDeviceKHR` from `XR_KHR_vulkan_enable2` requires that the implementation aggregate its own extension/feature requirements with the app's requirements passed in `XrVulkanDeviceCreateInfoKHR::vulkanCreateInfo`.

Say, an implementation requires timeline semaphores.
In the case where this feature is not already enabled by the app but the structure enabling it is in the pNext chain (e.g. `VkPhysicalDeviceTimelineSemaphoreFeatures` or `VkPhysicalDeviceVulkan12Features` is present but `timelineSemaphore` is false), since the `vulkanCreateInfo` field is const, the only way to safely enable timeline semaphores is to deep-copy the whole structure chain.

The issue is that the structure chain may contain structures that the implementation is not aware of, and cannot deep-copy.

What is the expected way to resolve this issue?

Contributor guide

No contributing guide indexed for this repository

Research direction

Read the XR_KHR_vulkan_enable2 definition and the XrVulkanDeviceCreateInfoKHR::vulkanCreateInfo entry, focusing on the required feature and pNext-chain cases described here. Done means the specification documents an unambiguous, safe rule for aggregating implementation and application requirements, including structures the implementation does not know.

Written by the indexing model from the issue text.

Assessment

Domain
api
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.