* Fixing cmake_install_prefix search to include /opt/rocm-xxxx
* Removing all hard references to /opt/rocm with ROCM_PATH
* Setting ROCM_PATH CMake variable in install script
[ROCm/rccl commit: 7b8b54955b]
* Fixing cmake_install_prefix search to include /opt/rocm-xxxx
* Removing all hard references to /opt/rocm with ROCM_PATH
* Setting ROCM_PATH CMake variable in install script
CPACK doesn't have proper logic for installing the license as described
by CPACK_RESOURCE_FILE_LICENSE.
For Debian packaging, the license is expected to be installed as:
/usr/share/doc/PACKAGENAME/copyright
To do this, I've added a bit of logic for CPACK to copy this into the
package using CPACK_INSTALL_COMMANDS to prep the directory, and
CPACK_INSTALLED_DIRECTORIES to add it to the package. This applies to
both RPM and DEB, so I've added some logic to the spec file to exclude
this file (note that CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST_ADDITION does
not work for files installed with CPACK_INSTALLED_DIRECTORIES).
For RPM install, I've just added a small bit of logic to the spec file
to handle it. The file needs to be copied into the spec working
directory, then a macro is used to handle the rest. Note the license
macro does not work on EL6, but I don't think we want to support this.
Change-Id: I06ce63d300419893cb8274bc504a15633e304d91
Signed-off-by: Jeremy Newton <Jeremy.Newton@amd.com>
CPACK doesn't have proper logic for installing the license as described
by CPACK_RESOURCE_FILE_LICENSE.
For Debian packaging, the license is expected to be installed as:
/usr/share/doc/PACKAGENAME/copyright
To do this, I've added a bit of logic for CPACK to copy this into the
package using CPACK_INSTALL_COMMANDS to prep the directory, and
CPACK_INSTALLED_DIRECTORIES to add it to the package. This applies to
both RPM and DEB, so I've added some logic to the spec file to exclude
this file (note that CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST_ADDITION does
not work for files installed with CPACK_INSTALLED_DIRECTORIES).
For RPM install, I've just added a small bit of logic to the spec file
to handle it. The file needs to be copied into the spec working
directory, then a macro is used to handle the rest. Note the license
macro does not work on EL6, but I don't think we want to support this.
Change-Id: I06ce63d300419893cb8274bc504a15633e304d91
Signed-off-by: Jeremy Newton <Jeremy.Newton@amd.com>
[ROCm/ROCR-Runtime commit: 7649cd862e]
I used the binary directory instead of the source directory to specify
the spec.in path, which passed local testing since these directories
are in the same location. This is not guarenteed to be true.
Change-Id: I1b49ca8453b9c074a947104c26fb39667d728a8e
Signed-off-by: Jeremy Newton <Jeremy.Newton@amd.com>
I used the binary directory instead of the source directory to specify
the spec.in path, which passed local testing since these directories
are in the same location. This is not guarenteed to be true.
Change-Id: I1b49ca8453b9c074a947104c26fb39667d728a8e
Signed-off-by: Jeremy Newton <Jeremy.Newton@amd.com>
[ROCm/ROCR-Runtime commit: 529c96c08b]
CPack does not support recommends for RPM generation, so I've generated
a template RPM SPEC files in order to make modifications to allow for
support of recommends.
The spec.in file was generated using the cpack option
"CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE" and was modified very
sparingly to avoid any maintanance burden, e.g. can be easily
regenerated. The CPACK_RPM_USER_BINARY_SPECFILE is then used to specify
the customized template file, instead of using the cmake's template.
From what I understand, the point of these two options is to allow
developers to tailor the specfile to their desire, since rpm spec files
are much more advanced then the equilivent debian file.
Change-Id: I80c69be58a3c57729ed997fd2ce01f5d16b9e9b9
Signed-off-by: Jeremy Newton <Jeremy.Newton@amd.com>
CPack does not support recommends for RPM generation, so I've generated
a template RPM SPEC files in order to make modifications to allow for
support of recommends.
The spec.in file was generated using the cpack option
"CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE" and was modified very
sparingly to avoid any maintanance burden, e.g. can be easily
regenerated. The CPACK_RPM_USER_BINARY_SPECFILE is then used to specify
the customized template file, instead of using the cmake's template.
From what I understand, the point of these two options is to allow
developers to tailor the specfile to their desire, since rpm spec files
are much more advanced then the equilivent debian file.
Change-Id: I80c69be58a3c57729ed997fd2ce01f5d16b9e9b9
Signed-off-by: Jeremy Newton <Jeremy.Newton@amd.com>
[ROCm/ROCR-Runtime commit: 3c0e4fee0f]
* gtest: dynamically generate tests based on test machine's GPU count
* Adjust test element size and bfloat16 threshold for up to 16 GPUs
[ROCm/rccl commit: 03a830293c]
For the use of libdrm-amdgpu-amdgpu1 and libdrm-amdgpu, we should use
recommends, as we want these packages installed with a strong dependency
but avoid a strict dependency, since this is enhancement feature.
Using the newer libdrm, which is build for amdgpu-dkms, is ideal since
it will produce more correct marketing names, but should not be mandated
due to two reasons:
- A user may not want to install both libdrms on their system
- The system might not have the newer libdrm available
This patch only fixes the Ubuntu/debian package since recommends is not
properly implemented for the RPM generator for CPACK. For now,
"suggests" will have to do, since it's the closest option we have. I
will investigate if we can get around this issue.
Change-Id: I33a90c3ead235bbbe265238c026933688ea63fe3
Signed-off-by: Jeremy Newton <Jeremy.Newton@amd.com>
For the use of libdrm-amdgpu-amdgpu1 and libdrm-amdgpu, we should use
recommends, as we want these packages installed with a strong dependency
but avoid a strict dependency, since this is enhancement feature.
Using the newer libdrm, which is build for amdgpu-dkms, is ideal since
it will produce more correct marketing names, but should not be mandated
due to two reasons:
- A user may not want to install both libdrms on their system
- The system might not have the newer libdrm available
This patch only fixes the Ubuntu/debian package since recommends is not
properly implemented for the RPM generator for CPACK. For now,
"suggests" will have to do, since it's the closest option we have. I
will investigate if we can get around this issue.
Change-Id: I33a90c3ead235bbbe265238c026933688ea63fe3
Signed-off-by: Jeremy Newton <Jeremy.Newton@amd.com>
[ROCm/ROCR-Runtime commit: 86c27a7af8]
Comments call out the specific operation being selected since the
ternary nest is a bit hard to read.
Change-Id: If033dbaa6cba132e96196ad3fc6d5572042041f4
Comments call out the specific operation being selected since the
ternary nest is a bit hard to read.
Change-Id: If033dbaa6cba132e96196ad3fc6d5572042041f4
[ROCm/ROCR-Runtime commit: fc75731034]
Agent temp array could have leaked if one of the given agent
handles was invalid.
Change-Id: I9e638b3a4f6bb917a4e3209ad81a1253bb603365
[ROCm/ROCR-Runtime commit: b198016949]
Argument must be checked for nullptr before being dereferenced and
filled with the default return value.
Change-Id: I9ff366f066a5e18c78129bf59cc3ba00fca3ef18
Argument must be checked for nullptr before being dereferenced and
filled with the default return value.
Change-Id: I9ff366f066a5e18c78129bf59cc3ba00fca3ef18
[ROCm/ROCR-Runtime commit: f48a786662]
This omission did not cause problems earlier due to having not been
instanced.
Change-Id: I7a54f82e06c299902f3bf6b4d3737cc5e30961ad
[ROCm/ROCR-Runtime commit: 322588a60e]
anusha GodavarthySurya
Stanley Tsang
Jeremy Newton
German Andryeyev
Chauncey Hui
Sreekant Somasekharan
pghafari
Wenkai Du
Wenkai Du
Icarus Sparry
Maneesh Gupta
Rahul Garg
Sean Keely