-
Notifications
You must be signed in to change notification settings - Fork 71
Description
I think we made a mistake in SYCL 2020 for event::get_backend in two cases:
- The default constructed
event - The
eventthat is returned when you submit a host task
In both of these cases, there's no obvious backend. As a result, there's no obvious backend interop that you can do with these events. For example, what should get_native return for these events?
I think there's an implicit assumption that when object.get_backend returns backend::opencl, an application is allowed to use OpenCL backend interop APIs on that object. Therefore, I think it was a mistake to return backend::opencl for events that are created in the two cases I list above.
I think the cleanest solution would be to introduce a new enumerator called backend::none for cases like this. When an object reports backend::none, we would not support any backend interop for that object.
I also think backend::none would be useful for implementations that do not layer on any established "back end". For example, you could imagine an implementation that implements SYCL directly on hardware, without going through any documented backend API. Such an implementation could return backend::none for all calls to get_backend.
I think the specification should clearly specify what backend enumerator is returned, though. Implementations should not have complete freedom to choose on an object-by-object basis. Here are the rules that make sense to me:
-
An implementation has complete freedom to decide what backend is returned from
platform::get_backendfor eachplatformobject . This can be a Khronos-defined enumerator likebackend::opencl, a vendor-defined enumerator likebackend::ext_oneapi_level_zero, orbackend::none. Each backend enumerator (except forbackend::none) should have a matching backend interop specification. Khronos will define this specification if the backend enumerator is defined by Khronos. A vendor should define this specification if the backend enumerator is defined by the vendor. -
The SYCL specification should clearly document what is returned from all other
class::get_backendmember functions. In most cases, we will say that it returns the same backend as the associated platform. In the two "event" cases that I document above, we will say thatbackend::noneis returned.
This seems like the right balance of implementation freedom and API consistency to me.
Since this affects behavior of SYCL 2020 APIs, I think we should consider this as a bug fix to the SYCL 2020 specification.
Comments?