Add API call to return the complete list of extensions for a back-end device about anari-docs HOT 6 CLOSED

If so is the property guaranteed to be available before the device has been committed? Availability of features/extensions could depend on device configuration set via parameters which would only take effect after commit.

I think it should be present, but implementations which have single-use parameters to configure the device (such as VisRTX's GPU selection) should clearly state whether querying this parameter would cause the device to become initialized with default device parameters. It is reasonable to state that setting all desired device parameters and committing before querying the list should always give you expected behavior.

There's also a option which is a hybrid of both library+ device: the list queried from the library gives statically known extensions, and the list queried on the device may add additional extensions depending on the internal state of the device. FWIW, as it stands right now all of VisRTX's extensions are present regardless of what GPU is used, but that of course may not always be the case in the future.

from anari-docs.

If the extension query happens on a device object we could use the already existinging anariGetProperty API call for this:

const char ** extensions;
int retrieved = anariGetProperty(device, device,
   "extensions", ANARI_STRING_LIST, &extensions,
   sizeof(extensions), ANARI_NO_WAIT);
//...

where ANARI_STRING_LIST would be a new entry in the ANARIDataType enum.

Some open questions would then be:

1. Is the returned list allowed to be dynamic based on external factors (hardware, driver, internal API versions etc.)?
2. If so is the property guaranteed to be available before the device has been committed? Availability of features/extensions could depend on device configuration set via parameters which would only take effect after commit.

from anari-docs.

A 3rd alternative is similar to the other introspection calls (without the need to create a concrete device first):

const char **anariGetDeviceFeatures(ANARILibrary, const char *deviceSubtype);

from anari-docs.

Is the returned list allowed to be dynamic based on external factors (hardware, driver, internal API versions etc.)?

Good question. For differentiation we said that Introspection is for static (compile-time) information while Properties are for dynamic (run-time dependent) information. Isn't most (all?) support for extensions static information?

from anari-docs.

Isn't most (all?) support for extensions static information?

On the call today it was deemed there's a reasonable amount of evidence that a device may only have access to some features if the underlying infrastructure (i.e. HW) is available. For example, a Vulkan or DX12 based device may only offer a path tracing renderer (and any features inherently tied to that) if ray tracing extensions are available in VK/DX respectively. Thus the idea came up that there should be a static pathway to query what capabilities a device could have from a library, then a property on the device itself that gives you a subset of that list that is acutally available. Thus if you don't have a feature available at all in a library, there's no need to instantiated a device to find that out -- but there's also a pathway for devices to have HW-specific features known at runtime.

...so, both!

from anari-docs.

We have this now as property query feature (returning a STRING_LIST) for DEVICEs and RENDERERs.

from anari-docs.