Andrea Bocci
> The user does not need to fiddle around with the counter makro and the interface will become nice because there is no need to explicitly set the ID. Yes,...
> The id always depends on the caller because it is generated from the filename, function name, line, and column from where it is called. By caller do you mean...
Feel free not to use internal implementation details in your code.
Then I would suggest to use less triggering language than > That sounds borderline suicidal. and > I really don't want to be that pitiful person unconsciously pulling the trigger...
> I enjoy colourful and pictorial language occasionally sacrificing precision for the sake of (what I consider) funny expressions. Understood... next time I'll take in that spirit!
I'm not particularly interested in keeping rocprofiler (and in fact we did not have it until now). Unfortunately it seems to be a dependency of `hipcc` (via `rocminfo`) and various...
I got a suggestion from a possible workaround from an AMD expert: can we `LD_PRELOAD` the correct c++ library ?
I see, these are all good points. I guess the only option is to build ROCm from the sources.
As a temporary workaround it might be enough to build a stub library to replace `librocprofiler-register.so`. This seems to work to build CMSSW with ROCm 6.1.2: #### `rocprofiler-register.cc` ```c++ #include...
Note: one reason to upgrade ROCm is that the current version of the kernel drivers, 6.2.x, are only compatible with ROCm 6.0.x and newer. Anecdotally, running with ROCm 5.6.x on...