This issue proposes a new API for injecting array data into objects: anariMapParameterArray[1/2/3]D() and anariUnmapParameterArray().
The idea is to allow a map/unmap operation on an array directly on an object parameter -- doing so without an independent handle. For example, injecting vertex position data on a triangle geometry would look like:
ANARIGeometry geom = anariNewGeometry(device, "triangle");
float3 *vertices = anariMapParameterArray1D(device, geom, "vertex.position", ANARI_FLOAT32_VEC3, numVertices);
// if the array doesn't exist because an extension isn't implemented, such as
// ANARI_KHR_GEOMETRY_TRIANGLE, it may return NULL
if (vertices) {
fillVertexData(vertices);
}
anariUnmapParameterArray(device, geom, "vertex.position");
// ...
The near-term motivation is that some rendering engines (Cycles, to be specific) are not flexible with their memory allocation model and rely on their own abstractions for managing memory. While ANARI has plenty of great memory abstractions with lots of flexibility, there currently isn't a "fast path" for apps to inject data straight into the lowest-level location in memory that an implementation will use. This means that even managed arrays can still result in internal copies taking place, based on the underlying implementation's design limitations.
Long term I still think this API has value, as it guarantees that the array on the object in question cannot exist anywhere else, meaning this API gives the best performance for arrays which are not shared between multiple objects. For example, VisRTX would use this to allow injecting straight into a CUDA texture for image samplers.
There are plenty of reasons to keep all our other handle based arrays, so this proposed purely as an addition.
Practically all of the examples in the SDK would end up being convertible to this form, as we basically have no examples where a single array gets used in more than one place, nor needs to be memory shared with the application. Those use cases certainly exist and should be demonstrated, but I think direct array mapping is actually the default use case -- not the exception.
This issue proposes a new API for injecting array data into objects:
anariMapParameterArray[1/2/3]D()andanariUnmapParameterArray().The idea is to allow a map/unmap operation on an array directly on an object parameter -- doing so without an independent handle. For example, injecting vertex position data on a triangle geometry would look like:
The near-term motivation is that some rendering engines (Cycles, to be specific) are not flexible with their memory allocation model and rely on their own abstractions for managing memory. While ANARI has plenty of great memory abstractions with lots of flexibility, there currently isn't a "fast path" for apps to inject data straight into the lowest-level location in memory that an implementation will use. This means that even managed arrays can still result in internal copies taking place, based on the underlying implementation's design limitations.
Long term I still think this API has value, as it guarantees that the array on the object in question cannot exist anywhere else, meaning this API gives the best performance for arrays which are not shared between multiple objects. For example, VisRTX would use this to allow injecting straight into a CUDA texture for image samplers.
There are plenty of reasons to keep all our other handle based arrays, so this proposed purely as an addition.
Practically all of the examples in the SDK would end up being convertible to this form, as we basically have no examples where a single array gets used in more than one place, nor needs to be memory shared with the application. Those use cases certainly exist and should be demonstrated, but I think direct array mapping is actually the default use case -- not the exception.