076f4d8427
* readthedocs updates
* Adding License
* correcting table of contents path
* Move doc requirements to sphinx dir
* Compile requirements.txt
* Update path to reqs
* Adding missing python module
* changing sphinx version
* changing docutils version
* enabling sphinx extensions
* trying sphinx-rtd-theme
* Remove unused doc configs
* Remove unused html theme options
* Add files to toc
* temp commit to test
* updating environment.yml for CI build
* Update doc requirements
To include rocprofiler-sdk in projects.yaml
* Set external_projects_current_project as rocprofiler-sdk
* Exclude external projects
* Fix warning for missing static path
* updating conf.py
* Removing reST syntax
* Use rocm-docs-core doxygen integration
* Remove RST syntax from Markdown files
* Generate doxyfile post checkout on RTD
* Use custom RTD env
* Specify mambaforge
* Put conda before post checkout cmd
* Add doxyfile for RTD
* Run cmake from conf.py
* Update environment.yml
* Use mambaforge
* Fix path to environment.yml
* Call build doxyfile
* Add Developer API title to Doxyfile
* Config version header
* Fix typo in conf.py
* Format fix for conf.py
* Increasing timeout for build-docs-from-source
* Remove README as mainpage for doxyfile
* Fix formatting in conf.py
---------
Co-authored-by: Sam Wu <22262939+samjwu@users.noreply.github.com>
[ROCm/rocprofiler-sdk commit: a60c4def00]
29 lines
2.6 KiB
Markdown
29 lines
2.6 KiB
Markdown
# Welcome to the [ROCprofiler](https://github.com/ROCm/rocprofiler-sdk) Documentation!
|
|
|
|
## Important Changes
|
|
|
|
[Roctracer](https://github.com/ROCm/roctracer) and [rocprofiler (v1)](https://github.com/ROCm/rocprofiler)
|
|
have been combined into a single rocprofiler SDK and re-designed from scratch. The new rocprofiler API has been designed with some
|
|
new restrictions to avoid problems that plagued the former implementations. These restrictions enable more efficient implementations
|
|
and much better thread-safety. The most important restriction is the window for tools to inform rocprofiler about which services
|
|
the tool wishes to use (where "services" refers to the capabilities for API tracing, kernel tracing, etc.).
|
|
|
|
In the former implementations, when one of the ROCm runtimes were initially loaded, a tool only had
|
|
to inform roctracer/rocprofiler that it wished to use its services at some point (e.g. calling `roctracer_init()`)
|
|
and were not required to specify which services it would eventually or potentially use. Thus, these libraries had to effectively prepare for
|
|
any service to be enable at any point in time -- which introduced unnecessary overhead when tools had no desire to use certain features and
|
|
made thread-safe data management difficult. For example, roctracer was required to _always_ install wrappers around _every_ runtime API function
|
|
and _always_ added extra overhead of indirection through the roctracer library and checks for the current service configuration (in a thread-safe manner).
|
|
|
|
In the re-designed implementation, rocprofiler introduces the concept of a "context". Contexts are effectively
|
|
bundles of service configurations. Rocprofiler gives each tool _one_ opportunity to create as many contexts as necessary --
|
|
for example, a tool can group all of the services into one context, create individual contexts for each service, or somewhere in between.
|
|
Due to this design choice change, rocprofiler now knows _exactly_ which services might be requested by the tool clients at any point in time.
|
|
This has several important implications:
|
|
|
|
- rocprofiler does not have to unnecessarily prepare for services that are never used -- if no registered contexts requested tracing the HSA API, no wrappers need to be generated
|
|
- rocprofiler can perform more extensive checks during service specification and inform tools about potential issues very early on
|
|
- rocprofiler can allow multiple tools to use certain services simulatenously
|
|
- rocprofiler was able to improve thread-safety without introducing parallel bottlenecks
|
|
- rocprofiler can manage internal data and allocations more efficiently
|