Disable extension prototypes #251
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
An issue (number 1554) has been filed to correspond to this issue in the internal Khronos GitLab (Khronos members only: KHR:openxr/openxr#1554 ), to facilitate working group processes. This GitHub issue will continue to be the main site of discussion. |
brycehutchings
approved these changes
Apr 5, 2021
rpavlik
added
the
needs changelog fragment
…fusion or pollution with our internal functions
rpavlik
force-pushed
the
disable-extension-prototypes
branch
from
f09a47a
to
44e4a4c
Compare
rpavlik
removed
the
needs changelog fragment
|
Updated, ready to re-review. Generated headers look like this now:
|
brycehutchings
approved these changes
Apr 12, 2021
rpavlik
added a commit
that referenced
this pull request
Apr 14, 2021
The main SDK change in this release is that the OpenXR headers NO LONGER
EXPOSE EXTENSION FUNCTION PROTOTYPES because extension functions are not
exported by the loader. This should prevent some confusion during
development without affecting code that correctly compiles and links
with older SDKs. Code that was compiled but not linked (for instance,
the automated tests of example source in the specification) and that
would not have successfully linked may have their defects highlighted by
this change, however. If you need those prototypes still available,
there is a preprocessor define that can re-enable them. The function
pointer definitions are always available.
In addition to that header change, this release contains three new
vendor extensions plus an assortment of SDK 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)
- SDK
- Hide prototypes for extension functions unless explicitly
requested by defining XR_EXTENSION_PROTOTYPES. These functions
are not exported from the loader, so having their prototypes
available is confusing and leads to link errors, etc.
(OpenXR-SDK-Source/#251, OpenXR-SDK-Source/#174, internal issue
1554, internal issue 1338)
- Also list API layers in list tool. (internal MR 1991)
- Ensure we expose the OpenXR headers in the build-time interface
of the loader, as well as the install-time interface, for use
with FetchContent.cmake. (OpenXR-SDK-Source/#242,
OpenXR-SDK-Source/#195, internal issue 1409)
- Improve BUILDING.md, including adding details on how to specify
architecture for VS2019. (OpenXR-SDK-Source/#245,
OpenXR-SDK-Source/#253)
- Loader: Fix loader failing to load on Windows 7 due to pathcch
dependency. (OpenXR-SDK-Source/#239, OpenXR-SDK-Source/#214,
internal issue 1471, OpenXR-SDK-Source/#236, internal issue
1519)
- Loader: Fix conflicting filename in openxr_loader.def causing a
linker warning when building debug for Windows.
(OpenXR-SDK-Source/#246)
- Update cgenerator.py to generate header comments in openxr.h to
show when a struct extends another struct (internal MR 2005)
- hello_xr: Check for shaderStorageImageMultisample feature in
Vulkan plugin before using it. (OpenXR-SDK-Source/#234,
OpenXR-SDK-Source/#233, internal issue 1518)
- hello_xr: Make sure common.h includes the reflection header that
it uses. (OpenXR-SDK-Source/#247)
- layers: Revise documentation, re-formatting and updating to
refer to real functions and URLs. (internal MR 2012)
- loader: Check the instance handle passed to
xrGetInstanceProcAddr. (internal MR 1980)
- loader: Fix building OpenXR-SDK with CMake’s multi-config Ninja
generator. (OpenXR-SDK-Source/#249, OpenXR-SDK-Source/#231)
- openxr_reflection.h: Make reproducible/deterministic by sorting
protection defines in the script. (internal MR 1993, internal
issue 1424)
- xr_dependencies (shared utility): Include unknwn.h on Windows,
even without D3D enabled. (OpenXR-SDK-Source/#250,
OpenXR-SDK-Source/#237)
rhabacker
pushed a commit
to rhabacker/OpenXR-SDK-Source
that referenced
this pull request
Nov 16, 2022
The main SDK change in this release is that the OpenXR headers NO LONGER
EXPOSE EXTENSION FUNCTION PROTOTYPES because extension functions are not
exported by the loader. This should prevent some confusion during
development without affecting code that correctly compiles and links
with older SDKs. Code that was compiled but not linked (for instance,
the automated tests of example source in the specification) and that
would not have successfully linked may have their defects highlighted by
this change, however. If you need those prototypes still available,
there is a preprocessor define that can re-enable them. The function
pointer definitions are always available.
In addition to that header change, this release contains three new
vendor extensions plus an assortment of SDK 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)
- SDK
- Hide prototypes for extension functions unless explicitly
requested by defining XR_EXTENSION_PROTOTYPES. These functions
are not exported from the loader, so having their prototypes
available is confusing and leads to link errors, etc.
(OpenXR-SDK-Source/KhronosGroup#251, OpenXR-SDK-Source/KhronosGroup#174, internal issue
1554, internal issue 1338)
- Also list API layers in list tool. (internal MR 1991)
- Ensure we expose the OpenXR headers in the build-time interface
of the loader, as well as the install-time interface, for use
with FetchContent.cmake. (OpenXR-SDK-Source/KhronosGroup#242,
OpenXR-SDK-Source/KhronosGroup#195, internal issue 1409)
- Improve BUILDING.md, including adding details on how to specify
architecture for VS2019. (OpenXR-SDK-Source/KhronosGroup#245,
OpenXR-SDK-Source/KhronosGroup#253)
- Loader: Fix loader failing to load on Windows 7 due to pathcch
dependency. (OpenXR-SDK-Source/KhronosGroup#239, OpenXR-SDK-Source/KhronosGroup#214,
internal issue 1471, OpenXR-SDK-Source/KhronosGroup#236, internal issue
1519)
- Loader: Fix conflicting filename in openxr_loader.def causing a
linker warning when building debug for Windows.
(OpenXR-SDK-Source/KhronosGroup#246)
- Update cgenerator.py to generate header comments in openxr.h to
show when a struct extends another struct (internal MR 2005)
- hello_xr: Check for shaderStorageImageMultisample feature in
Vulkan plugin before using it. (OpenXR-SDK-Source/KhronosGroup#234,
OpenXR-SDK-Source/KhronosGroup#233, internal issue 1518)
- hello_xr: Make sure common.h includes the reflection header that
it uses. (OpenXR-SDK-Source/KhronosGroup#247)
- layers: Revise documentation, re-formatting and updating to
refer to real functions and URLs. (internal MR 2012)
- loader: Check the instance handle passed to
xrGetInstanceProcAddr. (internal MR 1980)
- loader: Fix building OpenXR-SDK with CMake’s multi-config Ninja
generator. (OpenXR-SDK-Source/KhronosGroup#249, OpenXR-SDK-Source/KhronosGroup#231)
- openxr_reflection.h: Make reproducible/deterministic by sorting
protection defines in the script. (internal MR 1993, internal
issue 1424)
- xr_dependencies (shared utility): Include unknwn.h on Windows,
even without D3D enabled. (OpenXR-SDK-Source/KhronosGroup#250,
OpenXR-SDK-Source/KhronosGroup#237)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Since the loader doesn't actually export extension functions, it can be confusing that the headers expose the extension prototypes by default. This change makes it so that you have to define
XR_EXTENSION_PROTOTYPES(and not defineXR_NO_PROTOTYPES) in order to get the prototypes for extension functions. (The function pointer types are not guarded this way, so those continue to work as expected.)Fixes #174 among others