-
Notifications
You must be signed in to change notification settings - Fork 689
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
DXIL support for Direct3D11 #621
Comments
This would be very nice to have indeed! We're currently stuck supporting D3D11 (and likely will be for some time), so we're unable to take advantage of the new features in dxc, even if they have no relevance to the actual API being executed on (e.g. enums). |
Sorry, we currently don't have plans to support DXIL in Direct3D11. |
Hello, is there any way to translate DXIL to HLSL? |
@SssWen No. It's theoretically possible but it would be as complex as writing a decompiler and would produce the same kind of poorly readable code. We have no scenario for it. |
Any plans for DXIL -> DXBC translator then? :) |
There is DXBC -> DXIL translator. If we have that, probably we can have backwards =) |
I guess there already must be an DXIL -> DXBC translator for the "DX12 on Windows 7" feature anyway. Would be nice to have that open source and/or at least publicly documented & usable. |
It is possible to convert modern HLSL to SPIR-V using DXC, then convert SPIR-V to legacy HLSL using spirv-cross, and then convert legacy HLSL to DXBC using FXC. This works apart from the conversion being lossy (for instance, structured buffers are turned into byte address buffers). This may or may not be an acceptable trade-off compared to not having access to new HLSL language features. |
Hello,
I was curious about that, so I thought I would post here.
It would be great to also have support for DXIL bytecode in DirectX11 as well.
Since both are still designed to work alongside each other for quite a while, and new Linker features are really promising (and best of all , open source), it would be great that we could be able to have those features for both API (otherwise, would still need to use a different compiler path for DirectX11 and DirectX12, which is a bit annoying).
So my question, is it planned at all (it means to have of course vendors to support it (and having some feature level/profile limitation)?
The text was updated successfully, but these errors were encountered: