Reply – Re: Is it possible to check if a CLBuffer is still valid?
Your Name
or Cancel
In Reply To
Re: Is it possible to check if a CLBuffer is still valid?
— by Michael Bien Michael Bien

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 :)