Performance considerations about anari-docs HOT 2 CLOSED

Thanks for your feedback and starting a discussion!

An alternative to the trampoline for applications that want to avoid it is to use static linking to a specific ANARI implementation.

We considered alternatives to strings for parameter passing, but so far want to keep them, for convenience.

I don't see both performance aspects as critical. Please keep in mind that ANARI is intended as a high-level API, we expect only a fraction of API calls compared to a low-level API like Vulkan.

While your CAD example (100M single-triangle objects) will work, it is not the recommended usage of ANARI. Instead, the CAD application should create a single (or a small number of) geometry objects containing the 100M triangles (potentially as triangle soup without index). The vertex data can (and probably should) be shared with ANARI, which means that individual triangles (e.g. the color) can be modified. All in all this results not in >100M API calls, but merely in a few dozens.

from anari-docs.

I definitely understand that you want to keep the API simple and convenient - that is a big advantage. Anyway, making it low overhead would not close the doors for some high-performance libraries that might seek to use a kind of standard and reusable API.

Let me start from from my example: In game development, you can do (and should do) exactly as you said. But one thing I learnt in CAD development is that you can never count on the user to create "nice" models. There is always at least one user somewhere in the world that creates something that you never thought about. The creativity is amazing thing of human persons. We really done this batching or binning, to put all the triangles of the same kind into the same bin and we render them in one or few draw calls. But the user is able to assign each object different material, different texture or even different animation. As the result, the objects cannot share the same bin. The example of triangles maybe seems naive, but boxes are very often used in CAD to construct buildings, for example. 10 millions cubes makes 120 million triangles. And unfortunately, each face of the cube can be assigned different texture, material and visibility. Thus, we have 60 millions quads. Essentially, the same problem. Any time the user might select any number of them and apply any modification, possibly resulting in 60 million set and commit operations.

Ok, now, it is my business as possible library implementer to minimize amount of Vulkan draw calls. With Vulkan, we are on low-level and we are aware that some Vulkan calls are very expensive as they might involve calls into the kernel, might have its cost in GPU silicon, etc. But with Anari, we are on high level. Thus, it is there where I would expect to have my 10 millions of cubes and handle them as Anari::Instances, able to assign different materials and textures and visibility to each one of them (and even much more). So, in contrast with low-level Vulkan where calls might be very expensive, I would expect that high level library such as Anari has minimal overhead. But ok, I am not the one designing Anari. I am just writing my feelings and wishes.

Concerning trampoline, you are right that static linking would solve that. However, it removes the flexibility of using different Anari libraries, for instance some raytracing library for making printing quality pictures and Vulkan library for real-time. It is the way, but removes this flexibility.

Concerning strings for parameter passing, I understand your view about the convenience for the programmer. It also brings disadvantages, like typos in parameter names are not detected already by the compiler - which might be sometimes hard to find bugs. Advantages like the programmer does not need to introduce new enum value for the new parameter, but just types the string is clear, or referencing parameters from samplers using string is quite easy. So, I see the advantages that are basically there and I see what we sacrificed: performance and typos.

What conclusions can be drawn from all this? I guess, there are three ways:

• minimalistic and user friendly API - The easiest way is to say: API performance is not important. We focus on convenience of usage. We accept that we will loose part of the industry that looks for the performance, but we will sacrifice it to win those that want simplicity and convenience.
• embrance all - Our priority is to see as much industry as possible to embrance our API and start to use it. We want to cooperate with them to make Anari right choice for the most of the industry. We will probably sacrifice simplicity of the API, but we want Anari to have broad impact.
• compromise - We want the core of Anari to stay as simple and user friendly as possible, but let's think about extensions that would bring performance, low overhead, and other various use cases to those that want it. For me - focused on performance - this would mean an extension that would allow to call Anari library functions directly (skipping the trampoline) and the option to use enums in the place of strings. If particular library would not support the extension, the extension would just translate any call to normal standard "core" Anari library call.

Any other ideas?

from anari-docs.