Level Zero memory provider should NOT be built by default

[ldorau]

Level Zero memory provider should NOT be built by default (UMF_BUILD_LEVEL_ZERO_PROVIDER should be OFF by default). Fix also its name in the README.md file.

Fixes: #288

[vinser52]

Why it should not be built by default?
We agreed with @bratpiorka that the L0 provider does not require hard (only via dlsym) runtime dependencies it should be part of libumf.so, since UR is planning to use the L0 provider it should be built.

[lukaszstolarczuk]

Why it should not be built by default? We agreed with @bratpiorka that the L0 provider does not require hard (only via dlsym) runtime dependencies it should be part of libumf.so, since UR is planning to use the L0 provider it should be built.

hmm... that sounds right, but on the other hand, pls see this fail (on nigthly Coverity build):

https://github.com/oneapi-src/unified-memory-framework/actions/runs/8148957053/job/22272779208#step:7:52

[ldorau]

Hmm... See: #288
It requires the header, so it always requires L0 library to be installed in OS.
Is it OK?

[vinser52]

hmm... that sounds right, but on the other hand, pls see this fail (on nightly Coverity build):

This failure indicates that our build environment is not correct, am I right? I think we should fix the build environment.

[ldorau]

hmm... that sounds right, but on the other hand, pls see this fail (on nightly Coverity build):

This failure indicates that our build environment is not correct, am I right? I think we should fix the build environment.

This failure indicates that there is a check for L0 library missing in CMake.

[KFilipek]

Basic build should be as easy as: clone -> configure -> make
Adding extra dependencies to the default build is not the best option I believe.
Changing the CI every time too...

[lukaszstolarczuk]

I'm also wondering about the requirements section in README - so should we expect from all UMF users to have L0 compatible GPU?

[vinser52]

Hmm... See: #288
It requires the header, so it always requires L0 library to be installed in OS.
Is it OK?

So, UMF is going to be part of oneAPI distribution and we will build UMF with the required options (L0 provider should be ON in that case). So our CI should build UMF with both (ON/OFF) options for L0 provider, but ON is a main option for us (oneAPI distribution). But keep in mind also that execution environment does not require L0 installed even UMF was build with L0 provider.

This failure indicates that there is a check for L0 library missing in CMake.

Agree

I'm also wondering about the requirements section in README - so should we expect from all UMF users to have L0 compatible GPU?

No, we are not expecting it, that is why L0 provider can be ON/OFF.

Now the question is what should be the default option? But anyway L0 provider ON is our (oneAPI) main option.

[vinser52]

Regarding the default option for the L0 memory provider, we have two opposing points of view:

1. The default path should be as easy as: cmake .. && make
2. The default environment is the same as we are using to build UMF for oneAPI package. So that user can explicitly disable some options to be aware that he/she is building version of UMF that is different from what Intel distributes as part of the oneAPI package.

When we discussed that with @bratpiorka yesterday I slightly prefered option 2 because it signals the user that when he/she turns off L0 provider the UMF binary will be different from what we have as part of oneAPI. But I have no strong preference on that question.

[pbalcer]

fwiw, UR disables L0 by default. And, if it's enabled, it will fetch L0 automatically. So users don't need to have L0/compute runtime installed even if they do compile the L0 adapter.

[vinser52]

I'm also wondering about the requirements section in README - so should we expect from all UMF users to have L0 compatible GPU?

One more clarification, I think the requirements for L0 provider are wrong right now. For build L0 provider only level-zero-dev is required. For execution, there are no any strict requirements for L0 provider - the client who is going to use L0 provider will link with L0 laoder and UMF will discover it at runtime.

[vinser52]

fwiw, UR disables L0 by default. And, if it's enabled, it will fetch L0 automatically. So users don't need to have L0/compute runtime installed even if they do compile the L0 adapter.

Do I get it correctly that oneAPI build turns this option ON explicitly? If so, we can do the same in UMF: by default turn it OFF, but in CI we should test the ON option and ON it when we create oneAPI package.

[vinser52]

This failure indicates that there is a check for L0 library missing in CMake.

Will you fix it in this PR, instead of just changing the default option? Or do we need a quick fix in this PR to make CI green?

[pbalcer]

Do I get it correctly that oneAPI build turns this option ON explicitly?

Yes. It also has cmake variables to allow the build to use a precompiled L0 version (that's not installed in the system), which is how it's used most of the time.

[ldorau]

This failure indicates that there is a check for L0 library missing in CMake.

Will you fix it in this PR, instead of just changing the default option? Or do we need a quick fix in this PR to make CI green?

I have already fixed CI. This PR can stay as is to finish the discussion.

[vinser52]

I have already fixed CI. This PR can stay as is to finish the discussion.

Ok, great. based on the discussion above I suggest the following:

1. Turn OFF by default L0 provider.
2. In the CI test both flows (L0 provider ON/OFF).
3. Not sure if it is possible with our CI. For the case when the L0 provider is ON we need to make sure that UMF can be used on the system without L0 dependencies if L0 provider is not used. Probably we can check with ldd that libumf.so is not linked with any l0 binaries.

Did I miss something?

[pbalcer]

4. update cmakes to use find_package/fetch content so that it's possible to set an external level-zero location.

[bratpiorka]

@ldorau I think that this draft PR can be closed

[ldorau]

@ldorau I think that this draft PR can be closed

OK