user events, CLEventList

I noticed the forums are a bit quiet for a good few months, has Michael B moved on?

I have a problem regarding user events - although you can create them, wait on them and use them as an individual condition to another queued command, you cannot add them to an existing event list the way you can accumulate events for conditions as with the enqueue commands.

i.e. i want something like the internal CLEventList.createEvent() but to add a user event to the list.  Actually just a simple CLEventList.addEvent(CLEvent) which works more or less the same would do.

I can't just copy the populated event list and create another one with the new event added, as the event list is being populated via multiple calls from the level above, being passed by reference.

I want to be able to create a call graph, and have asynchronous java code participate in the sequencing transparently.

I suppose i'll have to write another patch ...

On 03/09/2012 03:17 AM, notzed [via jogamp] wrote:
>
>
> I noticed the forums are a bit quiet for a good few months, has Michael B
> moved on?
>
Sort of.
Your use case sounds reasonable I guess.

Sorry, my OpenCL knowledge is still not good enough to give you an answer
here in the way 'this can't work because ..' - or, 'this is great and matches
the architecture.'. I just helped out with the native bindings and
general knowledge a bit.

I am afraid I will tell you the same things here as I did
in our JOAL conversation (patching / unit tests / maintenance),
if you get the idea :)

Since we try to get in some mobile OpenCL 1.1 device for our BOF this year,
I probably have to make a crash course into the current code base.
In May I will have the privileged of 3 weeks 'off',
which means I will have time for this endeavor.
I like to validate whether the current JOCL can be matched to
the OpenCL C++ Wrapper API, if this is not done yet .. etc.

Since you are at least interested, I welcome your support of course.

However, whoever likes to help and support (any project on jogamp)
would need to get familiar w/ the toolchain we use (git, ant, ..).
Otherwise the real maintenance work would become unbearable.

But discussions and knowledge exchange are very valuable contributions
as well, which don't require those things :)

Well, let's see how it goes.

~Sven

  hi michael (notzed),

i am still subscribed to this list and i am using jocl basically
fulltime. However i am either working on frameworks on top of jocl
(distributed computing and similar stuff) or writing kernels but use
only a small fraction of the CL 1.2 api. So your feedback is always
appreciated :)

lets take a look at CLEvents.
I remember i had a reason why i didn't add that.. but don't know what it
was. I will just go ahead and add a few utility methods (add(CLEvent)
and add(CLEventList)) and see how it works or where the problem was.

what was your other usecase regarding events again?

best regards,
michael (mbien)

On 03/09/2012 03:17 AM, notzed [via jogamp] wrote:

On 03/09/2012 06:48 PM, Michael Bien [via jogamp] wrote: Hi Micheal[s] and all [JOCL] interested parties.

First of all, good to hear from you Michael [Bien].

The JogAmp branch of JOCL currently differs from Michael Bien's branch
due to some differences in the past, which shall be of no concern.

In my role as the JogAmp lead, I have to try to 'solve' the maintenance
problem in regards to JOCL, incl. merges, unit test and device support.

Putting personal differences aside, the goal is to have 'once again'
a well maintained JogAmp JOCL module playing well along with all
other modules - a one stop shop for processing .. etc.

The ideal solution would be if Michael Bien picks up the job [again]
and prepares a pull request. In detail required changes are:

  - Realign the copyright notice of files (Personal -> JogAmp Community),
    which was agreed upon.

  - Realign to JogAmp's GlueGen. I already did this task while merging
    his tree, until the (c) change appeared.

  - Continuing at least in an upstream/downstream maintenance model,
    where original experimental changes may happen in MB's JOCL
    but we always commit to merge both branches - and communicate.

  - Respecting the process & roles

If the above is not possible for whatever reasons, we need to find a solution
for JOCL. As mentioned before, this might be done by interested
and skilled parties together.

Fortunately there seems some resolution on the horizon
which includes master students and some industry interest and sponsoring.

If having such wider support and maybe even Michael Bien's cooperation
we could reach the goal of platform agnostic OpenAL, OpenGL, OpenCL, etc
across platforms and devices in harmony - once again.

Well, however this is done - we will get it done :)

Cheers, Sven

Hi Michael,

Michael Bien wrote

hi michael (notzed),

i am still subscribed to this list and i am using jocl basically
fulltime. However i am either working on frameworks on top of jocl
(distributed computing and similar stuff) or writing kernels but use
only a small fraction of the CL 1.2 api. So your feedback is always
appreciated :)

Ok thanks for the background.  Yes I am barely touching the 1.1 stuff, and this was one case of it.

lets take a look at CLEvents.
I remember i had a reason why i didn't add that.. but don't know what it
was. I will just go ahead and add a few utility methods (add(CLEvent)
and add(CLEventList)) and see how it works or where the problem was.

what was your other usecase regarding events again?

Basically I want to pass (CLEventList condition, CLEventList event) as arguments to a function, and have that function participate in the global CL event scheduling as if it were any other enqueue() call: including the case where that function is just (e.g. multi-threaded) Java code.  This seems to be what user events are for.

The only reason I could imagine not to expose it in that way would be to hide the reference counting issues (e.g. passing ownership or not).

Cheers,
 Michael

On 03/11/2012 08:19 AM, notzed [via jogamp] wrote:

Hi Michael,

Michael Bien wrote

hi michael (notzed),

i am still subscribed to this list and i am using jocl basically
fulltime. However i am either working on frameworks on top of jocl
(distributed computing and similar stuff) or writing kernels but use
only a small fraction of the CL 1.2 api. So your feedback is always
appreciated :)

Ok thanks for the background.  Yes I am barely touching the 1.1 stuff, and this was one case of it.

lets take a look at CLEvents.
I remember i had a reason why i didn't add that.. but don't know what it
was. I will just go ahead and add a few utility methods (add(CLEvent)
and add(CLEventList)) and see how it works or where the problem was.

what was your other usecase regarding events again?

Basically I want to pass (CLEventList condition, CLEventList event) as arguments to a function, and have that function participate in the global CL event scheduling as if it were any other enqueue() call: including the case where that function is just (e.g. multi-threaded) Java code.  This seems to be what user events are for.

The only reason I could imagine not to expose it in that way would be to hide the reference counting issues (e.g. passing ownership or not).

yep makes sense. You could return a new list as workaround but thats uncool from resource management perspective.

https://github.com/mbien/jocl/commit/e6e10d8addd887c629b73585a8b6e510d75d67d5

i noticed as i wrote that that the list basically works now like a stack. I will take a look the next time i work on jocl if i can implement a single-ended queue interface of the collection api and add the missing pop/pull methods.

Cheers,
 Michael

best regards,
michael

-- 
- - - -
http://michael-bien.com