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

Are EXT functions missing the XR_ERROR_INSTANCE_LOST error return code? #10

Closed
pH5 opened this issue Mar 24, 2019 · 5 comments
Closed

Are EXT functions missing the XR_ERROR_INSTANCE_LOST error return code? #10

pH5 opened this issue Mar 24, 2019 · 5 comments
Assignees
@rpavlik
Labels
accepted Accepted for release, will be included in an upcoming patch release bug Something isn't working synced to gitlab A corresponding issue has been filed in the Khronos internal GitLab

Comments

@pH5
Copy link

pH5 commented Mar 24, 2019

Is there a system to whether or not a function can return the XR_ERROR_INSTANCE_LOST error code besides:

4.4.1. The Instance Lost Error
Once XR_ERROR_INSTANCE_LOST is first returned, it must henceforth be returned by all functions that involve an XrInstance or child handle type until the instance is destroyed.

?

For example, xrCreateInstance can return XR_ERROR_INSTANCE_LOST, which I don't understand the purpose of. But the EXT functions are missing it. For example, neither xrPerfSettingsSetPerformanceLevelEXT nor xrCreateDebugUtilsMessengerEXT contain it in their list of failure return codes.

I would have expected all EXT functions that have an XrInstance or XrSession parameter to have the XR_ERROR_INSTANCE_LOST return value.
@brycehutchings
Copy link

Functions like xrCreateDebugUtilsMessengerEXT are implemented in the loader so there is no requirement on the state of the runtime's instance handle. However, extensions like xrPerfSettingsSetPerformanceLevelEXT do look like they should document XR_ERROR_INSTANCE_LOST as a possible error code.

@rpavlik
Copy link
Contributor

rpavlik commented Jul 30, 2019

I suspect that the fact the loader implements "create debug messenger" is an implementation detail and it should still specify it. Note that the XR_ERROR_INSTANCE_LOST text quoted above did change somewhat in 1.0.0.

Makes me think the loader might itself have a bug because I imagine it's not tracking if instance lost was returned and then returning it itself for the debug functions.

@rpavlik rpavlik added the bug Something isn't working label Jul 30, 2019
@rpavlik-bot
Copy link
Collaborator

An issue (number 1256) has been filed to correspond to this issue in the internal Khronos GitLab.

If you have a Khronos account, you can access that issue at KHR:openxr/openxr#1256.

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

rpavlik commented Apr 14, 2021

So I thought this was fixed, but apparently wasn't. I have an internal MR now to fix it (and fix the scripts that were supposed to detect it), will be in the next release I assume.

@rpavlik rpavlik self-assigned this Apr 14, 2021
@rpavlik rpavlik added the accepted Accepted for release, will be included in an upcoming patch release label Apr 14, 2021
rpavlik added a commit that referenced this issue May 11, 2021
@rpavlik
OpenXR Specification 1.0.16 (2021-05-11)
7874fcf 
This release contains improved/clarified behavior for xrCreateInstance
and xrEnumerateInstanceProperties, a new multi-vendor extension, a new
vendor extension, and a collection of clarifications.

-   Registry
    -   Add new XR_ERROR_RUNTIME_UNAVAILABLE error code, add
        XR_ERROR_RUNTIME_UNAVAILABLE as a supported error code to
        xrCreateInstance and xrEnumerateInstanceProperties, and remove
        XR_ERROR_INSTANCE_LOST as a supported error code from
        xrCreateInstance. (internal MR 2024, internal issue 1552,
        OpenXR-SDK-Source/#177)
    -   Add XR_EXT_hand_joint_motion_range multi-vendor extension.
        (internal MR 1995)
    -   Add XR_FB_swapchain_update_state vendor extension. (internal MR
        1997)
    -   Fix missing XR_ERROR_INSTANCE_LOST return codes for extension
        functions in XR_EXT_performance_settings, XR_EXT_debug_utils,
        XR_EXT_conformance_automation, and XR_EXT_thermal_query.
        (internal MR 2023, OpenXR-Docs/#10, internal issue 1256)
    -   Reserve extension 166 for working group use. (internal MR 2025)
-   Specification
    -   Clarify use of xrRequestExitSession on platforms with managed
        application lifecycle. (internal MR 1978)
    -   Clarify hand grip orientation Z semantics. (internal MR 2008)
    -   Clarify unordered swapchain usage flag meaning. (internal MR
        2029, internal issue 1543)
    -   Clarify that hysteresis should be used when applying thresholds
        to scalar input. (internal MR 2031, internal issue 1260,
        OpenXR-Docs/#27)
    -   Document new multi-vendor extension
        XR_EXT_hand_joint_motion_range - allows applications to request
        specific motion ranges when using XR_EXT_hand_tracking.
        (internal MR 1995)
    -   Document new XR_FB_swapchain_update_state vendor extension.
        (internal MR 1997)
    -   Fix xml_consistency scripts to properly identify missing error
        codes from handle ancestors, and suppress warnings about all
        missing _LOST and _LOSS_PENDING on xrDestroy functions.
        (internal MR 2023, OpenXR-Docs/#10, internal issue 1256)
    -   Modify language in XR_EXT_hand_tracking to explicitly state that
        an “empty hand” range of motion is the default. (internal MR
        1995)
    -   Session: Explicitly name the pattern for “get graphics
        requirements” functions, and place a generic version of the
        XR_ERROR_GRAPHICS_REQUIREMENTS_CALL_MISSING return code text
        from graphics extensions in the core spec. (OpenXR-Docs/#79,
        internal issue 1547)
    -   Style guide: Update “Extensions” chapter to simplify and reflect
        actual practice and policy. (internal MR 2027)
    -   Extension process document: Update to note the working group
        policy on extending core/KHR bitmasks. (internal MR 2025)
    -   scripts: Have reflow.py identify a file’s current newline
        convention, and reproduce it upon writing the output. (internal
        MR 2028)
@rpavlik
Copy link
Contributor

rpavlik commented May 11, 2021

Fixed in 1.0.16

@rpavlik rpavlik closed this as completed May 11, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@rpavlik rpavlik

Labels
accepted Accepted for release, will be included in an upcoming patch release bug Something isn't working 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
4 participants
@pH5 @rpavlik @brycehutchings @rpavlik-bot