clCreateContextFromType properties parameter can not be NULL

The final NVidia release requires that the properties parameter of clCreateContextFromType can not be NULL (and this is perfectly kosher by the standard). http://developer.download.nvidia.com/co … es_3.0.txt

However, I can’t find an example of how to use clCreateContextFromType where this parameter is not NULL. NVidia’s entire arsenal of example code doesn’t use it even once. Does someone know how to use this parameter?

Thanks,
Brian

I stumbled across that today as well…

You can use clGetPlatformIDs() to query all platforms installed on the machine. You can then pass the platform you want to use to clCreateContextFromDevice() in the cl_context_properties parameter (the first parameter).
It’s a bit awkward as you have to pass a list of pairs of to the function (see spec section 4.3). Here’s an example code:


cl_context_properties props[3];
props[0] = (cl_context_properties)CL_CONTEXT_PLATFORM;  // indicates that next element is platform
props[1] = (cl_context_properties)platform;  // platform is of type cl_platform_id
props[2] = (cl_context_properties)0;   // last element must be 0
cl_context context = clCreateContextFromType(props, CL_DEVICE_TYPE_GPU, NULL, NULL, NULL);

Ick, that is ugly. Kind of makes the appeal of the clCreateContextFromType vanish if the platforms have to always be specified. I’m partly speaking from a C++ bindings user point of view, where I am used to writing unit test driver programs using the following boiler plate:


cl::Context context(CL_DEVICE_TYPE_ALL); 
std::vector<cl::Device> devices = context.getInfo<CL_CONTEXT_DEVICES>();
cl::CommandQueue queue(context, devices[0]);

Now my path of least resistance for unit test driver programs is something like the following:


std::vector<cl::Platform> platforms;
cl::Platform::get(&platforms);

std::vector<cl::Device> devices
platforms.front().getDevices(CL_DEVICE_TYPE_ALL, &devices);

cl::Context context(devices); 
cl::CommandQueue queue(context, devices[0]);

Twice as many lines of code, but nobody said OpenCL was going to be easy. Though it is clear why PyOpenCL has a create_some_context function. It is not entirely clear from the AMD article (http://developer.amd.com/support/Knowle … aspx?ID=71) why NULL can’t be used to indicate, “give me all the devices from all the platforms”.

Are there good technical reasons to allow implementations to prohibit a context that actually spans two platforms/vendors? Why can’t the ICD handle the abstraction of the different platforms when I specify NULL to clCreateContextFromType?

The specification is clear on theese points :

  • context can’t be shared between platform
  • if you don’t pass platform property at context creation, paltorm selection is implementation dependent.

So I think nVidia behavior is a bug.

This is described in the ICD extension document, so this is not a bug.

3: How will the ICD handle a NULL cl_platform_id?

RESOLVED: The NULL platform is not supported by the ICD.

Ok, this ICD spec part was not clear for me, so I’m just sad about this fact :frowning: as coleb.

To my understanding, the decision is because there is no fair way to choose from multiple platforms available on a computer. For example, supposed that you have one NVIDIA video card and one AMD video card, both installed on the same machine, which should be the “default” platform? That may bring a lot of problems. If the “default” platform is determined by some obscure way, it could start a “bidding war” in which vendors are trying to make their platforms to be more default than others :slight_smile:

Some may argue that this is a rare case. Most people probably are going to have only one video card, so they should only have one platform installed. However, OpenCL is not just about video cards. It’s also about CPU, CELL, etc. Also, if it allows NULL platform id on systems with only one platform, but fails on systems with multiple platforms, people will get lazy and you’ll see a lot of OpenCL applications which don’t work on systems with multiple platforms, and that’d be very bad. So, a well behaved application should always let its user to choose from all platforms available on the system.

The unfortunate thing is that the clCreateContextFromType function seems to be retrofitted to conform to this by making users pass the cl_platform_id into the properties argument. Why not just make cl_platform_id a required argument to clCreateContextFromType in the next release of the standard?

This annoyance along with the fact that NVidia’s implementation is unhappy with multiple hosts threads accessing the same context (even though the way I read the standard this should be safe) is pushing me towards writing OpenCL host code that never makes use of multi-device contexts. Basically, single thread-device-context appears to be the most stable way forward. Though it introduces other inefficiencies (it’s harder to reuse kernel compilation). Furthermore, even though fermi will support concurrent kernel execution, the rumor is that it won’t support concurrent contexts on the device.

Real software shouldn’t let the user choose this sort of thing. Users hate being presented with choices like this, they always want it to “just work”. Though I recognize the proper programmatic way forward is not have one vendor be defaulter than others. So what we need is some standard recipes about choosing devices for developers to follow when developing applications.

No. Real applications should give the users the ability to choose, but also provide a sensible default setting. Apparently, let the ICD to choose from a platform when platform_id is NULL is not going to be a sensible default setting (for example, you may want to use all GPU available on the system).