AnsweredAssumed Answered

Device information issues

Question asked by gbilotta on Jun 7, 2013
Latest reply on Jun 14, 2013 by gbilotta

While writing and testing a clinfo program, I came across the following issues with the device information exposed by the AMD platform:

  • the reported MAX_CLOCK_FREQUENCY on Intel CPU devices is not the _maximum_ clock frequency, but the current one; for example, if my CPU is running at 800MHz but can go to 2.5GHz, 800MHz is reported; the issue seems to be limited to Intel CPUs, since for the Phenom in one of my systems the maximum frequency is correctly reported;
  • although the list of available extensions does not expose the cl_khr_fp16 extension, querying for the preferred and native half vector types gives a value of 2 on most of the CPUs and GPUs I have tried; this violates the standard, since when the extension is not supported, 0 should be reported; if the platforms does indeed support the half type, then the cl_khr_fp16 extension should be mentioned among the extensions supported by the device;
  • querying for the LINKER_AVAILABLE (OpenCL 1.2) property returns CL_FALSE. This violates the specification, since COMPILER_AVAILABLE is CL_TRUE, and in this case LINKER_AVAILABLE must also return CL_TRUE; additionally, FULL_PROFILE devices (and most f not all CPUs and GPUs supported by the AMD platforms have FULL_PROFILE) must also return CL_TRUE for LINKER_AVAILABLE;
  • on CPUs, the reported PRINTF_BUFFER_SIZE (OpenCL 1.2) is 65KB, while according to the standard the minimum value allowed for FULL_PROFILE devices is 1MB;
  • finally, where can I find some information about the GLOBAL_FREE_MEMORY_AMD property? From the cl.hpp I could derive that it's of type size_t[], and from my experimentation it seems to present two identical values which represent the amount of free global memory (in megabytes) for the GPU; would it be possible to have some documentation about this property, such as why are there two values? (I was also surprised to find it exports a size_t[] since I would have expected it to provide a cl_ulong[], for consistency with other memory-related properties)

 

For reference, my clinfo code can be found on http://github.com/Oblomov/clinfo/

Outcomes