Skip to content

Tighten spec for extension queries #1374

@aarongreig

Description

@aarongreig

UR_DEVICE_INFO_EXTENSIONS and UR_PLATFORM_INFO_EXTENSIONS both return strings denoting "extensions supported" by the underlying adapter. The current implementations can return some pretty weird stuff, like cuda reporting support for a couple of OpenCL extensions, and a PI extension the line below that. In fact, OpenCL extension strings are reported by all the adapters. I suspect this behaviour is relied on by some element of the sycl RT but it isn't a good mechanism for communicating what it's trying to communicate, and we should definitely aim to get rid of it.

Beyond that a conversation needs to be had about what these queries are for. We deliberately avoided calling the various experimental features extensions, although we are now seeing some of them appear in the output of these queries. If we want them to be a mechanism for reporting support for UR experimental features then the spec should reflect that. If we want them to return extensions supported by the underlying API (i.e. have the CL adapter continue reporting CL extension strings) then that should explicitly be in the spec as well. I question the usefulness of both of these. Unless there's a compelling use case for returning native extension strings (which you could still do if you really wanted, by getting the native handle out), or reporting experimental feature support via a string rather than a ur_device_info_t enum like we mostly already do, we should consider these queries vestigial and remove them.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions