Clarify xrEnumerateInstanceExtensionProperties

[fredemmott]

Per https://registry.khronos.org/OpenXR/specs/1.1/html/xrspec.html#api-initialization , this function can be called before calling xrCreateInstance.

This function may: be called before an instance has been created; implementations must: not assume an instance exists.

Concretely:

• a bug in past versions of the Ultraleap API layer crashed if an instance had not been created.
• I've added the paragraph explaining about API layers invoking these, as a past version of the Ultraleap API layer entirely removed their implementation of this and xrEnumerateApiLayerProperties as they appeared to be dead code

[fredemmott]

Related loader docs PR: KhronosGroup/OpenXR-SDK-Source#490

[rpavlik-bot]

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

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

[rblenkinsopp]

I think I'd also like to see:

Suggested change

	When applications invoke this function, the OpenXR loader's implementation
	is used, which enumerates the registered runtime and API layer manifests;
	this function must: still be implemented by API layers and runtimes, as it may
	be invoked by API layers.
	When applications invoke this function, the OpenXR loader's implementation
	is used, which enumerates the registered runtime and API layer manifests;
	this function must: still be implemented by API layers and runtimes, as it may
	be invoked by API layers, and must: return the same information as the manifest.

[fredemmott]

Would that belong here, or in the loader docs over on https://github.com/KhronosGroup/OpenXR-SDK-Source/pull/490/files ?

[rblenkinsopp]

Good question, I think it belongs here because it's specifying the behaviour of the function rather than the detail of the manifest. It probably should have an accompanying note in the loader docs that mirrors it form the manifest perspective.

[johnkearney]

The problem with adding it here is that the main spec doesn't know about the loader - or implementation details of a potential loader like the manifest. It does sound good to add it to the loader spec though.

[fredemmott]

There's a few other paths we could/should take, in order of BC-breaking:

Adding a recommendation to always call with an instance (not bc breaking)

Calling without an instance will result in almost-certainly undesired behavior:

• if the layer is the last layer, it will retrieve all extensions advertised by the runtime
• if there are later layers, it will retrieve all extensions advertised by only the very next layer - not the runtime's extensions, and not any later layers

This would not be a 'must'. Probably 'should'.

Require an instance - mildly BC-breaking

Layers MUST create an instance before calling this.

Runtimes MUST support multiple instances sequentially (i.e. create -> destroy -> create -> destroy, not CCDD) in order for layers to do this before the app creates its' instance. I believe this is already required

Ban this function in API layers, add xrEnumerateApiLayerInstanceExtensionProperties - severely BC breaking

This would be similar to how API layers must not call or define xrCreateInstance and must use xrCreateApiLayerInstance

This new function would take a mandatory XrInstance property, to incorporate the previous suggestion into the function signature.

[fredemmott]

Would that belong here, or in the loader docs over on https://github.com/KhronosGroup/OpenXR-SDK-Source/pull/490/files ?

[johnkearney]

Similar to my comment below, the spec does not really know anything about a potential loader's implementation. If we have something that we are going to require here, we need to require it of the runtime or of the API layer.

[johnkearney]

This is a new unenforceable must: - it was already required that runtimes implemented this function, but it wasn't required for API layers. Is there some path to make this enforceable?

[fredemmott]

I don't think this is new for API layers - it's already a must: at https://github.com/KhronosGroup/OpenXR-SDK-Source/blob/main/specification/loader/api_layer.adoc#api-layer-conventions-and-rules

[fredemmott]

As for making it enforceable:

• we don't currently have any CTS that's really usable for API layers. Perhaps this should change?
• we could make the loader refuse to load extensions that do not implement the functions and where the detail doesn't matter. This would have a minor performance cost on startup.

[johnkearney]

It's not new via the loader spec; but the loader spec is full of things like this. What's being proposed here is a change to the OpenXR spec where we are much more careful. You can see the difference in style / enforcement in the MRs / PRs where I moved the negotiate functions from the loader spec to the OpenXR spec.

[fredemmott]

I don't think this is new for API layers - it's already a must:

My assumption here is that the 'must:' for API layers in the loader specification are actually requirements for API layers; is this the actually the case, or is this just describing assumptions that Khronos's loader implementation is allowed to make?

If the latter, that implies there's potentially such a thing as a conformant API layer that the Khronos loader is unable to load - that seems undesirable.