Update the packaging code to be CMake 3.5 compatible for CI. Create two
packages rocm-opencl and rocm-opencl-dev on Ubuntu and CentOS. Add
proper versioning into naming.
Change-Id: I116081b7f6f7efa4be43ab3a66e4d3bff0589298
[ROCm/clr commit: b3d035b1dc]
Update the packaging code to be CMake 3.5 compatible for CI. Create two
packages rocm-opencl and rocm-opencl-dev on Ubuntu and CentOS. Add
proper versioning into naming.
Change-Id: I116081b7f6f7efa4be43ab3a66e4d3bff0589298
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/clr commit: b4a0008b36]
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
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]
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
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/clr commit: 8667e21b25]
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
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]
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
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/clr commit: a994da8af6]
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
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]
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
Vladislav Sytchenko
Divya Shikre
Aaron Enye Shi
Jiabao Xie
kjayapra-amd
rkebichi
Sarbojit Sarkar
Evgeny Mankov