Originally posted by ElectricPrism
View Post
Announcement
Collapse
No announcement yet.
Vulkan 1.1 Released As The First Major Update To This Graphics/Compute API
Collapse
X
-
Originally posted by Karbowiak View PostThis is probably a dumb question, but what with Vulkan 1.1 supporting HLSL in some form - wouldn't this make the work for the guy writing DXVK easier?
The problem with porting between GL and DX9 is that they are very different beasts and architecturally different, bunch of GL driver is implemented in userspace whereas DX drivers run in kernel mode (which has been historically seen as downside of DX, because kernel context switches are costly).
MS did improve on this with DX10 (or 11, don't recall), allowing parts of "certified" DX drivers to run in userspace. But without straying too off-topic, DX9 models graphics concepts, whereas Vulkan/DX12 models graphics hardware concepts. Hence why it's easier to port DX12 <> Vulkan and why it's difficult to port GL <> DX9.
It's not terribly hard to do machine translation, but doing so efficiently is much easier when underlying models are same.
Back to your original question, unless you really don't care about backwards compatibility, any change (even for better) just means more work.
- Likes 1
Comment
-
Originally posted by pal666 View Postall vulkan drivers support 1.1, so compatibility with what?
Comment
-
-
Originally posted by oiaohm View Post
Maybe yes maybe no. If DXVK wants to keep Vulkan 1.0 support might mean needing two shader compliers to get best performance.
This repo hosts the source for the DirectX Shader Compiler which is based on LLVM/Clang. - microsoft/DirectXShaderCompiler
Above is interesting right. HLSL to SPIR-V is being included in Microsoft compiler its DXIL ot SPIR-V and back that is interesting problem as well.
Dilithium is a bidirectional shader converter for converting between DXIL and SPIR-V. - gongminmin/Dilithium
Above is interesting.
This repo hosts the source for the DirectX Shader Compiler which is based on LLVM/Clang. - microsoft/DirectXShaderCompiler
Targeting DX11 means you have to support dxbc2dxil.dll that beast allows DX11 program to use shaders for older versions of DX back to dx9. So there is room for a joint project working on shaders.
Targeting DX12 is where you get to drop legacy.
Also these extra SPIR-V features for simpler DX shader conversion will this come to opengl SPIR-V as well.
Its been interesting that DXIL is open specification and the old dxbc is closed specification. Yes dxbc support is quite a big pain in tail.
- Likes 2
Comment
-
Originally posted by dfx. View PostSo, instead of amalgamating Vulkan and OpenCL they've put DRM right into APIā¦ what a time to be alive !
But, if someone is insistent on copy protection, then the choice is rather one of enabling an extensible Vulkan backend or having a closed, proprietary path. At least making it open and extensible lets media players (and video processing plugins, I think) do some interesting things with the content.
The way I see it, the DRM battle was lost, long ago. It's here to stay. The best we can hope for is to minimize the downsides - and one significant downside was the inability to have open and extensible post-processing (e.g. sophisticated deinterlacing, motion interpolation, noise reduction, film grain & scratch removal, blur reduction, super-resolution, black level correction, de-banding, etc.). I'm no fan of DRM, but I'm happy for it to get in the way a bit less.
- Likes 1
Comment
Comment