loader windows platform discovery implementation

[pbalcer]

issue

The loader needs to be able to discover available adapter implementations, given a hardcoded list of names. On Linux, this is simple since we can rely on dlopen's builtin support for dynamic symbol discovery.
For windows, this gets complicated. The level-zero loader (https://github.com/oneapi-src/level-zero/blob/master/source/loader/windows/driver_discovery_win.cpp) looks for registry keys from the display adapter installation to discover the drivers. This approach might not necessarily work for UR.

tasks

1. For the time being, we need a simple way of allowing the loader to find adapters on windows. This should include loading hardcoded adapters from some known directory (cwd ?) and support for UR_ENABLE_ALT_DRIVERS env variable.
2. We need to figure out and implement the best long-term approach for adapters to register themselves for the loader to discover. Maybe we need a registry folder where adapters info is placed? or maybe have a known single directory for all adapters?

[PatKamin]

As to the registering of adapters and the ideas provided by @pbalcer, one of the solutions is to have a single conf file where adapters' names and their absolute paths would be stored. Each adapter upon its installation would have to append this conf file with just a single line. Adapters search in UR would look the same on linux and Windows. For linux, it seems reasonable to have such a file stored in /etc/ur.d/. For Windows the equivalent would be C:/ProgramData/Unified Runtime/.

There is one disadvantage of this solution, though. What should adapters do if UR is not installed? Introducing a requirement for adapters to be installed after UR installation would be very inconvenient, I think this have to be handled in some way. Should adapters' installers create such a file? In such a case, there should be a template file stored somewhere in UR so that authors of adapters would know how this conf file should look like.

This problem can be resolved by using some registry key of type REG_MULTI_SZ (or even better, a set of REG_SZ with each adapter creating its own entry in the same UR reg key) for storing adapters names and paths. This would work for Windows. On linux, we could rely on dlopen()'s functionality - it searches well-known paths for libraries. Given that there is a standardized way of naming adapter libraries (#352), it's easy to load all adapters found in the system. I think this is the cleanest way to load adapters. We could describe the location and the name of the reg key in the README or INTRO file so this is well-known to authors of adapters. Proposed location of the UR key for storing adapters' paths is HKLM/SOFTWARE/UnifiedRuntime/RegisteredAdapters/. In this solution, no config file is needed.

Any thoughts on that? I think the second solution with reg keys and dlopen's functionality would be the way to go.

[kbenzie]

As a data point, the OpenCL-ICD-Loader defines a similar approach here of using a config file on Linux and registry keys on Windows.

[pbalcer]

We've discussed this at the workgroup, and the decision is to keep things simple for now. The hard coded list of adapters will stay and be used on both platforms. In addition, we will:

• create a new env variable (UR_ADAPTERS_SEARCH_PATH) that specifies a comma-separated list of directories to include in the adapter search. This can be implemented in a platform-agnostic way with the use of std::filesystem (because I don't think there's a clean way of adding a library search path on Linux. LD_LIBRARY_PATH needs to be defined on program start).
• make the loader look for adapters in the loader's own location. This can be accomplished on Linux with dlinfo(..., RTLD_DI_LINKMAP, ...); and on Windows with GetModuleFileName.