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.

Sign up for GitHub

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

Jump to bottom

Is it possible to clarify what type of images are allowed to be passed to xrEnumerateSwapchainImages #68

Closed
expipiplus1 opened this issue Dec 11, 2020 · 4 comments
Closed

Is it possible to clarify what type of images are allowed to be passed to xrEnumerateSwapchainImages #68

expipiplus1 opened this issue Dec 11, 2020 · 4 comments
Assignees
@rpavlik
Labels
clarification Reflects a spec clarification request synced to gitlab A corresponding issue has been filed in the Khronos internal GitLab

Comments

@expipiplus1
Copy link
Contributor

https://www.khronos.org/registry/OpenXR/specs/1.0/man/html/xrEnumerateSwapchainImages.html

It would be good if this documentation would clarify what happens if I pass XrSwapchainImageOpenGLKHR when the swapchain is from a Vulkan device for example.

I would expect that either:

  • The structures are untouched and an error code is returned
  • Undefined behavior

happens.
@rpavlik-bot
Copy link
Collaborator

An issue (number 1512) has been filed to correspond to this issue in the internal Khronos GitLab (Khronos members only: KHR:openxr/openxr#1512 ), to facilitate working group processes.

This GitHub issue will continue to be the main site of discussion.

@rpavlik-bot rpavlik-bot added the synced to gitlab A corresponding issue has been filed in the Khronos internal GitLab label Feb 4, 2021
@rpavlik
Copy link
Contributor

rpavlik commented Mar 4, 2021

Straw poll indicates that a validation failure will be returned. I don't remember offhand if we make any guarantees about output data modification on an error, I think you have to treat it as possibly all invalid. We'll make an update to the spec to clarify this behavior, thanks for the report!

@rpavlik rpavlik self-assigned this Mar 4, 2021
@rpavlik rpavlik added the clarification Reflects a spec clarification request label Mar 4, 2021
rpavlik added a commit that referenced this issue Apr 14, 2021
@rpavlik
OpenXR Specification 1.0.15 (2021-04-13)
c056125 
This release contains three new vendor extensions plus an assortment of
small spec fixes.

-   Registry
    -   Add XR_VARJO_foveated_rendering vendor extension. (internal MR
        1981)
    -   Add XR_VARJO_composition_layer_depth_test vendor extension.
        (internal MR 1998)
    -   Add XR_VARJO_environment_depth_estimation vendor extension.
        (internal MR 1998)
    -   Add uint16_t to openxr_platform_defines (and associated scripts)
        so it may be used easily by extensions. (internal MR 2017)
    -   Reserve extension 149 for working group use. (internal MR 1999)
    -   Reserve extension numbers 150 to 155 for ULTRALEAP extensions
        (internal MR 2006)
    -   Reserve extension numbers 156-165 for Facebook. (internal MR
        2018)
-   Specification
    -   Add note to recommend joint names for hand skeletons when using
        XR_EXT_hand_tracking (internal MR 1959, OpenXR-SDK-Source/#223)
    -   Added anchor to the spec of grip pose and aim pose for easy
        linking to their definitions. (internal MR 2016)
    -   Clarify runtime behavior on providing wrong type of images to
        xrEnumerateSwapchainImages. (internal MR 2000, internal issue
        1512, OpenXR-Docs/#68)
    -   Correct function parameter documentation in
        XR_EXT_conformance_automation. (internal MR 2003, internal issue
        1445, OpenXR-Docs/#60)
    -   Document new XR_VARJO_foveated_rendering vendor extension.
        (internal MR 1981)
    -   Document new XR_VARJO_composition_layer_depth_test vendor
        extension. (internal MR 1998)
    -   Document new XR_VARJO_environment_depth_estimation vendor
        extension. (internal MR 1998)
    -   Fix generated valid usage language for
        xrGetVulkanInstanceExtensionsKHR and
        xrGetVulkanDeviceExtensionsKHR, and fix minor vulkan_enable2
        typo. (internal MR 2002, internal issue 1515, OpenXR-Docs/#77)
    -   Fix sample code in XR_EXT_hand_tracking to show proper retrieval
        of function pointers. (internal MR 2019)
    -   Fix sample code in XR_EXT_performance_settings to show proper
        retrieval of function pointers. (internal MR 2019)
    -   Fix sample code callouts in XR_EXT_performance_settings that
        were broken by reflow. (internal MR 2019)
    -   Fix sample code in XR_MSFT_hand_tracking_mesh to show proper
        retrieval of function pointers. (internal MR 2019)
    -   Remove language about display time synchronization for
        EXTX_overlay (internal MR 1951)
    -   Reword the description for xrAttachSessionActionSets. (internal
        MR 1986)
    -   Specify interpretation of premultiplied alpha color when alpha
        is zero. (internal MR 1971)
    -   Specify that rules for extension revisions compatibility
        requirements do not apply to experimental extensions. (internal
        MR 1992)
    -   Update reflow.py so it does not reflow source code callout
        annotations. (internal MR 2019)
    -   Update reflow.py so it does not break directives to include an
        image. (internal MR 2019)
    -   Vulkan extensions: Specify expected mapping of swapchain image
        flags to Vulkan equivalents. (internal MR 1966, internal issue
        1500)
@rpavlik
Copy link
Contributor

rpavlik commented Apr 14, 2021 •
edited
Loading

Resolved in 1.0.15. Thanks for your report!

@rpavlik rpavlik closed this as completed Apr 14, 2021
@expipiplus1
Copy link
Contributor Author

Thanks for the resolution!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@rpavlik rpavlik

Labels
clarification Reflects a spec clarification request synced to gitlab A corresponding issue has been filed in the Khronos internal GitLab
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@rpavlik @expipiplus1 @rpavlik-bot