P4 to Git Change 2024454 by axie@axie-hip-rocm on 2019/11/04 14:38:31

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=vcsModificationBuilds
	http://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

opencl/api/opencl/amdocl/cl_svm.cpp

@@ -74,7 +74,7 @@ static bool validateMapFlags(cl_map_flags flags) {
  *  \param size is the size in bytes of the SVM buffer to be allocated.
  *
  *  \param alignment is the minimum alignment in bytes that is required for the
- *  newly created buffer’s memory region. It must be a power of two up to the
+ *  newly created buffer?s memory region. It must be a power of two up to the
  *  largest data type supported by the OpenCL device. For the full profile, the
  *  largest data type is long16. For the embedded profile, it is long16 if the
  *  device supports 64-bit integers; otherwise it is int16. If alignment is 0, a
@@ -169,7 +169,7 @@ RUNTIME_ENTRY_RET_NOERRCODE(void*, clSVMAlloc, (cl_context context, cl_svm_mem_f
   // if alignment not specified, use largest data type alignment supported
   if (alignment == 0) {
     alignment = minContextAlignment;
-    LogPrintfInfo("Assumed alignment %d\n", alignment);
+    ClPrint(amd::LOG_INFO, amd::LOG_API, "Assumed alignment %d\n", alignment);
   }
 
   amd::Context& amdContext = *as_amd(context);
@@ -876,7 +876,7 @@ RUNTIME_EXIT
  *  (clEnqueueNDRangeKernel) until the argument value is changed by a call to
  *  clSetKernelArgSVMPointer for \a kernel. The SVM pointer can only be used for
  *  arguments that are declared to be a pointer to global or constant memory.
- *  The SVM pointer value must be aligned according to the argument�s type. For
+ *  The SVM pointer value must be aligned according to the argument?s type. For
  *  example, if the argument is declared to be global float4 *p, the SVM pointer
  *  value passed for p must be at a minimum aligned to a float4. The SVM pointer
  *  value specified as the argument value can be the pointer returned by