-
Notifications
You must be signed in to change notification settings - Fork 125
Description
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.