Generate .def file with all UR entry points #2045
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
EwanC
reviewed
Sep 4, 2024
aarongreig
pushed a commit
to aarongreig/unified-runtime
that referenced
this pull request
Sep 4, 2024
Generate .def file with all UR entry points
martygrant
pushed a commit
to intel/llvm
that referenced
this pull request
Sep 6, 2024
The issues with DLLs and teardown of global objects on Windows is well documented, and was the reason for the use of the `pi_win_proxy_loader` library in SYCL-RT. When we ported from PI to UR, we ported this library (it's now called `ur_win_proxy_loader`), but it was not actually fully utilized. SYCL-RT still linked with `ur_loader.dll` and still experienced issues with race conditions in the teardown of SYCL-RT and Unified Runtime. See #14768. This PR reintroduces the proxy loader as it was previously used with PI. The UR loader (`ur_loader.dll`) is loaded via `LoadLibraryEx` at initialization, and is therefore not cleaned up too early for normal teardown to occur. This necessitates changing the signature of `Plugin->call` to look like it did with PI, taking an enum template argument to specify which UR entry point to call. On Windows, when each plugin (which is a wrapper over a UR adapter) is loaded, it populates a table of function pointers to each API entry point in the UR loader. When UR entry points are called, the function pointer is retrieved from the table. This is more or less equivalent to the previous PI implementation. On Linux, the UR loader is dynamically linked as before. The `Plugin->call` methods just use the regular UR functions rather than programmatically looking up the symbols. For the unittest executables, the UR loader is still dynamically linked as before to avoid having to introduce noisy changes to the tests, and since we aren't concerned about teardown issues there. The implementation of these changes in the runtime should avoid as much overhead as possible (and be no worse than PI), but suggestions on how to improve and tidy things are more than welcome. Associated UR change: oneapi-src/unified-runtime#2045
AlexeySachkov
pushed a commit
to AlexeySachkov/llvm
that referenced
this pull request
Nov 27, 2024
The issues with DLLs and teardown of global objects on Windows is well documented, and was the reason for the use of the `pi_win_proxy_loader` library in SYCL-RT. When we ported from PI to UR, we ported this library (it's now called `ur_win_proxy_loader`), but it was not actually fully utilized. SYCL-RT still linked with `ur_loader.dll` and still experienced issues with race conditions in the teardown of SYCL-RT and Unified Runtime. See intel#14768. This PR reintroduces the proxy loader as it was previously used with PI. The UR loader (`ur_loader.dll`) is loaded via `LoadLibraryEx` at initialization, and is therefore not cleaned up too early for normal teardown to occur. This necessitates changing the signature of `Plugin->call` to look like it did with PI, taking an enum template argument to specify which UR entry point to call. On Windows, when each plugin (which is a wrapper over a UR adapter) is loaded, it populates a table of function pointers to each API entry point in the UR loader. When UR entry points are called, the function pointer is retrieved from the table. This is more or less equivalent to the previous PI implementation. On Linux, the UR loader is dynamically linked as before. The `Plugin->call` methods just use the regular UR functions rather than programmatically looking up the symbols. For the unittest executables, the UR loader is still dynamically linked as before to avoid having to introduce noisy changes to the tests, and since we aren't concerned about teardown issues there. The implementation of these changes in the runtime should avoid as much overhead as possible (and be no worse than PI), but suggestions on how to improve and tidy things are more than welcome. Associated UR change: oneapi-src/unified-runtime#2045
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This was necessary for intel/llvm#15262 - it allows defining macros over every function in the API