The build should never touch the source directory, and only write
generated files to the output directory.
Also track the dependency with a custom command and target, as is the
normal method for dependencies on generated files.
Change-Id: I9d835256c643aeef241d26ca05ab390ebba65111
Don't rely on shell commands. On Ubuntu 20.04, /usr/bin/python no
longer exists, so I'm seeing some failures from somewhere assuming the
path.
The top level CMakeLists also repeats exactly this, which should be
fixed.
Change-Id: I56b26742920f0dc40b363b409892bd41cfa485ef
Embedded device binaries should not be cloned if we want the ROCR's
code object URI for this binary to point to the container (host
executable or shared library) instead of a memory location.
Depends-On: I7973bb0243f5a2d1b639b8a88445cfe6af919dd7
Change-Id: Id3afc981e027e5371114d011f2caaa6414f5fc58
1. Enable versioning for HIP libraries
2. Enable RUNPATH on HIP libraries to find ROCm dependencies
3. Control HIP package install using CPACK_INSTALL_PREFIX
Change-Id: I9096da56592e9c78cdba329011f6e1bae99adaa2
- As different modules may have symbols with the same name, each symbol
needs identifying with a pair of the module handle and the symbol
name.
Change-Id: I85650a787d9a424545154cc40ebd59e706fa358f
hipEventRecord is much slower in hipclang/vdi
- Make sure default streams don't sync each other.
- Add null stream into the list of default streams.
- Code clean-up to simplify queue look-up.
Change-Id: I36e1fc8d86a600e3dce806694d95d146ed8afd03
- HIPPerfDispatchSpeed disparity between HIP/HCC vs HIP/VDI
Insert a wait marker command in the default stream only when
HIP has pending operations on other async streams
Change-Id: I68660a54867fab7571ba57eb1df5feb1bca1c61a
1.Combine libamdhip64_static_base.a and libamdvdi_static.a into libamdhip64_static.a.
2.Let hipcc use -use-staticlib to link libamdhip64_static.a.
3.Add some samples for static lib.
4.Fix compiling failure of code object.
Change-Id: Ic8c95228eb139058da8b5d66ba8439486154ca6f
This reverts commit 5210ee6ca5.
Reason for revert: It is causing dkms-no-npi-hipclang broken.
It is top priority to maintain dkms-no-npi-hipclang build, otherwise we lose track of regression analysis.
So revert the change for now and recommit it after fixing it.
Change-Id: Ia5136e888baecb6148c6c18eedbf37066fcb1eaa
1.Combine libamdhip64_static_base.a and libamdvdi_static.a into libamdhip64_static.a.
2.Let hipcc use -use-staticlib to link libamdhip64_static.a.
3.Add some samples for static lib.
4.Fix compiling failure of code object.
Change-Id: Ia2333622a8d05639b90974c4c5d3d85654ba0138
Since we adjust we adjust the start of the region, amd::BufferRect::end_ is no longer the size, just the offset as to where the region ends.
The actual size of the region is (amd::BufferRect::end_ - amd::BufferRect::start_).
Change-Id: I8425d8bdfb20f485740863813e762e8923d9ee94
This is charrypick of 9ead991784
and https://github.com/ROCm-Developer-Tools/HIP/pull/2009
Fix cmake config file
Removed cmake target files under packaging directory.
Merged cmake config .in files for HIP-Clang and HCC as one.
Use cmake generated target files in both install and packaging.
This makes cmake config file consistent for make install and
make package.
Let device side malloc/free return nullptr and trap
Change-Id: I448f3ea2d4934648089bad371debc203f895cba6
VDI reports the limits in pixels, but user provides the size in bytes.
Make sure both values are in pixels before doing comparisons.
Change-Id: I082c7175c9fa4383e0b0ee38ff8c047c26ff20b4
The following warnings are addressed:
comparison of different enumeration types in switch statement
Change-Id: I6cb3948aeab7287851c57ecc1d4b3a439ab14ec6
Support hipLaunchCooperativeKernelMultiDevice()
- Add validation logic for MGPU launches to pass a cuda test
Change-Id: Iccca7fde43493fc3bc6685512d39202271ae3e92
Support hipLaunchCooperativeKernelMultiDevice()
- Add hipCooperativeLaunchMultiDeviceNoPreSync and
hipCooperativeLaunchMultiDeviceNoPostSync support to pass a cuda test
Change-Id: If518f11ef2636a2235e5df9e77f879d8ced68102
These fixes address regressions caused by http://gerrit-git.amd.com/c/compute/ec/hip/+/337601
Currently we're converting a 1D offset into a 3D offset, which doesn't make much sense once you consider the fact that this offset is relative to a different origin than our current 3D offset.
I traced through our blit kernels in VDI - the copy buffer rect path is able to handle immediate offsets in the 3D buffer via the amd::BufferRect::start_ parameter.
Instead of adjusting the offset, simply adjust the start of the region.
Change-Id: Ic8797a2c8ac0ad106f246f61ff06ca1ca03d3058
Matt Arsenault
Michael Hong Bin Liao
Payam Ghafari
Laurent Morichetti
Saleel Kudchadker
German Andryeyev
Vlad Sytchenko
Freddy Paul
kjayapra-amd
root
Maneesh Gupta
Evgeny Shcherbakov
Tao Sang
Yaxun (Sam) Liu
Christophe Paquot