* 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>
* Add missing texturePitchAlignment member to the hipDeviceProp_t struct.
* Add missing hipDeviceAttributeTexturePitchAlignment enumerator to the hipDeviceAttribute_t enum.
* Initialize texturePitchAlignment to 256. This works for gfx9+, but is technically overaligned in most cases for pre-gfx9.
* Add the texturePitchAlignment property to the NVCC path.
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.
* Fix hipcc warning related to hipVersion
* Rename hipVersion.h to hip_version.h
* Remove HIP_VERSION splitting
* Update .gitignore
- Ignore generated include/hip/hip_version.h
- Removed some stale entries
- Added executables from samples/1_Utils/*/ for consistency with bin/ entries.
HIP_VERSION_MAJOR, HIP_VERSION_MINOR, HIP_VERSION_PATCH and HIP_VERSION pre-processor macros are now defined in hipVersion.h instead of being set by hipcc.
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.