Joseph Greathouse
f68149eafd
Update HIP's unsafeAtomicAdd to: - Compile properly even when not compiling for gfx90a - Fall back to safe atomic add on non-gfx90a architectures - use flat atomic add for FP64 on gfx90a, instead of dynamically checking memory spaces. In addition, when the compiler is passed -munsafe-fp-atomics, it will define __AMDGCN_UNSAFE_FP_ATOMICS__. When this happens, the compiler is requesting that the HIP headers force all HIP atomicAdd() calls on floats or doubles to use their unsafe versions. This patch thus causes unsafeAtomicAdd() calls when that define is seen. This call to unsafeAtomicAdd() is also done for atomicSub(), since that calls atomicAdd underneath. This is not done for system-scope atomicAdd because, on gfx90a, system-scope atomic FP add instructions would need to target fine-grained memory, which is always unsafe. This patch also creates safeAtomicAdd() functions for float and double. These functions will create a standalone safe atomic, even when the application is compiled with -munsafe-fp-atomics. Finally, this patch adds wrappers in the Nvidia path of HIP so that these HIP functions call through to atomicAdd there as well. Change-Id: I8af0621d3d28ea30c9278bfeea7393d03bbdac6d
What is this repository for?
This repository provides HIP implementation specifically for AMD platform.
DISCLAIMER
The information presented in this document is for informational purposes only and may contain technical inaccuracies, omissions, and typographical errors. The information contained herein is subject to change and may be rendered inaccurate for many reasons, including but not limited to product and roadmap changes, component and motherboard versionchanges, new model and/or product releases, product differences between differing manufacturers, software changes, BIOS flashes, firmware upgrades, or the like. Any computer system has risks of security vulnerabilities that cannot be completely prevented or mitigated.AMD assumes no obligation to update or otherwise correct or revise this information. However, AMD reserves the right to revise this information and to make changes from time to time to the content hereof without obligation of AMD to notify any person of such revisions or changes.THIS INFORMATION IS PROVIDED ‘AS IS.” AMD MAKES NO REPRESENTATIONS OR WARRANTIES WITH RESPECT TO THE CONTENTS HEREOF AND ASSUMES NO RESPONSIBILITY FOR ANY INACCURACIES, ERRORS, OR OMISSIONS THAT MAY APPEAR IN THIS INFORMATION. AMD SPECIFICALLY DISCLAIMS ANY IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY, OR FITNESS FOR ANY PARTICULAR PURPOSE. IN NO EVENT WILL AMD BE LIABLE TO ANY PERSON FOR ANY RELIANCE, DIRECT, INDIRECT, SPECIAL, OR OTHER CONSEQUENTIAL DAMAGES ARISING FROM THE USE OF ANY INFORMATION CONTAINED HEREIN, EVEN IF AMD IS EXPRESSLY ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. AMD, the AMD Arrow logo, and combinations thereof are trademarks of Advanced Micro Devices, Inc. Other product names used in this publication are for identification purposes only and may be trademarks of their respective companies.
© 2021 Advanced Micro Devices, Inc. All Rights Reserved.
Repository branches:
The hipamd repository maintains several branches. The branches that are of importance are:
- Main branch: This is the stable branch. It is up to date with the latest release branch, for example, if the latest HIP release is rocm-4.4, main branch will be the repository based on this release.
- Develop branch: This is the default branch, on which the new features are still under development and visible. While this maybe of interest to many, it should be noted that this branch and the features under development might not be stable.
- Release branches. These are branches corresponding to each ROCM release, listed with release tags, such as rocm-4.4, etc.
Release tagging:
hipamd releases are typically naming convention for each ROCM release to help differentiate them.
- rocm x.yy: These are the stable releases based on the ROCM release. This type of release is typically made once a month.*