Quantcast

user events, CLEventList

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

user events, CLEventList

notzed
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 ...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: user events, CLEventList

Sven Gothel
Administrator
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.

> 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 ...
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


signature.asc (910 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: user events, CLEventList

Michael Bien
In reply to this post by notzed
  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:

> 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 ...
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: user events, CLEventList

Sven Gothel
Administrator
On 03/09/2012 06:48 PM, Michael Bien [via jogamp] 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 :)
>
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


signature.asc (910 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: user events, CLEventList

notzed
In reply to this post by Michael Bien
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: user events, CLEventList

Michael Bien
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
Loading...