Update Various C++ Documentation Examples to Current Interface

[KeithJH]

Updated various C++ documentation examples and TestBenchmark to code that will compile. This largely is updating references of kp::OpTensorSync{Device,Local} to kp::OpSync{Device,Local} and updating algorithms to use kp::Memory instead of kp::Tensor as these changes were introduced in #388.

Examples from documentation were tested by copying into a local C++ project setup to use Kompute and compile without any modification to the example code.

TestBenchmark was tested by compiling Kompute with KOMPUTE_OPT_ENABLE_BENCHMARK="ON" and ensuring the produced binary runs.

[KeithJH]

Is there a better way to signify running the same shader but with a different tensor bound for this example other than creating another Algorithm? The code before my change just ran both sequences updating tensorA and tensorB was never updated. The below print appears to expect both updated, which makes sense for a more useful example.

[axsaucedo]

I'm not sure I follow, could you provide an example of what you mean?

[KeithJH]

@axsaucedo Anything that more closely resembles what the code was previously trying to do, with reuse of algo instead of creating two separate algorithms. I've not looked into the backend, but this could be to avoid any overhead around spirv being duplicated (like making sure it's loaded/ready on device).

I'm going to guess that since there wasn't an immediate suggestion to change here that there is no concern in having the separate algorithms and we should continue as-is.

[KeithJH]

Perhaps a poor example as it doesn't make sense with how everything is laid out, but I could imagine a world where you would see something similar to:

sqOne->evalAsync<kp::OpAlgoDispatch>(algo, tensorA);
sqTwo->evalAsync<kp::OpAlgoDispatch>(algo, tensorB);

[axsaucedo]

Ah I see what you mean now - yes this would actually be much desirable. When designing kompute this was initial aim as well, unfortunately due to the design of the underlying vulkan architecture it's not possible (namely due to the dependency between the descriptor sets, the algorithm and the tensors) which make it such that initialisation is coupled. This is something that I hope at some point is addressed in the design of Vulkan, but at least in the medium term this doesn't seem to be planned. Hope this provides further context.

[KeithJH]

There are more potential changes, but this PR covers the ones I felt comfortable validating with my current development environment. Presumably changes are also necessary for the below. I can create issues for these to be handled separately.

Python Examples:

PS kompute-fork> ls -r docs\overview\python* | select-string OpTensorSync

docs\overview\python-examples.rst:17:   from kp import Manager, Tensor, OpTensorSyncDevice, OpTensorSyncLocal, OpAlgoDispatch
docs\overview\python-examples.rst:29:   sq.eval(OpTensorSyncDevice([tensor_in_a, tensor_in_b, tensor_out]))
docs\overview\python-examples.rst:44:   sq.eval(OpTensorSyncLocal([tensor_out]))
docs\overview\python-examples.rst:69:    seq.eval(kp.OpTensorSyncDevice([tensor_in_a, tensor_in_b, tensor_out]))
docs\overview\python-examples.rst:86:    seq.record(kp.OpTensorSyncLocal([tensor_in_a]))
docs\overview\python-examples.rst:87:    seq.record(kp.OpTensorSyncLocal([tensor_in_b]))
docs\overview\python-examples.rst:88:    seq.record(kp.OpTensorSyncLocal([tensor_out]))
docs\overview\python-examples.rst:114:    mgr.sequence().eval(kp.OpTensorSyncLocal([t1, t3]))
docs\overview\python-examples.rst:125:    sq_sync.record(kp.OpTensorSyncLocal([t1, t3]))
docs\overview\python-examples.rst:211:    sq.sequence().eval(kp.OpTensorSyncDevice(params))
docs\overview\python-examples.rst:216:    sq.record(kp.OpTensorSyncDevice([tensor_w_in, tensor_b_in]))
docs\overview\python-examples.rst:218:    sq.record(kp.OpTensorSyncLocal([tensor_w_out_i, tensor_w_out_j, tensor_b_out, tensor_l_out]))

C++ Reference Documentation:

PS kompute-fork> ls -r docs\overview\reference.rst | select-string OpTensorSync

docs\overview\reference.rst:98:OpTensorSyncLocal
docs\overview\reference.rst:101:The :class:`kp::OpTensorSyncLocal` is a tensor only operation that maps the data from the GPU device memory into the local host vector.
docs\overview\reference.rst:103:.. doxygenclass:: kp::OpTensorSyncLocal
docs\overview\reference.rst:106:OpTensorSyncDevice
docs\overview\reference.rst:109:The :class:`kp::OpTensorSyncDevice` is a tensor only operation that maps the data from the local host vector into the GPU device memory.
docs\overview\reference.rst:111:.. doxygenclass:: kp::OpTensorSyncDevice
docs\overview\reference.rst:119:.. doxygenclass:: kp::OpTensorSyncDevice

Godot code:

PS kompute-fork> ls -r examples\godot* | select-string OpTensorSync

examples\godot_examples\custom_module\kompute_summator\KomputeSummatorNode.cpp:86:        sq->record<kp::OpTensorSyncDevice>({ this->mSecondaryTensor });
examples\godot_examples\custom_module\kompute_summator\KomputeSummatorNode.cpp:92:        sq->record<kp::OpTensorSyncLocal>({ this->mPrimaryTensor });
examples\godot_examples\gdnative_shared\src\KomputeSummator.cpp:83:        this->mSequence->record<kp::OpTensorSyncDevice>(
examples\godot_examples\gdnative_shared\src\KomputeSummator.cpp:92:        this->mSequence->record<kp::OpTensorSyncLocal>(
examples\godot_logistic_regression\custom_module\kompute_model_ml\KomputeModelMLNode.cpp:67:            mgr.sequence()->eval<kp::OpTensorSyncDevice>(params);
examples\godot_logistic_regression\custom_module\kompute_model_ml\KomputeModelMLNode.cpp:71:                ->record<kp::OpTensorSyncDevice>({ wIn, bIn })
examples\godot_logistic_regression\custom_module\kompute_model_ml\KomputeModelMLNode.cpp:73:                ->record<kp::OpTensorSyncLocal>({ wOutI, wOutJ, bOut, lOut });
examples\godot_logistic_regression\gdnative_shared\src\KomputeModelML.cpp:71:            mgr.sequence()->eval<kp::OpTensorSyncDevice>(params);
examples\godot_logistic_regression\gdnative_shared\src\KomputeModelML.cpp:75:                ->record<kp::OpTensorSyncDevice>({ wIn, bIn })
examples\godot_logistic_regression\gdnative_shared\src\KomputeModelML.cpp:77:                ->record<kp::OpTensorSyncLocal>({ wOutI, wOutJ, bOut, lOut });

[axsaucedo]

Amazing, thank you very much for the contribution, this is indeed well needed - much appreciated.

[axsaucedo]

LGTM