Add API logging to validation layer #270
Conversation
b8464f5 to
17d3901
Compare
c5faf17 to
5fddbd5
Compare
4b451dd to
33d7d92
Compare
|
My PR changing the expected log format in SYCL has been approved so it's seems that we don't have to add any alternative formats - we can just always use the same formatting as loader is using. |
|
|
||
| `ZE_ENABLE_VALIDATION_LAYER=1` | ||
|
|
||
| By default logs will be written to the log file, as described above. To print the logs |
There was a problem hiding this comment.
Though not incorrect in this review, we may need to update the filename above at line 56 as it appears no longer valid according to current behavior. This may be a good time to update.
There was a problem hiding this comment.
Are they incorrect? From what I see, we still have LOADER_LOG_FILE_DIRECTORY defined as ".oneapi_logs" and LOADER_LOG_FILE as "ze_loader.log"
| @@ -2411,15 +2528,17 @@ namespace validation_layer | |||
| zes_fan_handle_t hFan ///< [in] Handle for the component. | |||
| ) | |||
| { | |||
| context.logger->log_trace("zesFanSetDefaultMode(hFan)"); | |||
There was a problem hiding this comment.
When we log APIs, should we show the hFan value itself? Instead of just the API signature?
This same question could be applied to many of these APIs
There was a problem hiding this comment.
We could do this quite easily for numeric values and perhaps for pointers (although printing the raw address might not be very useful). ze_tracer does this and even handles descriptors (prints all members of a struct in user-readable format) but this requires some extra logic.
We can think about porting (some of) this more complex logic from ze_tracer in future.
There was a problem hiding this comment.
Lets take this proposal to a future PR.
| namespace loader { | ||
|
|
||
| std::string to_string(const ze_result_t result) { |
There was a problem hiding this comment.
Is there a way we can stringify this with MACROs as opposed to keeping another list we have to maintain? Else we have to modify two locations with potential mismatch with new ERROR codes introduced.
There was a problem hiding this comment.
What is the other place where we have a list like this?
I'm not sure if macro would help much but we could probably generate this funtion from a .mako file.
Anyway, I would prefer to do that in a separate PR, I did not introduce this function - I just moved it from ze_loader.cpp
There was a problem hiding this comment.
Lets take this proposal to a future PR.
through validation layer when 'trace' level is set. This will enable us to remove logging L0 calls from UR and make sure that all L0 calls are being logged (e.g. ones from UMF). Signed-off-by: Igor Chorazewicz <[email protected]>
33d7d92 to
9d2e311
Compare
This reverts commit 4f42647.
No description provided.