* Incremental Counter Profile Creation
Adds support for incremental counter creation. How this functions is the
behavior of rocprofiler_create_profile_config has been changed.
rocprofiler_create_profile_config(rocprofiler_agent_id_t agent_id,
rocprofiler_counter_id_t* counters_list,
size_t counters_count,
rocprofiler_profile_config_id_t* config_id)
The behavior of this function now allows an existing config_id to be
supplied via config_id. The counters contained in this config will be
copied over and used as a base for a new config along with any counters
supplied in counters_list. The new config id is returned via config_id
and can be used in future dispatch/agent counting sessions.
A new config is created over modifying an existing config since there
is no gaurentee that the existing config isn't already in use. While we
could add locks (or other mutual exclusion properties) to check if its
in use and reject an update, the benefit from doing so is minor in
comparison to just creating a new config. This also side steps a common
pattern a tool may use to add additional counters at some point later on
during execution. Now they can do that without destroying the existing
config.
---------
Co-authored-by: Benjamin Welton <ben@amd.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
[ROCm/rocprofiler-sdk commit: 81d1407565]
* Incremental Counter Profile Creation
Adds support for incremental counter creation. How this functions is the
behavior of rocprofiler_create_profile_config has been changed.
rocprofiler_create_profile_config(rocprofiler_agent_id_t agent_id,
rocprofiler_counter_id_t* counters_list,
size_t counters_count,
rocprofiler_profile_config_id_t* config_id)
The behavior of this function now allows an existing config_id to be
supplied via config_id. The counters contained in this config will be
copied over and used as a base for a new config along with any counters
supplied in counters_list. The new config id is returned via config_id
and can be used in future dispatch/agent counting sessions.
A new config is created over modifying an existing config since there
is no gaurentee that the existing config isn't already in use. While we
could add locks (or other mutual exclusion properties) to check if its
in use and reject an update, the benefit from doing so is minor in
comparison to just creating a new config. This also side steps a common
pattern a tool may use to add additional counters at some point later on
during execution. Now they can do that without destroying the existing
config.
---------
Co-authored-by: Benjamin Welton <ben@amd.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Fix derived counters to have globals replicated across all architectures (that support them).
---------
Co-authored-by: Benjamin Welton <ben@amd.com>
[ROCm/rocprofiler-sdk commit: ab92bef1a4]
The provides tag is required when the package provides a virtual package.
Package name along with version will be provided by default and the provides tag is not required for this.
Using the tag for providing the name, but without version was resulting in package upgrade issues.
Change-Id: I74506d8c3bbd75d028bcdc03525c29541dce2b4c
[ROCm/rocm_smi_lib commit: d54bade574]
The provides tag is required when the package provides a virtual package.
Package name along with version will be provided by default and the provides tag is not required for this.
Using the tag for providing the name, but without version was resulting in package upgrade issues.
Change-Id: I74506d8c3bbd75d028bcdc03525c29541dce2b4c
1.Move global amd::monitor listenerLock before global
class runtime_tear_down as it will be referenced in
~RuntimeTearDown() after main(). It should be freed
later than runtime_tear_down.
2.Update Device::~Device() to SVM free coopHostcallBuffer_
before context_ is released and freed.
Change-Id: I1d21378ff463477d3238d71e5e2a1a7d6b9147ad
[ROCm/clr commit: 544c45364f]
1.Move global amd::monitor listenerLock before global
class runtime_tear_down as it will be referenced in
~RuntimeTearDown() after main(). It should be freed
later than runtime_tear_down.
2.Update Device::~Device() to SVM free coopHostcallBuffer_
before context_ is released and freed.
Change-Id: I1d21378ff463477d3238d71e5e2a1a7d6b9147ad
- Markdown fixes
- Fix spellcheck
- Clean up
- Supress etoc warning
- Remove folder before clone if it's exist
- Change liniting.yml to use develop
- Trailing white space fix
Change-Id: Ib3bb2cdd0abebeb21071b5d2e2d3b57fe41666e0
hip-samples package should depends on hip-dev/devel and hipcc rather than hip-runtime-amd
Updated the same for static package as well
DependsOn: Iacab7993dffaa00efd1344d3eafb55f6317d1509
Change-Id: I1470475ddbaf9201ba0e39977aeb48b0382f59c9
[ROCm/hip-tests commit: 0b28ca3f04]
hip-samples package should depends on hip-dev/devel and hipcc rather than hip-runtime-amd
Updated the same for static package as well
DependsOn: Iacab7993dffaa00efd1344d3eafb55f6317d1509
Change-Id: I1470475ddbaf9201ba0e39977aeb48b0382f59c9
This patch fixes error:
error: assignment of member 'dismiss_' in read-only object
Reported by kind Gentoo folks:
<https://bugs.gentoo.org/918709>
Change-Id: I7cc593043e97402afd85593c528ace86952b1350
Signed-off-by: Galantsev, Dmitrii <dmitrii.galantsev@amd.com>
If the graph has kernels that does device side allocation, during packet capture, heap is
allocated because heap pointer has to be added to the AQL packet, and initialized during
graph launch.
Handle race with wait when 2 kernels with device heap are enqueued on multiple streams.
Change-Id: I45933b77fcaf7bc8fdf1bc906462e32b5d8d3688
[ROCm/clr commit: 57156c524d]
If the graph has kernels that does device side allocation, during packet capture, heap is
allocated because heap pointer has to be added to the AQL packet, and initialized during
graph launch.
Handle race with wait when 2 kernels with device heap are enqueued on multiple streams.
Change-Id: I45933b77fcaf7bc8fdf1bc906462e32b5d8d3688
The hip libraries depends on multiple standard shared libraries.
Corresponding packages are added to the dependency list.
Removed hipcc from hip-runtime package dependency list
Rearranged the package dependencies as well
The base (docker) images usually comes with the standard packages installed.
So even without the standard packages in dependency list, the installation will go through.
But its good to have all the required packages in the dependency list.
Change-Id: Iacab7993dffaa00efd1344d3eafb55f6317d1509
[ROCm/clr commit: 7dc71710dd]