RenderKit / ospray

An Open, Scalable, Portable, Ray Tracing Based Rendering Engine for High-Fidelity Visualization
http://ospray.org
Apache License 2.0
1k stars 182 forks source link

More control over reference counts #354

Closed paulmelis closed 5 years ago

paulmelis commented 5 years ago

Currently, incrementing a reference count cannot be done manually. The only user operation on a reference count is to decrease it with ospRelease. But when storing references to OSPObject's (in all their variations) outside of OSPRay's control this becomes quite limiting. For example, I'm storing a list of OSPInstance in a regular std::vector, which gets updated during program lifetime. At some point that vector gets passed to ospNewData to be used during rendering, but changes are happening to the list at other moments. As the data object might get released outside of my control I cannot guarantee those instance stay alive, other than by storing them in some sort of second "keep-alive" OSPData object. But when the list changes that object would need to be reconstructed every time, etc. My troubles would be much smaller if I could just have more control over the refcount to match the actual number of references kept.

So would it be possible to add an ospAddReference() call (or similar name)? And also a way to get the current reference count of an object, e.g. ospGetReferenceCount()?

johguenther commented 5 years ago

We already thought of adding the pendant to ospRelease: ospRetain(OSPRObject).

If you pass the vector of instances in an OSPData (and keep that around), then the instances should not get released. So it may also be a bug in OSPRay.

paulmelis commented 5 years ago

Ok, great. I actually haven't tried the extra-OSPData-trick at this point.

johguenther commented 5 years ago

I didn't mean the extra-ospData, but the original one; if that is alive, the instances should be as well (if not, this is a bug).

paulmelis commented 5 years ago

Ah, misunderstood. I'm indeed keeping it alive for now as a workaround. But it's not optimal, as that data doesn't contain the up-to-date list of instances, only the ones currently being used for rendering, while there are more that are cached until being used again in future.

johguenther commented 5 years ago

So you create many Instances, but only a subset of them is used for rendering at a given time? And you did not call ospRelease on any Instance (currently used or not)? When you put some of those instances in a ospData, their refcount should increase, and be decreased again when that ospData is released. But then the refcount is still >=1 and the Instances should not get released.

paulmelis commented 5 years ago

Ok, I checked my code and was indeed inadvertently releasing the initial references in a few places, causing unexpected deleted objects later on

johguenther commented 5 years ago

So, can we close this issue? We track the ospRelease() feature-request independently.

paulmelis commented 5 years ago

Great! Yes, I'll close it