Add experimental extension for counter-based events

[jandres742]

Resolves: #145

[jandres742]

this is how rendered would look like:

[BartoszDunajski]

I think you should add more details about usage restrictions

[MichalMrozek]

do you mean NON_IMMEDIATE here?

[jandres742]

thanks @MichalMrozek . Fixed.

[aravindksg]

do we need two flags? say if we just have IMMEDIATE, then the absence of that flag would mean REGULAR cmdlists?

[jandres742]

thanks @aravindksg . I was thinking on that. However, it is better to be explicit. in any case, as you see, we are saying that default value is zero, which is IMMEDAITE, so the user only needs to pass a flag (NON_REGULAR) if they want for regular.

type: $x_event_counter_based_exp_flags_t
      name: flags
      desc: |
            [in] mode flags.
            must be 0 (default)

[jandres742]

@MichalMrozek , @BartoszDunajski : please take a look at latest changes.

[aravindksg]

do we want to consider adding flag for event pools for counter based events? i.e, would there be value in creating an event pool where events from that pool are only used as counting events?

[MichalMrozek]

Yes we need flag for event memory pool as those events doesn't require pool memory to be allocated for them, the storage is inherited from command list.

[jandres742]

@MichalMrozek : sorry, could you clarify the comment about event pool? do we want the counter-based flags to be part of the zeEventPoolCreate or zeEventCreate, or both?

[MichalMrozek]

Counter Based Events doesn't need memory backing if they are for immediate command lists, so this must be event pool flag as this is steered to control where allocation happens.
I do not see a need for event flag.
So only change in zeEventPoolCreate flags.

[aravindksg]

seems to me that we are talking about "counter events" being associated at a command queue level. so would it be better to describe a different struct for this entirely so we can cleanly associate at command queue/command list level rather than shoe-horning it into existing event(pool) struct/desc?

we have fences described here as being associated at command queue level, so something similar for "counter events"?
https://spec.oneapi.io/level-zero/latest/core/PROG.html#fences

[MichalMrozek]

We want to leverage events, otherwise all append API's would need to be rewritten.

[jandres742]

thanks @MichalMrozek . I have moved the flags to the event pool logic. Please check.

[jandres742]

@MichalMrozek , @aravindksg, @BartoszDunajski : please see latest changes.

[aravindksg]

do we want to add notes on effect of "Timestamp" flags with counter events? I think timestamp flags (even if set) would be ignored right? or we want to forbid user from setting it and return error?

also- do we expect IPC events to continue to work with counter events?

[jandres742]

timestamps and IPC are orthogonal features, I dont think they cannot work, However, if that's the case, we can add note in the documentation in future follow ups.

[BartoszDunajski]

In general looks ok. But usage on Regular CmdLists is not well described here. This is something that may be confusing in the future and its worth to explain it.

Counter assigned to Event is updated on Each "execute" call.

For example:

CL1->appendLaunchKernel();
CL1->appendLaunchKernel(signal: Event1);
CL1->appendLaunchKernel();
CL1->close();

CmdQ->execute(CL1); // counter {1 -> 2 -> 3}
CmdQ->execute(CL1); // counter {4 -> 5 -> 6}

CL2-> appendLaunchKernel(wait: Event1); 
CL2->close();
CmdQ->execute(CL2); // wait for counter == 5

CLs executed again:

CmdQ->execute(CL1); // counter {7 -> 8 -> 9}

CmdQ->execute(CL2); // wait for counter == 8

[jandres742]

In general looks ok. But usage on Regular CmdLists is not well described here. This is something that may be confusing in the future and its worth to explain it.

Counter assigned to Event is updated on Each "execute" call.

For example:

CL1->appendLaunchKernel();
CL1->appendLaunchKernel(signal: Event1);
CL1->appendLaunchKernel();
CL1->close();

CmdQ->execute(CL1); // counter {1 -> 2 -> 3}
CmdQ->execute(CL1); // counter {4 -> 5 -> 6}

CL2-> appendLaunchKernel(wait: Event1); 
CL2->close();
CmdQ->execute(CL2); // wait for counter == 5

CLs executed again:

CmdQ->execute(CL1); // counter {7 -> 8 -> 9}

CmdQ->execute(CL2); // wait for counter == 8

thanks @BartoszDunajski . Let me add that clarification in a follow-up patch.