Unique device/implementation name

Is there a better way than :
devicesInfos.vendorID + deviceInfos.name + platformInfos.version
to find and unique identifier for a device on an implementation?

This permit to find a file name for each potentially different binary produced by opencl compilers.

Hash the string “devicesInfos.vendorID + deviceInfos.name + platformInfos.version” with MD5 or SHA1, and use the hash for the filename.

I went nuts and used everything I could find:


static std::string GetUniqueDeviceName(const cl::Device &device)
{
  std::string uname;
  uname += DeviceTypeToString(device.getInfo<CL_DEVICE_TYPE>());
  uname += device.getInfo<CL_DEVICE_VENDOR>();
  uname += NumberToString(device.getInfo<CL_DEVICE_VENDOR_ID>());
  uname += device.getInfo<CL_DEVICE_NAME>();
  uname += device.getInfo<CL_DEVICE_VERSION>();
  uname += device.getInfo<CL_DEVICE_PROFILE>();
  uname += device.getInfo<CL_DEVICE_EXTENSIONS>();

  return uname;
}

It sure would be nice if the spec said what the minimal set was to associate with binaries.

Based on another thread though there may not be anything possible at this point:

[quote=“dbs2”]

Good luck! This is really hard to get right with the current API. E.g., on a Mac, if you compile on an SSE4.2 machine your saved kernel binary will crash on an SSE4.1 or SSSE3 machine with invalid instructions. This is unfortunately not a very well thought-out part of the design.[/quote]

viewtopic.php?f=28&t=2617

Hash is a good idea for file name (because some returned string are not valid file name :slight_smile: ).

SSE3 and SSE4 machine should not have same device, so two differents ID?

Are you talking about a CPU OpenCL implementation ??
If you have a CPU OpenCL (like AMD) then, I don’t know if AMD expose in the “system infos” the fact that you are on a machine with SSE[3|4], that strings are implementation dependant.

A hash generated for the string CL_DEVICE_VENDOR_ID + CL_DEVICE_NAME should be sufficient to identify a unique device identifier. You may want to include CL_DRIVER_VERSION as well.

WRT following comment “Good luck! This is really hard to get right with the current API. E.g., on a Mac, if you compile on an SSE4.2 machine your saved kernel binary will crash on an SSE4.1 or SSSE3 machine with invalid instructions. This is unfortunately not a very well thought-out part of the design.” this looks like a bug with the Mac OS X OpenCL implementation. A SSE4.1 device should either have a different vendor ID or different device name vs. a SSSE3 device. Please file an appropriate bug with your ADC account against Mac OS X OpenCL.