[SYCL] Add queue properties to select submission mode

[rdeodhar]

This change adds the queue properties immediate_command_list and no_immediate_command_list to enable overriding the queue submission defaults.

[alycm]

As this PR changes pi.h then it will require UR changes to match this.

As stated in a comment on another PR, documentation on how to add experimental features is being written here oneapi-src/unified-runtime#546

But this change may be small enough and concrete enough to skip experimental and we just add it to UR directly?

You can ask us (@alycm, @jandres742, @kbenzie) any questions and we'll help you out.

[jbrodman]

How is this supposed to work on non-Intel GPUs?

[rdeodhar]

The queue properties are intended to be a hint to the implementation. On L0, where we have different submission modes, it is clear what to do. On other platforms the implementation may ignore these hints if they cannot be mapped to something useful.

[jandres742]

the environment variable should have priority over the flags, because that way, the user can force one or the other behavior w/o having to change the code.

[rdeodhar]

In this case, the code, if it uses an explicit queue property, should win. Only if the queue property is not used should we rely on env vars.

[jandres742]

@rdeodhar : but let's say you have the binary for a customer application taht uses batched submission, and you want to see if a functional or performance bug is gone if you used immediate submission? by having the environment variable always taking priority, you can change the behavior and debug the issue w/o needing a new binary.

same from point of view of user: Imagine the user has a very large codebase, where immediate submission is used, and they want just to see what would happen if batched submission were used. They could go and change all the codebase, but that would mean time refactoring, compiling and executing, while with the environment variable, they can test and see any benefits or problems before investing time changing the code.

[rdeodhar]

I appreciate your reasoning but when something is explicitly (hard) coded in the program it should not be subject to over-ride through env vars. Do you know of any other SYCL properties that are subject to over-ride through env vars?
A secondary question is whether the env var has been explicitly set or default. Should even a default setting of the env var over-ride the code? What about explicit setting to what was already the default setting? Should that be considered an explicit setting and over-ride what is in the code?

[jandres742]

@rdeodhar for the second question, we would need to have a default value of -1 for the environment variable, so something like this:

if (environment variable != -1) {
   set queue mode to value set by environment variable;
} else if (batched mode selected by application) {
   set batched mode
} else if (immediate mode selected by application) {
   set immediate mode
} else {
   set defaults // which currently is for instance immediate mode for PVC and batched for others
}

so again, this is mostly about helping with the debug and programmability. but it is not a hard blocker. If you think it is better to have priority in the setting from application, it is good too.

[rdeodhar]

The compiler convention is to honor explicit coding and allow env var control over other behavior. So we'll stick with the way its done now.

[KseniyaTikhomirova]

LGTM

[KseniyaTikhomirova]

seems to be redundant here. it is the first place Submission seen could be set to true

[rdeodhar]

Yes, you are right. Removed unneeded code.

[gmlueck]

extension spec LGTM.