I'm working with feliwir on the project.
From my finding every D3D8 object, is wrapped using the D3D8WrappedObject class along it's hierarchy:
https://github.com/doitsujin/dxvk/blob/e7ec5be5d29433b4b1d3f54c29f838ee68875a8c/src/d3d8/d3d8_wrapped_object.h#L24
This means that there's a function there in DXVK's case, which allows conversion to D3D9.
Is it possible to use that to obtain the D3D9 Swapchain from the D3D8 Swapchain for example, to get the Backing Buffers, to then use QueryInterface to obtain the ID3D9VkInteropTexture to then obtain VkImage?
Is that an intended way, or am I missing something here?
Exposing Vulkan objects in general is a massive can of worms that's a) probably not going to work the way anyone thinks it does and will b) lock us out of making any changes to any of the code interacting with those objects for all eternity unless we want to break stuff. This has been a huge headache with any of the existing interop APIs before that's still not fully resolved, and I'm not planning on making it even worse.
Swapchains and surfaces have platform-specific lifetime constraints and may need to be recreated for all sorts of different internal reasons and generally exist on a timeline that is detached from the application's main thread, so exposing any of that to the app safely is impossible.
What exactly do you need access to the VkSurface for anyway?
Is it possible to use that to obtain the D3D9 Swapchain from the D3D8 Swapchain for example, to get the Backing Buffers, to then use QueryInterface to obtain the ID3D9VkInteropTexture to then obtain VkImage?
I guess we could theoretically add some sort of COM interface to expose the D3D9 object for any given D3D8 object (just adding those to QueryInterface isn't really viable since that's just going to break actual games), and that approach might actually sort-of work because exposing D3D-side image resources is actually reasonably well defined.
Just keep in mind that D3D9 and IDirect3DSwapChain9::GetBackBuffer in particular is cursed wrt resource lifetimes, the only safe way to interact with that in general is to re-query the back buffer once per frame and release the reference before the game can make any additional D3D calls.
Again, I don't really know what the exact goal here is, but if it's just to make UI stuff display properly then the ideal solution is probably one that doesn't touch D3D at all.
The surface was just an example of a vulkan object we want to access.
The goal / behavior we want to mimic is embedding a D3D8/9 view into a Gui application.
Inside C&C Generals (the game we are porting) this is achieved by using a HWND provided by MFC (the UI toolkit).
Looking at cross-platform UI toolkits nowadays there is Qt6 & Gtk4, which both provide ways to render Vulkan images. So it seemed natural to me to render the generated DXVK Vulkan ouput.
What would be your recommendation on how to use DXVK in an embedded widget context? Copying the pixels via D3D API to the CPU and then reuploading them from the UI toolkit not a viable option due to the overhead
I think what you actually want for your use case is to implement a custom WSI backend (similar to how sdl3 etc are implemented) to forward the Qt-managed Vulkan surface to DXVK.
From my understanding this would require modification of DXVK?
Would it be possible to register a custom WsiDriver? I suppose that's currently not the case?
EDIT: Is there interest in a WSI driver for Qt6? I thought maybe a more generic implementation would be appropriate over something specific like Qt6.
Asking to determine, if it makes sense to try and create a PR in case we develop this feature, and in which direction it should go.
EDIT3: I was thinking of something along the lines of "dxvk::SetWsiDriver(IWsiDriver *)"
Looking at cross-platform UI toolkits nowadays there is Qt6 & Gtk4, which both provide ways to render Vulkan images. So it seemed natural to me to render the generated DXVK Vulkan ouput.
There is also ImGui. People writing editors, game and game engine interfaces all the time. But this tying is special.
IDK if it will be better or will work, but maybe native SDL + native dxvk + ImGui (sdl+dx9) backend will do?
Nothing extracted yet.
Hey,
I am using DXVK-Native to port old games (e.g. C&C Generals) to Linux & macOS. There are windows applications (e.g. MapEditor) that embed their D3D8 rendering into a control of an application (see screenshot)
I'd like to use QVulkanWindow (Qt6) to draw the existing Vulkan surface by DXVK. However that is not accessible by default. Could that (and other internal Vulkan object) be made accessible by the API?