[SYCL] Fix depends_on with default-constructed events

[steffenlarsen]

Using depends_on with default constructed events caused commands to incorrectly expect the events to have associated PI events. Since default-constructed events are automatically considered finished, they can be ignored if they do not have an associated native event. These changes allows commands to ignore uninitialized events in dependency events.

[steffenlarsen]

/verify with intel/llvm-test-suite#1172

[smaslov-intel]

Since default-constructed events are automatically considered finished, they can be ignored

Can't they be un-signaled/reset before appearing in the dependencies to other commands?

[steffenlarsen]

Since default-constructed events are automatically considered finished, they can be ignored

Can't they be un-signaled/reset before appearing in the dependencies to other commands?

They could be associated with a PI event after this, if that is what you're thinking of. However, this event would be set to completed immediately, as is the SYCL 2020 behavior of default-constructed events. Do you think that would be a problem?

[smaslov-intel]

Since default-constructed events are automatically considered finished, they can be ignored

Can't they be un-signaled/reset before appearing in the dependencies to other commands?

They could be associated with a PI event after this, if that is what you're thinking of. However, this event would be set to completed immediately, as is the SYCL 2020 behavior of default-constructed events. Do you think that would be a problem?

My thinking is that even if it is constructed immediately completed, it is not necessarily so throughout its lifetime, and then it cannot be ignored.

[steffenlarsen]

My thinking is that even if it is constructed immediately completed, it is not necessarily so throughout its lifetime, and then it cannot be ignored.

The default-constructed event should only be used by the user and not inside the runtime. From a user's perspective it should not ever have another underlying event than one that is trivially complete.

We do run the risk of someone inadvertently using the default-constructor event in the runtime in the future. If they try to set the handle-ref of one that is not fully initialized, then this could become a problem. An option for avoiding this would be to have an assert in the non-const getHandleRef that the event is fully initialized, but I don't think XPTI accepts const objects.

[smaslov-intel]

The default-constructed event should only be used by the user and not inside the runtime. From a user's perspective it should not ever have another underlying event than one that is trivially complete.

Could you point to the SYCL spec that is saying so?

[steffenlarsen]

Could you point to the SYCL spec that is saying so?

In 4.6.6 it specifies that for the only user-facing event constructor:

Constructs an event that is immediately ready. The event has no dependencies and no associated commands. Waiting on this event will return immediately and querying its status will return info::event_command_status::complete.

I do not see how the user could use the created event in a way that will change this.

[smaslov-intel]

Constructs an event that is immediately ready. The event has no dependencies and no associated commands. Waiting on this event will return immediately and querying its status will return info::event_command_status::complete.

I do not see how the user could use the created event in a way that will change this.

I think we should at least force this somehow. What does get_native() call on such an event?

[steffenlarsen]

I think we should at least force this somehow. What does get_native() call on such an event?

get_native will force it to create a native event (piEventCreate). I am actually not sure whether that event can really be considered "finished" given we seem to have deprecated piEventSetStatus. Do we have an alternative function for ensuring that the status is completed?

Either way, once get_native has been called on the event it will report true for isInitialized() and as such won't be ignored anymore. The underlying event should still be considered completed though.

[smaslov-intel]

Do we have an alternative function for ensuring that the status is completed?

I don't think you can change the status by SYCL API directly, but one could use get_native() and reset the underlying L0 native event handle with a direct L0 API.

once get_native has been called on the event it will report true for isInitialized() and as such won't be ignored anymore.

I think this resolves my concern.