-
Notifications
You must be signed in to change notification settings - Fork 803
[SYCL] Implement multiple tracing levels for SYCL_UR_TRACE #14983
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
[SYCL] Implement multiple tracing levels for SYCL_UR_TRACE #14983
Conversation
58ac5f6 to
889afba
Compare
889afba to
0be4666
Compare
0be4666 to
18f8492
Compare
|
@intel/dpcpp-doc-reviewers @intel/dpcpp-esimd-reviewers @intel/dpcpp-tools-reviewers @intel/sycl-graphs-reviewers please review, Thanks! |
sarnex
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm minus a question
sycl/doc/EnvironmentVariables.md
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand the difference between 2 and -1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2 enables just the tracing of UR calls, but -1 enables tracing of the UR calls as well as the basic device/adapter discovery tracing, i.e. 1 and 2 combined (and implicitly also any future tracing levels that may be added).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks, think we can add that explanation to the doc?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've updated the documentation now
|
@intel/dpcpp-doc-reviewers Please review, Thanks! |
This change means SYCL_UR_TRACE has the same behavior as the SYCL_PI_TRACE option that it replaced.
86bb1aa to
c854e34
Compare
|
@intel/llvm-reviewers-runtime Please review, Thanks! |
|
To be honest, it doesn't make sense to me to have any UR traces inside SYCL RT. Is that bad naming or some bigger issue with tracing design? |
This is restoring the behavior of |
@aelovikov-intel The tracing is implemented in UR, but the environment variables to enable it are quite verbose: The |
But previously plugins were part of this project, so while not ideal implementation-wise, still not leaking abstractions terribly. I don't see that being true now that UR is separate. |
Why can't that shortcut be provided at the UR side? |
@aelovikov-intel It could, although from a SYCL user's perspective it makes sense for the option to start with the I'd rather get this merged asap to get rid of functional differences with SYCL_PI_TRACE, and then we could revisit the design of the tracing in future. |
aelovikov-intel
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a fan of it, but if it's needed to unblock folks...
This undoes some changes to tracing that were made when porting from PI to UR, and means that `SYCL_UR_TRACE` now has the same behavior as the `SYCL_PI_TRACE` option that it replaced. Also only enable the UR tracing layer when `SYCL_UR_TRACE` is set to the appropriate level, rather than always enabling it when `UR_LOG_TRACING` is set - fixes intel#14926
This undoes some changes to tracing that were made when porting from PI to UR, and means that
SYCL_UR_TRACEnow has the same behavior as theSYCL_PI_TRACEoption that it replaced.Also only enable the UR tracing layer when
SYCL_UR_TRACEis set to the appropriate level, rather than always enabling it whenUR_LOG_TRACINGis set - fixes #14926