OpenCL bug _ implementation not defined

[Evan407]

cl_int
clGetDeviceIDs (cl_platform_id platform,
cl_device_type device_type,
cl_uint num_entries,
cl_device_id *devices,
cl_uint *num_devices)

If platform is NULL, the behavior is implementation-defined.

https://www.khronos.org/registry/OpenCL/sdk/1.0/docs/man/xhtml/clGetDeviceIDs.html

platform
Refers to the platform ID returned by clGetPlatformIDs or can be NULL. If platform is NULL, the behavior is implementation-defined.

It is supposed to be able to take null but the issue is there could be more than one platform!

[Kai]

That's why you are supposed to provide the platform ID to that method, and not null.
As the spec says very clearly: **If platform is NULL, the behaviour is implementation-defined.**
It is _not_ defined by the standard what happens, but up to the implementation (such as choosing one platform as the "default" platform).
Obviously, you would NEVER rely on implementation-defined behaviour which might just happen to work on your computer.

[Evan407]

That's why you are supposed to provide the platform ID to that method, and not null.
As the spec says very clearly: **If platform is NULL, the behaviour is implementation-defined.**
It is _not_ defined by the standard what happens, but up to the implementation (such as choosing one platform as the "default" platform).
Obviously, you would NEVER rely on implementation-defined behaviour which might just happen to work on your computer.

What I've found is that it's important to retrieve a device
org/lwjgl/opencl/CL10.html#clCreateCommandQueue-long-long-long-java.nio.IntBuffer-

Having multiple command-queues allows applications to queue multiple independent commands without requiring synchronization.

public static int clEnqueueBarrier(long command_queue)

Enqueues a barrier operation. The clEnqueueBarrier command ensures that all queued commands in command_queue have finished execution before the next batch of commands can begin execution.

There is no point in partitioning a device when you can have multiple command-queues, kernels, barriers, and the entire context for each platform.

[Kai]

Any issues you might have with OpenCL itself are probably better addressed here:
https://forums.khronos.org/forumdisplay.php/87-OpenCL-parallel-programming-of-heterogeneous-systems

[Evan407]

Any issues you might have with OpenCL itself are probably better addressed here:
https://forums.khronos.org/forumdisplay.php/87-OpenCL-parallel-programming-of-heterogeneous-systems

Why can't I group all the devices in one context? They are still separated by platform.

[spasi]

Why can't I group all the devices in one context? They are still separated by platform.

You can use multiple platforms at the same time, but you cannot do anything across platforms. Each platform is independent and may have access to different devices. A context can be created with multiple devices, only if they belong to the same platform.

With that said, it's becoming obvious (from this and other recent threads) that you're trying to deal with advanced functionality without having experience of OpenCL and LWJGL basics. I would highly recommend that you first get familiar with simple OpenCL functionality (it's simple, but not easy) and the way LWJGL bindings work (easy, but needs practice), before trying to do anything more complicated. LWJGL is a low-level binding library and does not try to be friendly to novice users.

[Evan407]

Why can't I group all the devices in one context? They are still separated by platform.

You can use multiple platforms at the same time, but you cannot do anything across platforms. Each platform is independent and may have access to different devices. A context can be created with multiple devices, only if they belong to the same platform.

With that said, it's becoming obvious (from this and other recent threads) that you're trying to deal with advanced functionality without having experience of OpenCL and LWJGL basics. I would highly recommend that you first get familiar with simple OpenCL functionality (it's simple, but not easy) and the way LWJGL bindings work (easy, but needs practice), before trying to do anything more complicated. LWJGL is a low-level binding library and does not try to be friendly to novice users.

I do have a lot of experience with lwjgl and java. I don't know why you are replying this it is false and demonstrates you do not actually know how to fix the problem or what the problem is.