OpenCL bug _ implementation not defined

Started by Evan407, May 27, 2017, 19:07:54

Previous topic - Next topic

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)

QuoteIf platform is NULL, the behavior is implementation-defined.
https://www.khronos.org/registry/OpenCL/sdk/1.0/docs/man/xhtml/clGetDeviceIDs.html
Quoteplatform
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

Quote from: Kai on May 27, 2017, 19:20:51
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-
QuoteHaving multiple command-queues allows applications to queue multiple independent commands without requiring synchronization.
Quote
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.


Evan407

Quote from: Kai on May 27, 2017, 21:39:25
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

Quote from: Evan407 on May 27, 2017, 23:46:03Why 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

Quote from: spasi on May 28, 2017, 09:16:50
Quote from: Evan407 on May 27, 2017, 23:46:03Why 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.