Reduce friction when porting from DX
nsubtil opened this issue · 12 comments
There seems to be a lot of interest in porting applications from DX to Vulkan. However, some developers have expressed frustration about a few pain points, mostly to do with different design decisions between DX and Vulkan. I have been collecting a non-exhaustive list of pain points:
- Per-stage descriptor sets
- Integer counters for fences
- Sparse descriptor sets
- DXGI swap chain interop
Individually, each of these features don't necessarily bring a lot of benefit, but taken together they would significantly reduce the friction in porting existing DX apps.
I imagine the least friction would be introduced by a DX -> Vulkan translation library. Is that what you have in mind? The other way around is already covered by Vulkan Portability initiative.
The scope here is a bit different. The idea is to collect feedback from developers who are already doing native DX -> Vulkan ports and see if we can turn some of that feedback into actionable items.
This is orthogonal to the Vulkan Portability initiative, though there's a chance some of these features might also make it easier to write portability layers.
Nuno, what's the aim here - are you looking for development of new features for the Vulkan API, or are you thinking about dealing with them with some sort of tooling/developer guidelines/examples?
Anything that requires a new Vulkan feature should be tracked on the Vulkan-Docs repo - otherwise the main WG will not look at it; though you're obviously free to track them here as well (please link them together!).
For the last of those points:
DXGI swap chain interop
I believe this is covered by the external_memory/fence/semaphore APIs, but an example app needs writing (which does seem like an ecosystem problem).
Figuring out if the current interop extensions can be used for this as-is sounds like a good thing to look into first.
Nuno, what's the aim here - are you looking for development of new features for the Vulkan API, or are you thinking about dealing with them with some sort of tooling/developer guidelines/examples?
I'm not leaning one way or another myself --- the intent is simply to figure out whether this is worth fixing and, if so, find the appropriate course of action. If any action items for the WG come out of this discussion, we'll file them in the appropriate repos.
Figuring out if the current interop extensions can be used for this as-is sounds like a good thing to look into first.
I looked into this a few weeks ago, and unfortunately the external_* APIs don't seem to allow for DXGI swap chain interop today, or at least not efficiently. The problem is that DXGI swap chain surfaces aren't exportable, so you can't get a share handle for any of the surfaces in the swap chain.
You could enable VK -> DXGI presents by creating a shared surface and using DX to blit into the swap chain. This might work for some use cases (and we could use some sample code here as well), but it involves an extra blit and is probably not viable for most perf-sensitive apps.
Is there a good (not toy) example anywhere of how DXGI works in DX12? I suspect DXGI is foreign enough to most involved with Vulkan that it's hard to get anything going.
Based on #26, it seems like another feature worth considering would be stream output / transform feedback support. It's not clear how important it is, but there is some indication that at least a few popular games use this functionality (see, e.g., doitsujin/dxvk#135 for more details).
More details regarding Quake Champions..:
The crashes happen 100% of the time on these 3 specific occations:
- After loading the map "Lockbox"
- After loading the map "Vale of pnath"
- When the character/champion named "Sorlag" uses his ability: Acid spit.
- At the exact same time, a tail -f on the d3d11 log on the other monitor spew out the StreamOutput not implemented errors.
- These crashes are the only ones I experience in Quake Champions.
@metalight Was that comment perhaps meant for the DXVK issue tracker?
@Cyprex Oh, sorry that was indeed meant for DXVK.. Should I delete the comment here or just leave it?
This repository is being archived as it has been replaced with the vulkan.org website (https://www.vulkan.org) and is no longer being maintained (i.e., issues posted here are no longer being addressed ). After reviewing issues posted here, most (if not all) have been resolved or have already been re-opened in Vulkan-Docs (https://github.com/KhronosGroup/Vulkan-Docs) or other repositories for further consideration. Therefore, all issues in this repository will be closed. If you believe your issue has not yet been resolved, please re-open in Vulkan-Docs. Thanks!