Gopesh Bhardwaj
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]
2.6 KiB
Welcome to the ROCprofiler Documentation!
Important Changes
Roctracer and rocprofiler (v1) 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