One device, many contexts

Is it the intent of the OpenCL specification to allow a device to be part of more than one context, or should a device that is already part of an existing context be marked as “unavailable” and cause “clCreateContext()” to fail when an application asks for it to be included in a new context as well?

Also, if OpenCL should not fail “clCreateContext()” when one or more of the listed devices are already part of context(s), then what about “clCreateContextWithType()” when there are no other available devices of the selected type?

Is it the intent of the OpenCL specification to allow a device to be part of more than one context

Yes, this is intentional. I’ll give an example of why this is useful: let’s say that you write an application that uses OpenCL to perform some computation. Let’s also say that your application is linked against a library that also uses OpenCL to accelerate some operations. Isn’t it nice that the library and the main application can both use OpenCL simultaneously? They don’t need to worry whether the other party is already using certain device; in fact, they don’t even need to know that the other is using OpenCL at all!

Also, if OpenCL should not fail “clCreateContext()” when one or more of the listed devices are already part of context(s), then what about “clCreateContextWithType()” when there are no other available devices of the selected type?

No difference. The OpenCL driver makes sure that multiple contexts, even multiple processes, can use the same device “simultaneously”.

Thank you, this was very informative.

I can now see why using the same device with multiple contexts is important.

I think that using the same device with multiple processes “simultaneously” is dangerous for security, unless of course the device is a CPU. Multiple threads of the same process - certainly, but not multiple processes of possibly different users. GPUs have no memory-protection, so it would be open to abuse such as spying on other users, or even modifying their data. Of course, a driver could transparently back up and restore the whole GPU memory when used by different processes, but that can be unreasonably expensive.

You will find that modern GPUs have MMUs (shameless plug).

Useless trivia: I think the first GPU with an MMU was the 3dlabs P10 back in 2002.

Very interesting.

I just wondered, since GPUs with MMUs are starting to appear, one important feature that goes with it is the ability to preempt a kernel: what if two users use the same GPU and one’s kernel takes very long - suppose it already ran for an hour, or suppose it has a bug causing an infinite loop, it is important for the operating-system to be able to stop that kernel and resume it later, allowing the second user to proceed.

Any such plans?