[SYCL][L0] POC for code re-use between PI L0 Plugin and UR L0 Adapter

[smaslov-intel]

Moved (with slightest changes) the minimal viable amount of L0 Plugin code to form a future Unified Runtime and Unified Runtime L0 Adapter. The same code is used for L0 Plugin and UR. The immediate next step would be to enable build/use of PI UR as a new backend of SYCL RT.

Signed-off-by: Sergey V Maslov [email protected]

[smaslov-intel]

Looks like IP scan is failing. From http://icl-jenkins.sc.intel.com:8080/blue/organizations/jenkins/SYCL_CI%2Fintel%2FProtexIP/detail/ProtexIP/13180/pipeline/95

[2022-11-06T19:00:57.871Z] Hit found!
[2022-11-06T19:00:57.871Z] ------ Get match info ------
[2022-11-06T19:00:57.871Z]
[2022-11-06T19:00:57.871Z] ##### Matched files in path sycl listed below #####
[2022-11-06T19:00:57.871Z]
[2022-11-06T19:00:57.871Z] SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
[2022-11-06T19:00:57.871Z] SLF4J: Defaulting to no-operation (NOP) logger implementation
[2022-11-06T19:00:57.871Z] SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
[2022-11-06T19:00:57.871Z] Nov 06, 2022 7:00:57 PM org.apache.cxf.service.factory.ReflectionServiceFactoryBean buildServiceFromClass
[2022-11-06T19:00:57.871Z] INFO: Creating Service {urn:protex.blackducksoftware.com:sdk:v7.0:discovery}DiscoveryApiService from class com.blackducksoftware.sdk.protex.project.codetree.discovery.DiscoveryApi
[2022-11-06T19:00:59.257Z] Nov 06, 2022 7:00:59 PM org.apache.cxf.service.factory.ReflectionServiceFactoryBean buildServiceFromClass
[2022-11-06T19:00:59.257Z] INFO: Creating Service {urn:protex.blackducksoftware.com:sdk:v7.0:codetree}CodeTreeApiService from class com.blackducksoftware.sdk.protex.project.codetree.CodeTreeApi
[2022-11-06T19:00:59.515Z] Nov 06, 2022 7:00:59 PM org.apache.cxf.service.factory.ReflectionServiceFactoryBean buildServiceFromClass
[2022-11-06T19:00:59.515Z] INFO: Creating Service {urn:protex.blackducksoftware.com:sdk:v7.0:project}ProjectApiService from class com.blackducksoftware.sdk.protex.project.ProjectApi
[2022-11-06T19:01:07.630Z] sycl/plugins/unified_runtime/zer_api.h : inteldal.devel.win-x64//2021.1.1.71 (PRECISION)
[2022-11-06T19:01:07.630Z] SourceLocation: sycl/plugins/unified_runtime/zer_api.h ( 26- 59)
[2022-11-06T19:01:07.630Z] MatchingLocation: inteldal.devel.win-x64.2021.1.1.71.nupkg/lib/native/include/services/internal/sycl/level_zero_types.h ( 27- 60)

@bmyates : any idea how to fix this? (I don't even see what it doesn't like)

[romanovvlad]

LGTM

[FranklandJack]

Hi @smaslov-intel,

Thanks for making a start with this, it's good to see some Unified Runtime code being written 😁

I've taken a look at the PR and it looks good, I just wanted to check my understanding on a couple of things (I'm new to the PI architecture as it currently exists, so I may have gotten the wrong end of the stick here).

This PR aims to re-use code between the PI L0 plugin and the UR L0 Adapter. To that end you've moved the _pi_platform implementation into a new _ur_level_zero_platform class and _pi_platform now inherits from _ur_level_zero_platform so it can reuse the code. Further to this, _ur_level_zero_platform inherits from _ur_platform which is currently empty, but from this comment sounds like it could potentially house adapter agnostic shared code that adapter implementations could reuse by just inheriting from _ur_platform.

The MR also starts implementing the PI API on top of the UR API by implementing piPlatformsGet in terms of zerPlatformGet, however this is a point I'm a bit confused about since the definition of the piPlatformsGet entry point still exists (at least for the level zero plugin) and since there are currently no UR adapters there aren't any definitions of zerPlatformGet to actually call. Is the idea here that in the L0 UR adapter (when it is implemented) the implementation of zerPlatformGet would make use of _ur_level_zero_platform and in this way the code would be shared between PI and UR with minimal duplication whilst the two APIs exists? Maybe I've totally misunderstood this part though.

Does the above sound roughly correct, or have I got this totally wrong.

Cheers,

Jack.

[kbenzie]

We are intending to change the prefix used for Unified Runtime from zer to ur in oneapi-src/unified-runtime#23. It looks like that change would be a breaking change for this PR.

[smaslov-intel]

Hi @smaslov-intel,

Thanks for making a start with this, it's good to see some Unified Runtime code being written 😁

I've taken a look at the PR and it looks good, I just wanted to check my understanding on a couple of things (I'm new to the PI architecture as it currently exists, so I may have gotten the wrong end of the stick here).

This PR aims to re-use code between the PI L0 plugin and the UR L0 Adapter. To that end you've moved the _pi_platform implementation into a new _ur_level_zero_platform class and _pi_platform now inherits from _ur_level_zero_platform so it can reuse the code. Further to this, _ur_level_zero_platform inherits from _ur_platform which is currently empty, but from this comment sounds like it could potentially house adapter agnostic shared code that adapter implementations could reuse by just inheriting from _ur_platform.

The MR also starts implementing the PI API on top of the UR API by implementing piPlatformsGet in terms of zerPlatformGet, however this is a point I'm a bit confused about since the definition of the piPlatformsGet entry point still exists (at least for the level zero plugin) and since there are currently no UR adapters there aren't any definitions of zerPlatformGet to actually call. Is the idea here that in the L0 UR adapter (when it is implemented) the implementation of zerPlatformGet would make use of _ur_level_zero_platform and in this way the code would be shared between PI and UR with minimal duplication whilst the two APIs exists? Maybe I've totally misunderstood this part though.

Does the above sound roughly correct, or have I got this totally wrong.

Cheers,

Jack.

That's about right! There is currently no UR L0 Adapter, and this is my next step: move (most of) the code from "piPlatformsGet" of L0 PI plugin to "zerPlatformGet" of UR L0 adapter, and share it meanwhile with the L0 PI path via the "_ur_level_zero_platform".

[smaslov-intel]

Can this be merged now? My immediate next step is to introduce true "unified_runtime" backend (not yet working due to very limited functionality in it yet)

[FranklandJack]

I don't want to block progress on this, and you've addressed my comments, so from my perspective I'm happy for this to merged. Probably worth baring in mind though that this is likely to break as we iterate on the UR spec as Benie said.

[smaslov-intel]

We are intending to change the prefix used for Unified Runtime from zer to ur in oneapi-src/unified-runtime#23. It looks like that change would be a breaking change for this PR.

Thanks to @pvchupin we have a better build now.
These lines will cause the fetch of specific commit guarding us from breaking:

https://github.com/intel/llvm/pull/7293/files/884a06bc777b0717dc28e78dcb440b1d1ff5e516..b1bba4a8bb3418be62089047eb66495062f762f5#diff-1bf2ed05c0065126d4e2150f0eda4dbd561e5c3625452e96356aadafa1312e6fR11

[pvchupin]

#7330 for barrier_order.cpp fail