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]
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]
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]
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: 92af5e4375]
extern "C" on Windows implies nothrow. We shouldn't be throwing exceptions either way.
Change-Id: If0ed1f7ec194bf7f65b7cea1a5c250e768a8f190
[ROCm/hip commit: 38004b6ef0]
Handle converting signed int cases of hipResourceViewFormat to number of channels.
Change-Id: Ica8ae6f644edfaa0d4803d0b8e90e320479118e2
[ROCm/hip commit: 90feaf046f]
HIP assumes that image width is in bytes, but VDI assumes that image width in pixels. Need to perform byte -> pixel coversion before doing anything.
Change-Id: Ia9fd1f46d05db3fbe8049add10b4d7e5118a2b9a
[ROCm/hip commit: 3fc50731ae]
Vladislav Sytchenko
Jiabao Xie
Sarbojit Sarkar
Jatin Chaudhary
Tao Sang
Saleel Kudchadker
Sameer Sahasrabuddhe
Yaxun Liu
Julia Jiang
Lad, Aditya
Evgeny Mankov
agodavar
German Andryeyev