5-sec watchdog timer limit OpenCL

Few serious questions.

  1. Does a OpenCL kernel have 5-sec watchdog limitation?

  2. If Windows cannot load 2 drivers at the same time, How can I compute on both AMD and NVIDIA cards together?
    Is OpenCL affected by these issues?

  3. With respect to question 2 – what is the bhaviour of Linux?

Thanks,

q2 and q3:

using linux: you have to load the nvidia and amd opencl.so manually by writing a dl handler function to bind the opencl calls to amd and nvidia apis calls (cz. they are the same and cannot be initialized automatically. i assume this was your reason for this post).

i have not read anything about this issue in the OpenCL reference. maybe the reason is, that this is system specific and cannot be solved easily “with a standard interface” because you have know much more about the system. E.g. where the different .dll’s are stored and how they are named. but you can start to write such a wrapper library :)

@NVIDIA: is it possible that you rename your libOpenCL.so.x.x to libOpenCL_nvidia.so.x.x and create a symlink to libOpenCL.so? this makes it possible to install opencl libs from different manufactures on linux systems.

You hit it right. Thats exactly what I was looking for (True heterogenous computation on a single machine).

I stil dont understand the binding part that you are mentioning. When I query OpenCL for devices, Will I get AMD devices as well?

I assume this will be possible only if I install AMD’s openCL Runtime as well. So, if that is the case, how do these two run-time co-exist…

Its all confusing.

I dont think there is a need for a wraper. Or at least there should not be.

OpenCL must provide a layer where NVIDIA and AMD (and others) can place their modules. I am sure it must be there. If you have any info, Kindly share.

Thanks for posting!

no, you just get the nvidia cards as long as there’s no cooperation between AMD and nVidia :ph34r: . I’m quite sure that there’s no way to unify those drivers to the official API cz. they can return e.g. the same device ID making it necessary to unify also the internal device handling (or enumeration) structures, etc… the same problem occurs using memory objects and other handlers.

it’s like using 2 different graphic cards with opengl in a computer. this thing can also be done by loading the different libGL.so of nvida or ati (i always talk about linux systems)…

hm… i have an idea how to solve this problem: maybe you create 2 threads with a piece of shared memory. each thread loads the cpu or gpu libOpenCL.so and shares the data by shm.

I can figure your passion from your name “initram”. I think it is a linux internal data structure (initram_t), no? Vaguely remember so.

I used to work with linux long back. But now I am a big MS fan.

ok,

Coming to point,

The aim of OpenCL is to favour heterogeneous programming apart from portablity. If you read the OpenCL spec, you will understand this.

OpenCL spec says it has 3 layers.

  1. Platform Layer - Helps discovery of devices, context creation

  2. Runtime layer - to manipulate the context

  3. Compiler - to compile OpenCL programs

The platform layer should be able to talk to various run-times to make true heterogeneous computing possible.

The platform layer should be vendor independent and one can either use it from NVIDIA or AMD. Its all going to do the same.

The runtime and compiler should be specific to the device (nvidia or amd).

However the API calls listed in the spec are for all types of devices.

The spec fails to say how platform layer will work with various runtime and compiler layer.

For example: consider this API call

clCreateCommandQueue(cl_context, cl_device_id, cl_command_queue_properties, cl_int *);

Now, this call will be implemented by both NVIDIA and AMD’s runtime. So, an application can be linked only with one of them. Grrrr…

That spoils the whole objective of heterogeneous computation.

I think one needs to write a higher-level API to make true heterogenous computing happen. And, that can be a nightmarish and un-wanted task.

To conclude – if what I have mentioned above is true, then I can only conclude that OpenCL has failed to attain the heterogeneous computing objective.

just read my name backwards and you’ll know the meaning of life - (it’s not 42!!!) ;)

heterogenity also means to run programs on different architectures but not at the same time.

I google searched martini and found the meaning of life. Never tasted alcohol before :)

Doug.Adams did not know about CUDA. Otherwise, such a big computer was not necessary to find out 42. :-)

That is portability.

Well, see below what the OpenCL says :

sure, specially cz. i’m from bavaria (germany). there’s no life without beer :devil: !!!

okok, i’ve read the specific opencl spec. part again and what you wrote is exactly what they meant by heterogenity. but i think that’s not the general thought of heterogenity if we talk about software accessable heterogenous devices. this is just my experience and opinion. ok, back to the primary problem:

i coincide with you that the “OpenCL Platform layer” has to be developed as a separate lib but i dont think that there’s an easy way to do this. a statement of a nvidia member woule be useful :)

(btw. there are much more inconsistencies or unclear things in the specification)

yeah, I learnt that from some people who had been to Germany (strutgart or similar name)

Yup! It would be good to have some1 comment on this part.

Thanks a lot 4 ur time!

Best Regards,

Sarnath