Memory/Buffer abstraction

[szymon-rd]

The Problem

Currently, Buffer from vulkan module is only used internally in the Vulkan executor code. The execute method in AbstractExecutor and its subclasses takes Seq[ByteBuffer] and returns Seq[ByteBuffer] - That means that on each execution, the memory goes from RAM to GRAM, and then back. In Cyfra, we want a couple of features that require change to this behaviour:

• we want to allow building pipelines and composing functions in a way that does not block on GRAM/RAM transfer as it hurts performance a lot.
• we want to allow batch executions (e.g. rendering batch of frames), and sometimes totally avoid the GRAM/RAM transfer that would be orchestrated by our runtime (like in realtime rendering, there the window system takes care of that natively).

Solution

This effort will require a couple of steps (issues), but let's start with something that will already improve our situation significantly.

Executors

• Executors should accept a vulkan Buffer instead of on-RAM ByteBuffer. They should copy their content with Vulkan API to their input buffers.
• Executors should also accept output vulkan Buffers and copy results to them, instead of creating new on-RAM ByteBuffers each time.

GMem

• GMem should not hold a reference to ByteBuffer. Instead, it should reference Vulkan Buffer. This buffer should be copied to input buffers in Executor, and then the compute sequence should be executed.
• GMem should expose a constructor that builds a GMem from Array of correct type, and one that loads data from buffer and returns it as an Array.
• GMem should also expose method to clean-up the buffer.

A problem

How to deal with memory leaks? We can imagine that our users would be creating GMems a lot, and if they forget to clean them up, then they will pile up and fill up the GRAM. We need some clever mechanism here, or maybe API-level restriction that always guarantees that GMem is not left around but is a part of some pipeline.

Additional remarks

I believe MapExecutor is not used anymore, as SequenceExecutor offers the same functionality but more general. After making sure it is the case, I think it makes sense to remove it in this MR, instead of adding support of this feature to it.