KhronosGroup
Clarify API layer function limitations
In the loader spec, section 3.2 ("Application API Layer Usage"):
An API layer cannot introduce new OpenXR core API commands, but may introduce new extension-specific OpenXR commands that can be queried through the extension interface.
There's no direct definition of a "core API command", but there is the definition of a "core function" in the glossary:
A function that is defined in a version of OpenXR and not an extension. For example, xrCreateInstance is a core function defined in the OpenXR API as well as openxr.h.
If this is what is meant by "core API command", I don't even see how it would be possible for an API layer to define such a thing anyway. What is the intent of the line?
You are right that command means function here. I think the intent of the line is the second part: API layers can add new functions, but they have to be enabled through extensions. You're welcome to clarify that line if you wish. Does that help?
So to clarify, any new functions that an API layer implements must have a corresponding extension? What's the reason for this restriction?
That's how OpenXR functionality is controlled and exposed, through extensions. For an API layer that primarily implements new entry points on top of a runtime, enabling/disabling the extension provides a way for the app to control if it is in use, etc. xrGetInstanceProcAddr shouldn't return success for anything except functions in core or enabled extensions. It's not really a limitation, just a structure.
The extension doesn't have to be published or reviewed, though it should use a reserved extension number, and the repo provides a way to generate standalone headers of such extensions. See the extension process and style guide docs for more.
An issue (number 2502) has been filed to correspond to this issue in the internal Khronos GitLab (Khronos members only: KHR:openxr/openxr#2502 ), to facilitate working group processes.
This GitHub issue will continue to be the main site of discussion.
