SWDEV-198863 - Options for hip-clang-vdi path to provide the chicken bits, or functional equivalents to HCC_DB (phase 1)
1. The log macros is turned off for release build. So log functions has zero impact to release build.
2. The log macros have level, mask, condition control. So we can have more control to avoid log flooding.
I also adjusted some existing log to use new log functions.
1. To excercise and test the new log functions.
2. To improve performance slightly.
3. The change is mainly for HIP-ROCM, we can move more in next phases for PAL or ORCA.
4. I make these log feature unavailable for release build. We can revert to old log functions for release build in a case by case method.
Tests:
1. http://ocltc.amd.com:8111/viewModification.html?modId=128289&personal=true&tab=vcsModificationBuildshttp://ocltc.amd.com:8111/viewModification.html?modId=128358&personal=true&tab=vcsModificationBuilds
2. release build, run hip program, there is no log
3. fastdebug build, run hip program,
export LOG_LEVEL=3
export GPU_LOG_MASK=4294967295
There was a lot of logs.
4. fastdebug build, run hip program,
export LOG_LEVEL=2
export GPU_LOG_MASK=4294967295
There was no logs.
5. fastdebug build, run hip program,
export LOG_LEVEL=3
export GPU_LOG_MASK=4294967294
There was much less logs.
6. fastdebug build, run hip program,
export LOG_LEVEL=3
export GPU_LOG_MASK=47102
There was even much less logs. The logs was expected according to the mask.
7. Tested step 2 to 6 similarily in Windows and Linux
ReviewBoard: http://ocltc.amd.com/reviews/r/18215
Affected files ...
... //depot/stg/opencl/drivers/opencl/api/hip/hip_internal.hpp#46 edit
... //depot/stg/opencl/drivers/opencl/api/hip/hip_memory.cpp#82 edit
... //depot/stg/opencl/drivers/opencl/api/hip/hip_stream.cpp#26 edit
... //depot/stg/opencl/drivers/opencl/api/hip/hiprtc_internal.hpp#2 edit
... //depot/stg/opencl/drivers/opencl/api/opencl/amdocl/cl_svm.cpp#29 edit
... //depot/stg/opencl/drivers/opencl/runtime/device/comgrctx.cpp#6 edit
... //depot/stg/opencl/drivers/opencl/runtime/device/devkernel.cpp#29 edit
... //depot/stg/opencl/drivers/opencl/runtime/device/devprogram.cpp#68 edit
... //depot/stg/opencl/drivers/opencl/runtime/device/rocm/rocdevice.cpp#137 edit
... //depot/stg/opencl/drivers/opencl/runtime/device/rocm/rocvirtual.cpp#91 edit
... //depot/stg/opencl/drivers/opencl/runtime/platform/command.cpp#100 edit
... //depot/stg/opencl/drivers/opencl/runtime/platform/commandqueue.cpp#32 edit
... //depot/stg/opencl/drivers/opencl/runtime/platform/runtime.cpp#40 edit
... //depot/stg/opencl/drivers/opencl/runtime/utils/debug.hpp#10 edit
... //depot/stg/opencl/drivers/opencl/runtime/utils/flags.hpp#323 edit
[ROCm/clr commit: 1eb26b28bb]
SWDEV-198863 - Options for hip-clang-vdi path to provide the chicken bits, or functional equivalents to HCC_DB (phase 1)
1. The log macros is turned off for release build. So log functions has zero impact to release build.
2. The log macros have level, mask, condition control. So we can have more control to avoid log flooding.
I also adjusted some existing log to use new log functions.
1. To excercise and test the new log functions.
2. To improve performance slightly.
3. The change is mainly for HIP-ROCM, we can move more in next phases for PAL or ORCA.
4. I make these log feature unavailable for release build. We can revert to old log functions for release build in a case by case method.
Tests:
1. http://ocltc.amd.com:8111/viewModification.html?modId=128289&personal=true&tab=vcsModificationBuildshttp://ocltc.amd.com:8111/viewModification.html?modId=128358&personal=true&tab=vcsModificationBuilds
2. release build, run hip program, there is no log
3. fastdebug build, run hip program,
export LOG_LEVEL=3
export GPU_LOG_MASK=4294967295
There was a lot of logs.
4. fastdebug build, run hip program,
export LOG_LEVEL=2
export GPU_LOG_MASK=4294967295
There was no logs.
5. fastdebug build, run hip program,
export LOG_LEVEL=3
export GPU_LOG_MASK=4294967294
There was much less logs.
6. fastdebug build, run hip program,
export LOG_LEVEL=3
export GPU_LOG_MASK=47102
There was even much less logs. The logs was expected according to the mask.
7. Tested step 2 to 6 similarily in Windows and Linux
ReviewBoard: http://ocltc.amd.com/reviews/r/18215
Affected files ...
... //depot/stg/opencl/drivers/opencl/api/hip/hip_internal.hpp#46 edit
... //depot/stg/opencl/drivers/opencl/api/hip/hip_memory.cpp#82 edit
... //depot/stg/opencl/drivers/opencl/api/hip/hip_stream.cpp#26 edit
... //depot/stg/opencl/drivers/opencl/api/hip/hiprtc_internal.hpp#2 edit
... //depot/stg/opencl/drivers/opencl/api/opencl/amdocl/cl_svm.cpp#29 edit
... //depot/stg/opencl/drivers/opencl/runtime/device/comgrctx.cpp#6 edit
... //depot/stg/opencl/drivers/opencl/runtime/device/devkernel.cpp#29 edit
... //depot/stg/opencl/drivers/opencl/runtime/device/devprogram.cpp#68 edit
... //depot/stg/opencl/drivers/opencl/runtime/device/rocm/rocdevice.cpp#137 edit
... //depot/stg/opencl/drivers/opencl/runtime/device/rocm/rocvirtual.cpp#91 edit
... //depot/stg/opencl/drivers/opencl/runtime/platform/command.cpp#100 edit
... //depot/stg/opencl/drivers/opencl/runtime/platform/commandqueue.cpp#32 edit
... //depot/stg/opencl/drivers/opencl/runtime/platform/runtime.cpp#40 edit
... //depot/stg/opencl/drivers/opencl/runtime/utils/debug.hpp#10 edit
... //depot/stg/opencl/drivers/opencl/runtime/utils/flags.hpp#323 edit
[ROCm/clr commit: 759a2c2ce5]
SWDEV-198863 - Options for hip-clang-vdi path to provide the chicken bits, or functional equivalents to HCC_DB (phase 1)
1. The log macros is turned off for release build. So log functions has zero impact to release build.
2. The log macros have level, mask, condition control. So we can have more control to avoid log flooding.
I also adjusted some existing log to use new log functions.
1. To excercise and test the new log functions.
2. To improve performance slightly.
3. The change is mainly for HIP-ROCM, we can move more in next phases for PAL or ORCA.
4. I make these log feature unavailable for release build. We can revert to old log functions for release build in a case by case method.
Tests:
1. http://ocltc.amd.com:8111/viewModification.html?modId=128289&personal=true&tab=vcsModificationBuildshttp://ocltc.amd.com:8111/viewModification.html?modId=128358&personal=true&tab=vcsModificationBuilds
2. release build, run hip program, there is no log
3. fastdebug build, run hip program,
export LOG_LEVEL=3
export GPU_LOG_MASK=4294967295
There was a lot of logs.
4. fastdebug build, run hip program,
export LOG_LEVEL=2
export GPU_LOG_MASK=4294967295
There was no logs.
5. fastdebug build, run hip program,
export LOG_LEVEL=3
export GPU_LOG_MASK=4294967294
There was much less logs.
6. fastdebug build, run hip program,
export LOG_LEVEL=3
export GPU_LOG_MASK=47102
There was even much less logs. The logs was expected according to the mask.
7. Tested step 2 to 6 similarily in Windows and Linux
ReviewBoard: http://ocltc.amd.com/reviews/r/18215
Affected files ...
... //depot/stg/opencl/drivers/opencl/api/hip/hip_internal.hpp#46 edit
... //depot/stg/opencl/drivers/opencl/api/hip/hip_memory.cpp#82 edit
... //depot/stg/opencl/drivers/opencl/api/hip/hip_stream.cpp#26 edit
... //depot/stg/opencl/drivers/opencl/api/hip/hiprtc_internal.hpp#2 edit
... //depot/stg/opencl/drivers/opencl/api/opencl/amdocl/cl_svm.cpp#29 edit
... //depot/stg/opencl/drivers/opencl/runtime/device/comgrctx.cpp#6 edit
... //depot/stg/opencl/drivers/opencl/runtime/device/devkernel.cpp#29 edit
... //depot/stg/opencl/drivers/opencl/runtime/device/devprogram.cpp#68 edit
... //depot/stg/opencl/drivers/opencl/runtime/device/rocm/rocdevice.cpp#137 edit
... //depot/stg/opencl/drivers/opencl/runtime/device/rocm/rocvirtual.cpp#91 edit
... //depot/stg/opencl/drivers/opencl/runtime/platform/command.cpp#100 edit
... //depot/stg/opencl/drivers/opencl/runtime/platform/commandqueue.cpp#32 edit
... //depot/stg/opencl/drivers/opencl/runtime/platform/runtime.cpp#40 edit
... //depot/stg/opencl/drivers/opencl/runtime/utils/debug.hpp#10 edit
... //depot/stg/opencl/drivers/opencl/runtime/utils/flags.hpp#323 edit
[ROCm/clr commit: 3f6e18bf6b]
SWDEV-2 - Change OpenCL version number from 3030 to 3031.
Affected files ...
... //depot/stg/opencl/drivers/opencl/runtime/utils/versions.hpp#2778 edit
[ROCm/clr commit: 68340fee18]
SWDEV-2 - Change OpenCL version number from 3029 to 3030.
Affected files ...
... //depot/stg/opencl/drivers/opencl/runtime/utils/versions.hpp#2777 edit
[ROCm/clr commit: 60eea61dd7]
SWDEV-200688 - Correct some misalignment between DeviceInfo and CALtarget, so that VEGAM can be correctly recognized as gfx804 instead of gfx902
Affected files ...
... //depot/stg/opencl/drivers/opencl/runtime/device/gpu/gslbe/src/rt/caltarget.h#10 edit
[ROCm/clr commit: ec18fcbc84]
SWDEV-2 - Change OpenCL version number from 3028 to 3029.
Affected files ...
... //depot/stg/opencl/drivers/opencl/runtime/utils/versions.hpp#2776 edit
[ROCm/clr commit: 6b680186bc]
SWDEV-145570 - [HIP] Fix occupancy API prototype.
- They need to be C API, i.e. extern "C".
- Follow the current API and use `uint32_t` instead of `int`.
+ TODO: We need to revert them back once that APIs are changed to be
compatible with CUDA.
Affected files ...
... //depot/stg/opencl/drivers/opencl/api/hip/hip_platform.cpp#46 edit
[ROCm/clr commit: 988882bb4f]
- Fix 2 runtime API prototypes
`hipOccupancyMaxActiveBlocksPerMultiprocessor` and
`hipOccupancyMaxActiveBlocksPerMultiprocessorWithFlags`
- Add missing function templates of them in hip-clang.
[ROCm/clr commit: 61bc68a5f4]
SWDEV-208424 - ROCr language runtime should not free code object until executable destroy
- Reshuffle the code to make sure HSA runtime can keep the pointer to the code object
Affected files ...
... //depot/stg/opencl/drivers/opencl/runtime/device/devprogram.cpp#67 edit
[ROCm/clr commit: 783f1a506c]
The lifetime of the buffer given to
hsa_code_object_reader_create_from_memory must exceed that of the
code object reader. We need to create a copy of the code object
binary memory (file) that is kept allocated until the code object
reader is destroyed.
[ROCm/clr commit: 66c91b42e6]
SWDEV-2 - Change OpenCL version number from 3027 to 3028.
Affected files ...
... //depot/stg/opencl/drivers/opencl/runtime/utils/versions.hpp#2775 edit
[ROCm/clr commit: c081898145]
SWDEV-2 - Change OpenCL version number from 3026 to 3027.
Affected files ...
... //depot/stg/opencl/drivers/opencl/runtime/utils/versions.hpp#2774 edit
[ROCm/clr commit: a8e96b1d3d]
SWDEV-79445 - OCL generic changes and code clean-up
- Fix memory leaks in COMGR path. Don't create binaryData, since it will be overwritten with action_data_get_data() call.
Affected files ...
... //depot/stg/opencl/drivers/opencl/runtime/device/devprogram.cpp#65 edit
[ROCm/clr commit: e22fe683e7]
SWDEV-204995 - Linux Pro: Houdini18 Application hang is seen with pyro sample on OpenCL selection.
The new Houdini application has around 286.6K byte TLS. In Linux, the TLS resides in thread stack. TLS is allocated and initialized during pthread_create.
If command queue thread stack size is only 256k byte, pthread_create function failed with return value EINVAL.
The above information is verified by this test:
I printed out the address of a __thread variable. Then I printed out an address of a local variable. I confirmed both variables are in the same memory segment according to /proc/id/maps. This memory segment is same size of CQ_THREAD_STACK_SIZE and changed with this environment variable.
The __thread variable is 286.6K byte away from the bottom of the stack but still inside the stack.
I have added printf to verify function guessTlsSize can guess tlsSize correctly. And pthread_create succeeded in first invocation with tls size adjustment.
Tests:
1. Test houdini - PASS
2. http://ocltc.amd.com:8111/viewModification.html?modId=128021&personal=true&tab=vcsModificationBuilds
ReviewBoard: http://ocltc.amd.com/reviews/r/18175
Affected files ...
... //depot/stg/opencl/drivers/opencl/runtime/os/os_posix.cpp#47 edit
[ROCm/clr commit: be8023429a]
foreman
Jeff Daily
Alex Voicu
Evgeny Mankov
Rahul Garg
Rahul Garg
Laurent Morichetti
Michael LIAO