reinterpret_cast<> doesn't create an object, so the texref is actually unitiliazed. This may lead to garbage data in some of its struct members.
Initialize it by performing a placement new. The constructer should set all of its members to default values. There's no way currently to extract the channel type, so use single channel char for now.
Change-Id: I41b305a75bb3f30130324de785099f55b3e130c7
[ROCm/hip commit: 292d008a64]
Similar to the previous patch, this change adds type constraints to texture indirect functions. Since we don't have to deduce the return type for these, we simply just have to check if the user provided a valid channel type.
Change-Id: Ia094bd6126e01df2ea90902c9aa59cb6cfe85773
[ROCm/hip commit: 117f0ab102]
When sampling a pixel the hw always returns a float4. The type in the texture reference controls the bitcast that we perform before returning the sampled pixel. Creating a texture with an unsupported will lead to potential UB.
This change makes it so that it's only possible to use textures with a type that makes sense. Using something like texture<int, hipTextureType1D, hipReadModeNormalizedFloat> will now lead to a compilation error with a message "Invalid channel type!".
Change-Id: I7fde44cb1d4b9737e0c48c28cb59c018c59ccaa2
[ROCm/hip commit: ef2415edc7]
HIP-Clang cuda_wrapper headers require clang include path before standard C++ include path.
However libc++ include path requires to be before clang include path.
To workaround this, we pass -isystem with the parent directory of clang include
path instead of the clang include path itself.
[ROCm/hip commit: 08d9759eba]
This PR takes ensures that the maxThreadsPerBlock returned by hipFuncGetAttributes is both a multiple of the warp size and that the register usage of the maximum block does not exceed the number of available registers.
Fixes#1662
[ROCm/hip commit: b5e683a35d]
This change addresses three things.
First the available APIs are brought up to par with Cuda (missing ones are added and incorrect ones removed).
Second the size of hip/hcc_detail/texture_functions.h. Using some template magic we can bring down the code size down from ~11k lines to only ~900 lines in total.
Third this change fixes some bugs in the declaration of the texture fetch funcitons. Currently the return type for textures with read mode set to hipReadModeNormalizedFloat is not float. This causes pixel data to be lost during the bitcast when the texture pixel element size is less than the size of float.
The new headers will only be enabled for VDI to avoid breaking HCC.
Change-Id: I77cb29293fb79e55681be094c37702a48d80b64c
[ROCm/hip commit: a0751402d8]
This is currently so buggy that it causes a runtime crash on Nvidia platfrom...
Disable the new version for hcc and vdi, header fixes are required for it to pass.
Currently tex1D<char, hipTextureType1D, hipReadModeNormalizedFloat> returns a char, when the actual sampled pixel value is a float, so the hi 3 bytes get lost.
Change-Id: I8222a4d8d1d8b101eb43f3f8dfbe4818f885f8ea
[ROCm/hip commit: cc134f7c58]
Implement _ihipGetGlobalVar() and ihipGetGlobalVar() to
get global variables.
Change-Id: I442ab6712e12306c3316f114f5dc42f6daefaad9
[ROCm/hip commit: d432dbfe20]
This allows printf to work with hip-clang and HCC runtime. See comments under #1919 for a reported bug and feature request.
[ROCm/hip commit: 899c878703]
GCC emits a warning about using static functions like
hipCUDAErrorTohipError inside this function, because it has an
inline directive, but it's not static. Adding static to this function
to silence warnings (and prevent potential problems in the future).
[ROCm/hip commit: f7e85649f4]
NVCC warned if you tried to use hipOccupancyMaxActiveBlocksPerMultiprocessor
because when passing in a device function pointer, "const void* func" was
insufficient to describe it accurately. Adding a C++ templated class type
definition for this function.
[ROCm/hip commit: 4128d68ed7]
Fixes SWDEV-207362,
The output file name should not contribute to picking up the right flags for the compiler. This fix solves issues when the output has conflicting extensions which confuses hipcc to treat them as the source files and add the required flags for them.
PS: Output file refers to the file followed by -o
Example: hipcc test.o -o test.hip will add the flags for .hip compilation ignoring the fact that it is an output file
[ROCm/hip commit: 7bcfdf017d]
Query ROCr to see if we have the proper lower-level support for
cooperative groups -- GWS support through the firmware, driver,
thunk, and ROCr. ROCr does these checks for us, and presents a
query that allows us to see if GWS entries are available for use.
If so, then we have all the lower-level technologies needed, and
we should enable cooperative groups support for HIP.
[ROCm/hip commit: 18e6c529bc]
Fixes SWDEV-226025,
Right now -x c++ can come before libhip_hcc.so which forces the compiler to treat libhip_hcc.so as a text file and generates a lot of gibberish unicode. This PR changes the order of flags ensuring that -x c++ and similar flags come after libhip_hcc.so
Hopefully, this will not have any negative side effect.
[ROCm/hip commit: bbbb8bf1e6]
The maxSharedMemoryPerMultiProcessor attribute is meant to describe
the number of bytes of shared memory (LDS space in AMD terminology)
in each SM (CU in AMD terminology). For instance, on AMD GPUs this
is often 64KB per CU, and some Nvidia GPUs it's 96KB per SM.
This shared memory is a different address space from the normal
global memory. However, the current HIP-HCC properties fill this
in with a size that matches the totalGlboalMem property. This gives
a drastically too-high calculation for the amount of LDS space that
each CU has -- tens of GBs vs. 10s of KBs.
This patch fixes this by pulling the maxSharedMemoryPerMultiProcessor
property from the HSA pool that describes how much workgroup-local
space is available on each CU. The HSA runtime eventually pulls
this from the topology information about LDSSizeInKB, defined as
"Size of Local Data Store in Kilobytes per SIMD".
Previously, this HSA query was used to fill in the value of the
sharedMemPerBlock property. On today's AMD GPUs, we know that
the amount of LDS avaialble to the workgroup is identical to the
amount of LDS space in the CU. However, in the future this may
differ. As such, this patch changes around the order and fills
in the "PerMultiProcessor" property from the HSA query (since
what's what the query is defined to return), and then separately
fills in the "PerBlock" property as we know it.
[ROCm/hip commit: 55e55e78bb]
Fix two errors in hipOccupancyMaxActiveBlocksPerMultiprocessor.
1) Fix a possible segfault if the user passed in a null pointer for
the numBlocks value.
2) Handle the situation when the user is asking for a block size
that is larger than what the target device can hold within a
single block.
[ROCm/hip commit: bf04d7380a]
Currently there is a clang bug on Windows causing duplicate -mllvm options in clang -cc1.
Tempoarily disable -mllvm options for HIP-Clang on Windows until the bug is fixed.
Change-Id: I3a4393ba7745989398dc6c6001722837dad18704
[ROCm/hip commit: 7aa9611689]
- Need to check the availability of `__has_attribute` builtin macro
instead of compiler versions. That's more reliable and portable among
various compilers.
- Provides a very basic support of vectors for unknown compilers.
[ROCm/hip commit: 774035d869]
There are now two implementations of printf in HIP:
1. The implemenation for HCC is controlled by the HC_FEATURE_PRINTF
macro, and it works only with the HCC compiler used in combination
with the HCC runtime.
2. The implementation for hip-clang requires the VDI runtime, and is
always enabled with that combination.
Change-Id: Ibaeda7900ffe2ce602ca0094aafed0f1147ac2b6
[ROCm/hip commit: 64cd527335]
Vladislav Sytchenko
Jiabao Xie
Sarbojit Sarkar
Evgeny Mankov
Jatin Chaudhary
Nagy-Egri Máté Ferenc
Aryan Salmanpour
Yaxun (Sam) Liu
jglaser
Paul Fultz II
Tao Sang
Saleel Kudchadker
Jatin Chaudhary
zhaozhangjian
Sameer Sahasrabuddhe
Joseph Greathouse
Reshabh Sharma
Sarbojit2019
Maneesh Gupta
mhbliao
Sameer Sahasrabuddhe
Alex Voicu