Latest llvm already includes the texture/surface rework, but appropriate runtime changes have not been submitted.
Disable all texture related tests until http://gerrit-git.amd.com/c/compute/ec/hip/+/342147 is submitted.
Change-Id: I359c2eac6becdd3ca5110f2140679bd29d8ae54b
[ROCm/hip commit: de67236a27]
- It should be a volatile-qualified member function instead of returning
volatile type.
Change-Id: Id7aaa1953d56151b59e469ef22b9f4280f63bebb
[ROCm/hip commit: a48b312aa9]
This reverts commit f3bdfe2baa.
Reason for revert: German advised againt this change.
Change-Id: Ia1b1b9db60c965b2d9c006bd7d20012a9d7697e1
[ROCm/hip commit: 71f850f9ec]
Support hipLaunchCooperativeKernelMultiDevice()
- Add validation logic for MGPU launches to pass a cuda test
Change-Id: Iccca7fde43493fc3bc6685512d39202271ae3e92
[ROCm/hip commit: 5fe91ccb1b]
Support hipLaunchCooperativeKernelMultiDevice()
- Add hipCooperativeLaunchMultiDeviceNoPreSync and
hipCooperativeLaunchMultiDeviceNoPostSync support to pass a cuda test
Change-Id: If518f11ef2636a2235e5df9e77f879d8ced68102
[ROCm/hip commit: da1444bfc8]
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
[ROCm/hip commit: 1bd640b659]
If the code object is embedded in an already mapped file, and the
lifetime of the mapped file exceeds the lifetime of the executable,
we do not need to make a copy of the binary.
This allows the ROCR to present the code object URI as
file:///path/to/file#offset=X&size=Y.
[ROCm/hip commit: 9de5e90ab5]
libc++ defines fma as template function for auto promotion of mixed-type
arguments. libc++ does not handle _Float16 as _Float16 is not a supported
type by C++ standard. As such, it is unlikely we can commit our fix for
_Float16 to libc++ trunk.
Therefore we handle _Float16 with a template specialization of
__numeric_type in HIP headers.
Change-Id: If01960a657ebf1a7a67463cdcf66fab7458dff3c
[ROCm/hip commit: 4af2106d10]
Tests that check POSIX specifiers with a single thread:
- hipPrintfSpecifiers.cpp : all conversion specifiers
- hipPrintfFlags.cpp : common flags that modify conversions
- hipPrintfAltForms.cpp : alternate forms ('#')
- hipPrintfStar.cpp : additional arguments ('*')
- hipPrintfWidthPrecision.cpp : floating point details
Tests that check functionality on top of hostcall
- hipPrintfBasic.cpp : divergent calls, series of calls, return value, etc
- hipPrintfManyWaves.cpp : many waves printing together
- hipPrintfManyDevices.cpp : many waves on many devices
Change-Id: I35e069f4c542f896999239996dc89eda0faad7b8
[ROCm/hip commit: db3e17d552]
This adds the missing compilation flags to hip::device so it can compile with hip-clang compiler.
Change-Id: Ie2b30ea606bfca385a0e84ae03ee0a8d828ad16a
[ROCm/hip commit: 2c246dabfe]
Even though the runtime and driver texture object API is one to one, the structs used by these APIs are not. See hipResourceDesc vs HIP_RESOURCE_DESC differences.
These differences are not trivial and most likely won't be able to handled by hipify, so we need new API entry points.
Change-Id: Id4bcb1ad0ae15378dbdb5a2ed07e5ea30f320082
[ROCm/hip commit: aea688b79c]
Fixes github issue: #1754
- When ResourceDesc::resType is hipResourceTypeLinear ignore address mode and filter mode.
- When textureDesc::normalizedCoords is set to zero, AddressModeWrap and AddressModeMirror won't be supported and will be switched to AddressModeClamp.
[ROCm/hip commit: 50ef250a3b]