Skip to content

[SYCL][Doc] Update ITT instrumentation docs #4503

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

Merged
merged 9 commits into from
Sep 17, 2021
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions sycl/doc/EnvironmentVariables.md
Original file line number Diff line number Diff line change
Expand Up @@ -48,6 +48,7 @@ subject to change. Do not rely on these variables in production code.
| `SYCL_CACHE_MIN_DEVICE_IMAGE_SIZE` | Positive integer | Minimum size of device code image in bytes which is reasonable to cache on disk because disk access operation may take more time than do JIT compilation for it. Default value is 0 to cache all images. |
| `SYCL_CACHE_MAX_DEVICE_IMAGE_SIZE` | Positive integer | Maximum size of device image in bytes which is cached. Too big kernels may overload disk too fast. Default value is 1 GB. |
| `SYCL_ENABLE_DEFAULT_CONTEXTS` | '1' or '0' | Enable ('1') or disable ('0') creation of default platform contexts in SYCL runtime. The default context for each platform contains all devices in the platform. Refer to [Platform Default Contexts](extensions/PlatformContext/PlatformContext.adoc) extension to learn more. Enabled by default on Linux and disabled on Windows. |
| `INTEL_ENABLE_OFFLOAD_ANNOTATIONS` | Any(\*) | Enables ITT Annotations support for SYCL runtime. This variable should only be used by tools, that support ITT Annotations. |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's start splitting USER vars and special/experimental use vars and state clearly that these must not be used by end users.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have created a separate file for env variables, that are not meant to be accessed by SYCL users. A separate file is needed so that we can put two distinct entries in https://intel.github.io/llvm-docs/. When this patch is merged, I plan to move rest of the debug variables from this file to the new one and move Environment Variables item to Using oneAPI DPC++ for Application Development section.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pvchupin, I'm not sure why and how DPC++ should differentiate environment variables based on whom they are intended for "human" users or "tools". Could you clarify how do we define "end users"?

@alexbatashev, I think adding another table for environment variables intended for "tools" should resolve this comment and IMHO is better than adding a separate document.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bader,
My comment was mostly about "experimental/internal-use-only" vs. "production", rather than "tools" vs. "human".
I believe disclaimer we currently have is not working well anymore... some of these are used widely and some of these must never be used.
Separating these to different files sounds like a good idea. Would be good to split and categorize them clearly and draw the line more explicitly.
I would suggest to keep EnvironmentVariables.md (as it was referred many times in the past) and move the most of the variables to InternalEnvironmentVariables.md.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My comment was mostly about "experimental/internal-use-only" vs. "production", rather than "tools" vs. "human".
I believe disclaimer we currently have is not working well anymore... some of these are used widely and some of these must never be used.

I believe variables that "must never be used" must be removed.
I also suggest disabling by default (what I think you mean by "production") features which are "experimental/internal-use-only". There should be an option to enable those if needed, but this must be conscious action.

I don't see how moving around documentation can solve the usage problem. If feature is available, it's going to be used by someone eventually.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Somebody added them, so I assume there was/is "experimental" reason at least. It's probably fine to disable by default or remove some, on the other hand there could be cases where experiment can be done randomly on existing build, e.g. during triaging.
I believe there are many vars now and categorizing them properly should help to at least some extent.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pvchupin @bader I propose the following: I will move this variable back to EnvironmentVariables.md, and we will keep this discussion offline. I will prepare a followup patch once we have a decision.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok. Thanks.


`(*) Note: Any means this environment variable is effective when set to any non-null value.`

Expand Down
Original file line number Diff line number Diff line change
@@ -1,5 +1,4 @@
ITT annotations support
=======================
# ITT annotations support

This extension enables a set of functions implementing
the Instrumentation and Tracing Technology (ITT) functionality
Expand All @@ -8,64 +7,64 @@ in SYCL device code.
There are three sets of functions defined by this extension,
and they serve different purposes.

User APIs
---------
## User APIs

The user code calling these functions must include the corresponding header
file(s) provided by ``ittnotify`` project (TBD: reference ITT repo here).
file(s) provided by `ittnotify` project (TBD: reference ITT repo here).

These functions are named using ``__itt_notify_`` prefix.
These functions are named using `__itt_notify_` prefix.

Stub APIs
---------
## Stub APIs

These functions are not defined in any header file, and their declarations
follow exactly the declarations of the corresponding user APIs, except that
they have an extra ``_stub`` suffix in their names.
they have an extra `_stub` suffix in their names.

These functions implement the ITT functionality in a way that allows
the tools, such as Intel(R) Inspector, to recognize the ITT annotations
and run their analysis methods based on that.

For SYCL device code these functions are implemented as ``noinline`` and
``optnone`` functions so that the corresponding calls may be distinguished
For SYCL device code these functions are implemented as `noinline` and
`optnone` functions so that the corresponding calls may be distinguished
in the execution trace. This is just one way for implementing them,
and the actual implementation may change in future.

Compiler wrapper APIs
---------------------
## Compiler wrapper APIs

These functions are not defined in any header file, and they are supposed
to be called from the compiler generated code. These thin wrappers
just provide a convenient way for compilers to produce ITT annotations
without generating too much code in the compilers' IR.

These functions have ``_wrapper`` suffix in their names.
These functions have `_wrapper` suffix in their names.

Example
~~~~~~~
**Example**

.. code: c++
DEVICE_EXTERN_C void __itt_offload_wi_start_stub(
size_t[3], size_t, uint32_t);
```c++
DEVICE_EXTERN_C void __itt_offload_wi_start_stub(
size_t[3], size_t, uint32_t);

DEVICE_EXTERN_C void __itt_offload_wi_start_wrapper() {
if (__spirv_SpecConstant(0xFF747469, 0)) {
size_t GroupID[3] = ...;
size_t WIId = ...;
uint32_t WGSize = ...;
__itt_offload_wi_start_stub(GroupID, WIId, WGSize);
}
}
DEVICE_EXTERN_C void __itt_offload_wi_start_wrapper() {
if (__spirv_SpecConstant(0xFF747469, 0)) {
size_t GroupID[3] = ...;
size_t WIId = ...;
uint32_t WGSize = ...;
__itt_offload_wi_start_stub(GroupID, WIId, WGSize);
}
}
```

A compiler may generate a simple call to ``__itt_offload_wi_start_wrapper``
A compiler may generate a simple call to `__itt_offload_wi_start_wrapper`
to annotate a kernel entry point. Compare this to the code inside the wrapper
function, which a compiler would have to generate if there were no such
a wrapper.

Conditional compilation
-----------------------
## Conditional compilation

Data Parallel C++ compiler automatically instruments user code through
SPIRITTAnnotations LLVM pass, which is enabled for targets, that natively
support specialization constants (i.e., SPIR-V targets). Annotations are
generated for barriers, atomics, work item start and finish.
To minimize the effect of ITT annotations on the performance of the device code,
the implementation is guarded with a specialization constant check. This allows
users and tools to have one version of the annotated code that may be built
Expand All @@ -74,6 +73,10 @@ enabled, we expect that the overall effect of the annotations will be minimized
by the dead code elimination optimization(s) made by the device compilers.

For this purpose we reserve a 1-byte specialization constant numbered
``4285822057`` (``0xFF747469``). The users/tools/runtimes should set this
`4285822057` (`0xFF747469`). The users/tools/runtimes should set this
specialization constant to non-zero value to enable the ITT annotations
in SYCL device code.

The specialization constant value is controlled by
INTEL_ENABLE_OFFLOAD_ANNOTATIONS environment variable. Tools, that support ITT
annotations must set this environment variable to any value.
1 change: 0 additions & 1 deletion sycl/doc/extensions/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -36,7 +36,6 @@ DPC++ extensions status:
| [Unified Shared Memory](USM/USM.adoc) | Supported(OpenCL) | |
| [Use Pinned Memory Property](UsePinnedMemoryProperty/UsePinnedMemoryPropery.adoc) | Supported | |
| [Level-Zero backend specification](LevelZeroBackend/LevelZeroBackend.md) | Supported | |
| [ITT annotations support](ITTAnnotations/ITTAnnotations.rst) | Supported | |
| [Platform Context](PlatformContext/PlatformContext.adoc) | Proposal | |
| [SYCL_EXT_ONEAPI_DEVICE_IF](DeviceIf/device_if.asciidoc) | Proposal | |
| [SYCL_INTEL_group_sort](GroupAlgorithms/SYCL_INTEL_group_sort.asciidoc) | Proposal | |
Expand Down
1 change: 1 addition & 0 deletions sycl/doc/index.rst
Original file line number Diff line number Diff line change
Expand Up @@ -39,4 +39,5 @@ Developing oneAPI DPC++ Compiler
MultiTileCardWithLevelZero
OptionalDeviceFeatures
SYCLInstrumentationUsingXPTI
ITTAnnotations