-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SPEC] External GPU memory interop (OpenGL, Vulkan, DirectX) #9925
Comments
It is great that there will be a generic texture interop mechanism in Avalonia. I think that I understand the specification and the steps that user would need to take to render a shared texture. From the user's point of view, it would be good if
On Vulkan the following can be used:
Note that calling Some other minor spelling / conceptual issues or ideas:
The same applies for Similarly the
I am looking forward to a working demo of that spec. |
We are using strings to describe
According to the Vulkan spec: it "specifies a POSIX file descriptor handle that has only limited valid usage outside of Vulkan and other compatible APIs". This fd can only be exported from Vulkan, it can't be created by OpenGL. A universal API-agnostic (and usable by multiple physical devices) handle would be the DMABUF one. We'll add support for those extra handle types at some point too.
DirectX-compatible DXGI share handles are represented by Vulkan has its own |
|
DirectX 11 supports semaphores via
|
This looks very promising 😄 Just trying to understand this better - a while back I've prototyped implementing a custom D3D12 swap chain in Avalonia (see here), which I did by using a platform native control and then just plugged a DXGI swap chain from the given HWND (full source code in this branch). I'm trying to understand what the benefit of this would be vs. using that approach, as it seems this would also involve some additional steps to plug everything together. Is that because this would allow the swap chain to better interoperate with other visual tree elements compared to using a Really cool stuff though! Also love how some of the API names are (roughly) the same as on UWP ahah |
Nit: I would strongly recommend adding the "Async" suffix to |
@Sergio0694 problem with NativeControlHost-derived control is level of integration into the app, yes. As on most platforms it's basically another window glued in the middle of parent window. But it's still probably the easiest way to integrate native controls into the Avalonia app. |
I can't get this to run on Mac (M2 MacBook Pro) at all - It complains that the backend does not support image sharing. Is this a known issue? Can it be fixed? Is there another (platform independent) way to access the GPU within an Avalonia application? |
On macOS we currently only support interop via shared OpenGL context. IOSurface/CVPixelBuffer are planned but no ETA. |
Thanks, I took a quick look at it, but I think I need a deeper understanding of how the compositing works in Avalonia before I can make any use of that information :) |
I am working with this and I encountered problem that I cannot solve. can you please check my question #17689 |
To avoid jittering and rendering artifacts, any user-rendered GPU images need to be properly synchronized. By properly synchronized we mean:
We are adding
CompositionDrawingSurface
andCompositionSurfaceVisual
APIs (CompositionBrush and CompositionSpriteVisual would come later).User code could use
ElementComposition.SetElementChildVisual
to display theCompositionSurfaceVisual
on top of their control.CompositionDrawingSurface
retains its own copy of the image. To update said copy one needs to provide a GPU-backed image with some means to wait for rendering to be completed:What is
ICompositionImportedGpuImage
? It's an object that represents an externally allocated GPU memory, that's been imported to use with the compositor and the current GPU context (it will become invalid once that context is lost).ICompositionImportableSharedGpuContextObject
and friends would be obtained from IGlContext and are required to support platforms where we provide OpenGL rendering support via OpenGL context sharing and for those who wish to reuse the same VkDevice for both Avalonia and user code.OpenGlControlBase
,VulkanControlBase
and swapchains are outside of the scope of this spec. We are getting complaints about our built-in base controls being too inflexible for various applications, so the goal of this spec is to define a flexible API that can be used to implement both our built-in simple controls an complex user scenarios.For vsync-synchronized rendering, we'll just add
RequestAnimationFrame
API that would allow one to do rendering just before the composition batch is sent to the render thread:The text was updated successfully, but these errors were encountered: