feature request: OWL_BUFFER_GROUP and OWL_TEXTURE_GROUP about owl HOT 6 CLOSED

Agree that would be useful, but would argue that's not a "group" - at least right now, "groups" are very explicitly groups of things that can eb traversed/intersected with a ray, with a one-to-one mapping of a group to a optixtraversable.... and for textures or buffers that doesn't make sense.

the way that worked in optix 6 (and which is probably the easeiset/best route to reach that) is that there was a device-side registry of buffers, textures, etc, then the program would create buffers of IDs, and some device-side magic would resolve a buffer-id or texture-id back to the actual buffer/texture object (using said registery). Alternatively, the way this is handled in ospray (where 'buffers' are 'data objects') is that the API transparently replaced/remaps those things, but that has its own issues.

Buffers of IDs (with a means of looking up on the device) is how it was done in optix 6, so I'd argue that's how we should do it in OWL, too. Every buffer/texture/group etc already has a unique ID on the backend (in fact, even the registry at some point already existed), so that's the easiest way to do it.

from owl.

Names can change. “Group” was the first thing I thought of, but I’m open to alternatives too. “List” was another, or perhaps “Set”.

I personally prefer having raw pointers GPU side, although a device side API would be handy. Raw pointers are much more flexible than GLSL’s opaque handles, so we wouldn’t want to give that up too much.

I worry somewhat that designing a device side API might be outside of the scope of this feature request, and might make this feature more complicated than it needs to be to implement. I was just thinking of an extension to what OWLBuffer’s do right now, where per-device pointers would be directly exposed to the user.

from owl.

Yes, but for buffers it's different than for objects. For objcets - such a geometries, raygens, etc, the mapping is from "set of variables" to "raw data in the SBT", and it's already clear that this is a pretty heavy-weight operation that involved translations, lookups, data copying, etc .... and it's also usually "relatively" few. For buffers, you'd usually expect some relatively low-overhead operation (such as copying an array of floats), and also often a lot of items - but if the entries of a "group buffer" are different on the host than on the device, and even different on every device, then for such data types the buffer creation/update would suddenly involve way more work and time (let alone code to make it happen). The beauty of allowing only buffers of object _ID_s is that those IDs are once again plain ints, and all the translation happens on the device, where it can be done very elegantly with just a bit of template magic. Not saying it's not useful - just saying it's way more complicated, with way more caveats, than it initially sounds.

from owl.

Well, for one thing, I personally would really only like to use these buffer sets in the launch params. The data I have in lists represents an entire scene, and not a specific object. It’s possible there might be some future use case where owlGeomSetBufferSet would be useful, but I’m just imagining a owlLaunchParamsSetBufferSet for now. As a result, you wouldn’t have to worry about anything related to the SBT. I see where you’re coming from though from the perspective of entries in the SBT getting tricky with geometry...

Second, yes, I was thinking buffers of object IDs as well, since that would simplify backend stuff. I’d also explicitly disable creating sets of sets through the API to simplify the problem a bit.

I’m personally not sure how to design that a template strategy you’re suggesting which would do the translation from ID to pointer on device side, but if you have ideas I’d be down. Host side I’d just iterate first through all devices, and within I’d iterate through the OWL handles in the OWLBufferSet, creating a cuda buffer under the hood for each device which contains the pointers for each owl handle for the given device.

from owl.

features supported in latest devel by allowing owlDeviceBufferCreate(...,OWL_TEXTURE,OWLTexture*) and owlDeviceBufferCreate(....,OWL_BUFFER,OWLBuffer*)

from owl.

avaiable in v0.9.0, where buffers can be built over buffer or texture types.

from owl.