-
Notifications
You must be signed in to change notification settings - Fork 124
Proposal for UR new warnings mechanism #1330
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Labels
specification
Changes or additions to the specification
Comments
This was discussed on the WG meeting of 14/02/2024. There was no objections to this approach. So we will go ahead with adding the new entrypoint to the specification. |
martygrant
added a commit
to intel/llvm
that referenced
this issue
Apr 10, 2025
Migrated from oneapi-src/unified-runtime#1748 This PR implements oneapi-src/unified-runtime#1330 through a new logger sink: a user configurable callback. It introduces some spec additions: - `typedef void (*ur_logger_output_callback_t)(ur_logger_level_t level, const char *pLoggerMsg, void *pUserData)` - `urSetLoggerCallback(ur_adapter_handle_t hAdapter, ur_logger_output_callback_t pfnLoggerCallback, void *pUserData, ur_logger_level_t level` )` - `urSetLoggerCallbackLevel(ur_adapter_handle_t hAdapter, ur_logger_level_t level)` - `typedef enum ur_logger_level_t` (moved the logger::level enum into the spec) This new logger sink will only be constructed once a user makes a call to `urSetLoggerCallback` (which is called from the UR `urAdapterSetLoggerCallback` entry point), supplying their own callback function. They can set the minimum logging level through `urSetLoggerCallbackLevel`. Any subsequent logging calls will additionally make a call to the supplied callback where the log level, message and user data will be sent. A callback has been setup in the SYCL RT in `sycl/source/detail/ur.cpp` to print logs to `std::err`: ``` void urLoggerCallback([[maybe_unused]] ur_logger_level_t level, const char *msg, [[maybe_unused]] void *userData) { std::cerr << msg << std::endl; } ``` A new test suite `LoggerWithCallbackSink` has been added to test this new functionality. --------- Co-authored-by: Kenneth Benzie (Benie) <k.benzie83@gmail.com>
This has been implemented in intel/llvm#17095 |
kbenzie
added a commit
that referenced
this issue
Apr 14, 2025
Migrated from #1748 This PR implements #1330 through a new logger sink: a user configurable callback. It introduces some spec additions: - `typedef void (*ur_logger_output_callback_t)(ur_logger_level_t level, const char *pLoggerMsg, void *pUserData)` - `urSetLoggerCallback(ur_adapter_handle_t hAdapter, ur_logger_output_callback_t pfnLoggerCallback, void *pUserData, ur_logger_level_t level` )` - `urSetLoggerCallbackLevel(ur_adapter_handle_t hAdapter, ur_logger_level_t level)` - `typedef enum ur_logger_level_t` (moved the logger::level enum into the spec) This new logger sink will only be constructed once a user makes a call to `urSetLoggerCallback` (which is called from the UR `urAdapterSetLoggerCallback` entry point), supplying their own callback function. They can set the minimum logging level through `urSetLoggerCallbackLevel`. Any subsequent logging calls will additionally make a call to the supplied callback where the log level, message and user data will be sent. A callback has been setup in the SYCL RT in `sycl/source/detail/ur.cpp` to print logs to `std::err`: ``` void urLoggerCallback([[maybe_unused]] ur_logger_level_t level, const char *msg, [[maybe_unused]] void *userData) { std::cerr << msg << std::endl; } ``` A new test suite `LoggerWithCallbackSink` has been added to test this new functionality. --------- Co-authored-by: Kenneth Benzie (Benie) <k.benzie83@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The warning mechanism that currently exists in Unified Runtime is ambiguous and not very intuitive.
This is the current state (for adapters that use this functionality):
urAdapterGetLastError
and returnsUR_RESULT_ERROR_ADAPTER_SPECIFIC
urAdapterGetLastError
returnsUR_RESULT_SUCCESS
to signal that it is a warning.urAdapterGetLastError
returnsUR_RESULT_ERROR_ADAPTER_SPECIFIC
instead.This is not intuitive because
urAdapterGetLastError
is the only entrypoint that can return an error code in a success state. In addition, settingUR_RESULT_SUCCESS
to signal a warning doesn't make much sense.After some internal discussion, we think that the following changes could improve the current workflow:
urAdapterGetLastError
should be simplified to always returnUR_RESULT_SUCCESS
unless something is wrong with its parameters. This would make it behave in a way that is more in line with other UR entrypoints.Risks:
Related issue: #762
The text was updated successfully, but these errors were encountered: