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
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
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
Fix compilation error on hip-hcc+clang , hip-vdi+clang
Enabled hipExtLaunchMultiKernelMultiDevice test on hip-vdi path
hipExtLaunchMultiKernelMultiDevice common declaration for all paths
Change-Id: I76031840614fce8e12a8e845548fa43a389a741a
* Device texture functions should not normalize the sampled pixel. This is already done by HW.
* Add support to use h/w capability for normalized float data convertion for driver API's
Co-authored-by: ansurya <50609411+ansurya@users.noreply.github.com>
Fixes SWDEV-218626 and SWDEV-218629
Changes:
- Revert "`static inline` in a header, just like excess sugar in a diet, causes bloat (#1692)"
This reverts commit be70b9f7e7.
- Revert "Fix rocFFT build failure (#1777)"
This reverts commit 753277422a.
This PR is a follow-up on PR# #1698 and it makes two more APIs (hipLaunchCooperativeKernel/hipLaunchCooperativeKernelMultiDevice) inline so that they can work correctly with lazy binding.
* fix linking of vector types when linking hipcc objects with gcc
* use __atribute__((vector_size)) with both clang and gcc
and reinstate nonaligned n=3 vector type
* use implicit conversion to value and ext_vector_type when available
* Alternate formulation for GCC compatibility
* Built-in arrays don't mix well with placement new
* Fix typo
* Add conversions to enum
* Fix Scalar_accessor assignment.
* Update hip_vector_types.h
* stir up the underlying_type hideous mess
This fixes the HIP build issue "error: only enumeration types have underlying types".
Reverting #1673, #1697 and #1707.
Support for hipMemcpyWithStream and memcpy optimizations, will be brought in again once issues seen with these are resolved independently.
[Background] it was found that if lazy linking used for a library that calls hipExtLaunchMultiKernelMultiDevice API then this API can get the wrong program_state object for looking up device kernels leading to a "No device code available" error in this API.
To fix this issue, the API was refactored to be inline and get and pass the correct program_state to an internal hip API to request a multi-device kernel launch.