search

aardvark-platform / aardvark.rendering

Aardvark.Rendering is a high-performance, dependency-aware rendering engine. It is part of the open-source Aardvark Platform for visual computing, real-time graphics, and visualization.
https://aardvarkians.com/
Other
131 stars 13 forks source link

Bad Update Performance of AbstractResizeBuffer #50

Closed luithefirst closed 4 years ago

luithefirst commented 5 years ago

AbstractResizeBuffer creates a Fence in afterWrite(). As this might be invoked very often per frame, the performance can be significantly limited due to this.

Use Case: In the ManagedPool this kind of buffer is used to hold geometry data and per instance attributes. When updating multiple attributes (e.g. updating 100 transformations) per frame, afterWrite will be invoked very often and the performance drop to about 100 fps from >2000 without any updates.

Please see the test implementation in "Scratch (net471)/09 - MappedBufferPerformance".

Changing the implementation of afterWrite to "nop" increases the frame rate from 100 to 700. As this potentially breaks other updates (e.g. resize), a better general solution for this kind of buffer/update would be ideal.

luithefirst commented 5 years ago

AbstractResizeBuffer / IResizeBuffer is obsolete: see #56 Changed ManagedPool to use IBuffer -> this brought up shortcomings in the IndirectBuffer API currently limiting performance on add/remove: see #57

luithefirst commented 4 years ago

With SyncUploadsAndFrames=false (current default) the framerate is now at 700 due to a new implementation of the ManagedPool and no longer using IResizeBuffer. Still, every change performs its own NamedBufferSubData update (100x per frame).