OpenCL

[rosenrodt]

EDIT: reformat 

EDIT 2: correct driver version

Found a weird behavior in AMD's OpenCL compiler. Code taken straight from Boost library:

__kernel void serial_adjacent_find(const uint size, __global uint* output, __global char* buf0) 
{ 
  uint result = size; 
  for (uint i = 0; i<size - 1; i++) {
    if (buf0[i+1] < buf0[i]) {
      result = i;
      break;
    }
  }
  *output = result; }
); ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

The kernel checks if input array `buf0` is monotonically increasing. If any element in the array `buf0` is greater than the next element, it breaks out of the loop and alters the output value, which the host side checks against. When the input array is of type `char`, the kernel will break out of the loop prematurely. However with other types such as int or float this kernel runs fine.

I can repro the bug on AMD RX500/Vega series. Running on Windows 10 + Adrenalin 18.2.2 18.12.2/19.1.1.

I don't see this exact kernel causing an issue with Intel/Nvidia/Qualcomm OpenCL driver compilers.

I have attached a reproducible CMake project here for your quick reference

[dipak]

Thank you for reporting it. We will check and get back to you.

[dipak]

It seems that the "size"  argument of clEnqueueReadBuffer was not correct. Can you please modify the code (in  "main.cpp" file ) as shown below and share your observation?

Replace this line:

clEnqueueReadBuffer(queue, d_output, true, 0, sizeof(decltype(h_buf[0])), h_output, 0, nullptr, nullptr);  

By:

clEnqueueReadBuffer(queue, d_output, true, 0, sizeof(decltype(h_output[0])), h_output, 0, nullptr, nullptr); 

[rosenrodt]

Good catch. That was my mistake when wrapping up a minimal example for the bug report...

Still, the error persists after the read buffer size is corrected. 

[dipak]

After modifying the read buffer size, I didn't observe any issue on my test setup (Hawaii XT/Carrizo + Adrenalin 19.1.1). At this moment, I don't have a RX500/Vega series card to verify it myself. I'll ask the concerned team to reproduce it.

Please share the clinfo output.

Thanks.

[rosenrodt]

I just double-checked again - still no luck even after the corrected read buffer size

The problem with this bug is that older drivers (Adrenalin 18.5.2 & 18.9.1) I tried did not have this strange behavior. I do not observer the same behavior on my other machine with HD6000 series on Crimson driver, though. So please do check running on at least Vega series.

clinfo:

Number of platforms:				 1
  Platform Profile:				 FULL_PROFILE
  Platform Version:				 OpenCL 2.1 AMD-APP (2766.5)
  Platform Name:				 AMD Accelerated Parallel Processing
  Platform Vendor:				 Advanced Micro Devices, Inc.
  Platform Extensions:				 cl_khr_icd cl_khr_d3d10_sharing cl_khr_d3d11_sharing cl_khr_dx9_media_sharing cl_amd_event_callback cl_amd_offline_devices 


  Platform Name:				 AMD Accelerated Parallel Processing
Number of devices:				 1
  Device Type:					 CL_DEVICE_TYPE_GPU
  Vendor ID:					 1002h
  Board name:					 Radeon RX Vega
  Device Topology:				 PCI[ B#3, D#0, F#0 ]
  Max compute units:				 56
  Max work items dimensions:			 3
    Max work items[0]:				 1024
    Max work items[1]:				 1024
    Max work items[2]:				 1024
  Max work group size:				 256
  Preferred vector width char:			 4
  Preferred vector width short:			 2
  Preferred vector width int:			 1
  Preferred vector width long:			 1
  Preferred vector width float:			 1
  Preferred vector width double:		 1
  Native vector width char:			 4
  Native vector width short:			 2
  Native vector width int:			 1
  Native vector width long:			 1
  Native vector width float:			 1
  Native vector width double:			 1
  Max clock frequency:				 1622Mhz
  Address bits:					 64
  Max memory allocation:			 4244635648
  Image support:				 Yes
  Max number of images read arguments:		 128
  Max number of images write arguments:		 64
  Max image 2D width:				 16384
  Max image 2D height:				 16384
  Max image 3D width:				 2048
  Max image 3D height:				 2048
  Max image 3D depth:				 2048
  Max samplers within kernel:			 16
  Max size of kernel argument:			 1024
  Alignment (bits) of base address:		 2048
  Minimum alignment (bytes) for any datatype:	 128
  Single precision floating point capability
    Denorms:					 No
    Quiet NaNs:					 Yes
    Round to nearest even:			 Yes
    Round to zero:				 Yes
    Round to +ve and infinity:			 Yes
    IEEE754-2008 fused multiply-add:		 Yes
  Cache type:					 Read/Write
  Cache line size:				 64
  Cache size:					 16384
  Global memory size:				 8573157376
  Constant buffer size:				 4244635648
  Max number of constant args:			 8
  Local memory type:				 Scratchpad
  Local memory size:				 32768
  Max pipe arguments:				 16
  Max pipe active reservations:			 16
  Max pipe packet size:				 4244635648
  Max global variable size:			 3820172032
  Max global variable preferred total size:	 8573157376
  Max read/write image args:			 64
  Max on device events:				 1024
  Queue on device max size:			 8388608
  Max on device queues:				 1
  Queue on device preferred size:		 262144
  SVM capabilities:				 
    Coarse grain buffer:			 Yes
    Fine grain buffer:				 Yes
    Fine grain system:				 No
    Atomics:					 No
  Preferred platform atomic alignment:		 0
  Preferred global atomic alignment:		 0
  Preferred local atomic alignment:		 0
  Kernel Preferred work group size multiple:	 64
  Error correction support:			 0
  Unified memory for Host and Device:		 0
  Profiling timer resolution:			 1
  Device endianess:				 Little
  Available:					 Yes
  Compiler available:				 Yes
  Execution capabilities:				 
    Execute OpenCL kernels:			 Yes
    Execute native function:			 No
  Queue on Host properties:				 
    Out-of-Order:				 No
    Profiling :					 Yes
  Queue on Device properties:				 
    Out-of-Order:				 Yes
    Profiling :					 Yes
  Platform ID:					 00007FFFE9176FD0
  Name:						 gfx900
  Vendor:					 Advanced Micro Devices, Inc.
  Device OpenCL C version:			 OpenCL C 2.0 
  Driver version:				 2766.5 (PAL,HSAIL)
  Profile:					 FULL_PROFILE
  Version:					 OpenCL 2.0 AMD-APP (2766.5)
  Extensions:					 cl_khr_fp64 cl_amd_fp64 cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_3d_image_writes cl_khr_byte_addressable_store cl_khr_fp16 cl_khr_gl_sharing cl_khr_gl_depth_images cl_amd_device_attribute_query cl_amd_vec3 cl_amd_printf cl_amd_media_ops cl_amd_media_ops2 cl_amd_popcnt cl_khr_d3d10_sharing cl_khr_d3d11_sharing cl_khr_dx9_media_sharing cl_khr_image2d_from_buffer cl_khr_spir cl_khr_subgroups cl_khr_gl_event cl_khr_depth_images cl_khr_mipmap_image cl_khr_mipmap_image_writes cl_amd_liquid_flash cl_amd_planar_yuv


‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

[dipak]

Thank you for providing the above useful information and sharing the clinfo output.

I've already reported it to the concerned team. Once I've any update, I'll get back to you.

[rosenrodt]

dipak‌ Any update? It's been a while now. Can you confirm that it's reproducible on your side?

[dipak]

Hi rosenrodt‌,

I already opened a ticket against the issue. As per our issue tracking system, currently the ticket is under investigation. I'll try to get an update about it and share with you.

By the way, did you try the latest Adrenalin 19.3.1? If you see any different observation, please let us know.

Thanks.

[rosenrodt]

Thanks for the tip. I'll try the new driver sometime next week and see if

there's any difference

dipak <amd-external@jiveon.com>於 2019年3月8日 週五，下午3:28寫道：

Community <https://community.amd.com/?et=watches.email.thread>

Re: OpenCL driver bug in OpenCL

[rosenrodt]

Nope. Tried Adrenalin 19.3.2 and this issue still persists. 

[dipak]

Thank you for the confirmation. 

By the way, I asked the team for an update but haven't got any reply still now. Once I've any update, I'll get back to you. Thank you for your patience. 

Thanks.

[rosenrodt · Accepted solution]

I tried again today with Adrenalin 19.3.2 and this issue seems to be

solved. Running Boost.Compute's test suite that include similar kernel like

this has passed as well. Thanks @dipak

dipak <amd-external@jiveon.com>於 2019年3月18日 週一，下午7:37寫道：

Community <https://community.amd.com/?et=watches.email.thread>

Re: OpenCL driver bug in OpenCL

[dipak]

It's good to hear that the issue has been resolved. Thank you for the confirmation.

Thanks.