Skip to content

Should we add "backend::none"? #564

@gmlueck

Description

@gmlueck

I think we made a mistake in SYCL 2020 for event::get_backend in two cases:

  • The default constructed event
  • The event that 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_backend for each platform object . This can be a Khronos-defined enumerator like backend::opencl, a vendor-defined enumerator like backend::ext_oneapi_level_zero, or backend::none. Each backend enumerator (except for backend::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_backend member 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 that backend::none is 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?

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions