Motivation

The motivation behind offering an IPC version of the library is to avoid dependency conflicts and increase stability by running all ai computations in a separate process.

Consider the following setup (non-ipc version of the library):

Your application directly links against blace_ai.dll which in turns has some dependencies on third-party libraries. They all will be resolved into the same process space. If your application already has dependencies on some of those libraries, conflicts will occur:

Solution

In order to solve this problem, we offer an ipc workflow:

With this setup your application will link against a blace_ai_ipc.dll which offers exact same classes and methods, except that it spawns a new process for graph evaluation. All input data and results are serialized and communicated between the application process and the blace.ai IPC process. Note that you don't have to write additional code, just use include("../cmake/FindBlaceIPC.cmake")
in your project and link with
target_link_libraries(<your_target> PRIVATE 3rdparty::BlaceAIIPC)
to use the IPC workflow.

An additional benefits of this approach is increased stability (e.g. on a gpu drivers crash the main application will be unaffected).

BlaceWorld object has to exist in the scope of IpcEvaluator for it to run, as this object manages the lifetime of the worker object.

Concurrency

The IpcEvaluator is threadsafe, so the multiple instances of the class can be simultaneously used in multiple threads. Each instance submits tasks to the same worker, which will execute computation one by one.

Memory Sharing (CUDA)

If a blace::RawMemoryObject (either manually constructed or result after graph evaluation) holds CUDA memory the memory will be shared via the CUDA device, avoiding expensive copies. This is sensitive to the NVIDIA driver version (e.g. on Windows it was not working with 476.x). To avoid this behaviour, run a ToDeviceOP at the end of the graph to make sure the evaluation data is moved to CPU prior IPC-copying.