Commit during async frame rendering about anari-docs HOT 2 CLOSED

I was considering this point as well.

What I see with this "commit" approach is some added complexity of the code that needs to take care about the management of uncommitted data. The advantage of the commit approach is easy API design - you can have many object parameters, set them one by one, and commit them at the end. In the process, the object data might be in inconsistent state, but it does not matter as long as they are consistent at the moment of commit. The disadvantage of this approach is additional code complexity and increased memory consumption because the uncommitted data needs to be kept by Anari implementation until the commit.

An alternative approach that would remove these disadvantages would replace setParameter+setParameter+...+commit sequence by setParametersAndCommit call. The setParametersAndCommit would take list of all changed parameters and list of new data for each parameter being updated. This way, the user will provide consistent object data in a single call and these data can be applied immediately to the object without any need of temporary management of uncommitted data.

My preference is clearly with this setAllParametersAndCommit over setParameter+setParameter+...+commit approach although I understand that you might have reasons to use your approach. But even if Anari would use setParameter...commit approach, it would be nice to have setAllParametersAndCommit as an extension to avoid associated overhead and resource consumption of setParameter...commit.

Going back to original question, if we would use setParameter...commit approach, I see benefits of what @jeffamstutz suggested. Commit would not update the object data immediately. Instead, the object update would be performed on the start of the next frame. As management of uncommitted data is already there, postponing the update shall not add much to the code complexity, hopefully. One disadvantage is that we cannot already start the object update immediately (scheduling already data transfers, etc.), unless we introduce additional complexity of keeping of two copies of the object for the current and the next frame.

All in all, I am friend with such change as @jeffamstutz proposed while my hopes turn also for a performance extension that would provide setParametersAndCommit functionality as well.

from anari-docs.

Closed via #7.

from anari-docs.