Is it possible to check if a CLBuffer is still valid?

Is it possible to check if a CLBuffer is still valid? E.g. is there a better way than just trying to write something to it and see if it gives an error?

  On 06/17/2011 04:36 PM, barno [via jogamp] wrote:
> Is it possible to check if a CLBuffer is still valid? E.g. is there a better
> way than just trying to write something to it and see if it gives an error?
>
valid? You mean it has not been released yet or did you have something
else in mind?

-michael

besides it already being released I could also imagine situations where the device is not longer available or similar things.

On 06/17/2011 04:56 PM, barno [via jogamp] wrote:
> besides it already being released I could also imagine situations where the
> device is not longer available or similar things.
>
ok, lets try to tackle this.

1.) releasing resources

isReleased() isn't yet here mainly because of my laziness :)

CL uses manual reference counting. If you create a CL object refcount
will be 1. You can increment the refcount by calling clRetainFooBar().
If refcount == 0 the driver will delete the object.

Why is it this way? Systems use this to prevent situations when app 1
and app 2 sharing the same resource but do not know from each other. App
2 should be able to release the resource without killing app1 etc..

if you release a deleted object you will get a segfault since object IDs
are pointers (spec sais it should return an error flag but no driver
does this)

To play the sandbox/refcounting game i suggest to not expose retain() in
the high level api but add an isReleased().
  - calling release() will call clReleaseFooBar(ID)
  - releasing resources more than once will throw a
RuntimeException("already released")
  - if release has been called isReleased() will return true ignoring
the actual refcount

(we can think about adding retain() later if someone has convincing
arguments to expose it in the high level api)

would this be ok?


2.) available or not...
buffers should be always available. CL mem objects are very abstract.
They are not allocated on a particular device, they are just allocated
(where is a implementation detail -  it wouldn't surprise me if they are
allocated/moved when needed on a device). Devices can be unavailable
(see device.isAvailable()), however i haven't seen a unavailable device
yet :)

regards,
michael

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

Sounds like you're just trying to find out when your context 'crashed'?

Michael,

your suggested solution sounds fine, although it would not work under all conditions if I understand correctly. The situation mentioned by notzed seems to be one of those, doesn't it?

Thanks,
barno

In that case, what do you expect to be able to do though?  A crash indicates a problem with your code (or a driver problem you can't do much about).

Recovering from that would be pretty difficult - every object from the context I presume would have to be recreated.  And it wont fix the code crash in any event.

Hi Michael,

do you already have an idea if (or when?) you are going to implement the isReleased feature?

  On 08/05/2011 05:07 PM, barno [via jogamp] wrote:
> Hi Michael,
>
> do you already have an idea if (or when?) you are going to implement the
> isReleased feature?
>
its already implemented for all CLResources beside other improvements*.

a few Java 7 builds:
https://github.com/mbien/jocl/downloads


* http://michael-bien.com/mbien/entry/many_little_improvements_made_it

regards,
michael

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

wow!

Is there a reason why there is no Windows AMD64 build? Could you perhaps provide one?

  On 08/08/2011 03:47 PM, barno [via jogamp] wrote:
> Is there a reason why there is no Windows AMD64 build?
>
laziness :)


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

would it be a lot of work or could you quickly create one?

  On 08/08/2011 04:18 PM, barno [via jogamp] wrote:
> would it be a lot of work or could you quickly create one?
sorry not now since I am not on my workstation with the windows
virtualbox image (maybe this evening). You could run it with a 32bit jvm
if thats possible.

-michael

I can't run it under 32bit as I need more than 4GB of RAM. Please let me know once there is a 64bit build for Windows. Thanks.

I'm sorry I have to bother you again. Can you perhaps give an estimate when you will have time to create the AMD64 Windows build? I might have to switch back to the old version for now, but I would like to avoid that if it will be available soon.

  On 08/10/2011 11:01 AM, barno [via jogamp] wrote:
> I'm sorry I have to bother you again. Can you perhaps give an estimate when
> you will have time to create the AMD64 Windows build? I might have to switch
> back to the old version for now, but I would like to avoid that if it will
> be available soon.
>
https://github.com/mbien/jocl/downloads
uploaded

-michael

awesome, thanks!