You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Get that sweet Nabla-as-Middleware solution, where Nabla is made to work with already externally initialized and owned Graphics API objects.
NOTE: We already support the Nabla Master Middleware mode, where Nabla initializes and owns the Graphics API objects which are accessible to external frameworks and engines via getNativeHandle()
Description of the related problem
Grab yourself a context or vulkan instance from Unreal or Godot, then enjoy Imported Buffer and Image galore.
Solution proposal
Just make additional constructors that import VkInstance or an OpenGL context for the IAPIConnection,
and logical device creation which imports a VkDevice or an OpenGL context for all other contexts to share with.
Just like with #398 add some choice whether we destroy the imported handles or not.
Probably need semaphore import functions in the style of #398 and some special stuff for OpenGL to handle the master context sync issues.
This does not involve any cross-process/cross-instance memory/semaphore/fence import/export, we're explicitly thinking about sharing the same API Connection and Logical Device (instace/context/device) with another framework in the same process with no special interop.
The text was updated successfully, but these errors were encountered:
Description
Get that sweet Nabla-as-Middleware solution, where Nabla is made to work with already externally initialized and owned Graphics API objects.
NOTE: We already support the Nabla Master Middleware mode, where Nabla initializes and owns the Graphics API objects which are accessible to external frameworks and engines via
getNativeHandle()
Description of the related problem
Grab yourself a context or vulkan instance from Unreal or Godot, then enjoy Imported Buffer and Image galore.
Solution proposal
Just make additional constructors that import
VkInstance
or an OpenGL context for the IAPIConnection,and logical device creation which imports a
VkDevice
or an OpenGL context for all other contexts to share with.Just like with #398 add some choice whether we destroy the imported handles or not.
Probably need semaphore import functions in the style of #398 and some special stuff for OpenGL to handle the master context sync issues.
Additional context
Needs #379, #387, #390, #395, #396, #398 and possibly #399, #401 merged/resolved.
This does not involve any cross-process/cross-instance memory/semaphore/fence import/export, we're explicitly thinking about sharing the same API Connection and Logical Device (instace/context/device) with another framework in the same process with no special interop.
The text was updated successfully, but these errors were encountered: