Khronos working on an '3D Portability Initiative' to enable portable development across Vulkan, DX12 and Metal

Quoting: etonbearsFrom the viewpoint of a D3D developer, it's actually a lot better than that; Microsoft have a "merged" D3D11/D3D12 mode that gets you many of the benefits of D3D12 API while keeping most of the D3D11 calls the same. There is really no reason to change to Vulkan unless a developer wants to target additional platforms.

The reasoning behind this announcement/initiative is probably a pragmatic acknowledgement that the world will not become Vulkan overnight, and possibly not at all. For a general cross-platform application that wants to have some 3D capability, and for WebGL client implementations, having such a compatibility layer may help ( they are inviting input, so we don't know how such a layer would work ).

For games and other performance-sensitive applications, maybe it is not such a good idea, as there would probably not be as much opportunity to optimize with either a source-level code generator or binary-level translator.



As something of an aside, there seems to be an assumption by many people that adoption of Vulkan by developers is both an obvious step and a trivial task. For some developers one or both of these are true, but for many they are not.

What if you have a game or other application written in C++/COM on Windows, with all the appropriate development and content tools a practices? Are you going to adopt a new C API and development model for a few percent extra sales, or use the safe option of an updated familiar friend?

Vulkan is the "natural" 3D API for Android/Linux ARM devices and GNU/Linux x86 devices ( as well as potentially other Linux, BSD and SysV derivatives ), so anyone that has an interest in targeting these platforms, such as game engine developers, have been quick to adopt Vulkan. But I think it is the support in Android that is the more important driver for adoption than any support in Windows.

I think you refer to D3D11on12. That is primarily made for porting purposos, or reuse D2D, text and UI. It is by no means easy to use or in any way recommendable. And it is definately not wise (or simply impossible) to mix a D3D11 and D3D12 in the renderpipeline.
For me the 3d portability initiative is a way for every parttaking company to tell Microsoft and Apple: "We want open cross platform APIs".
We'll see how much members the initiative will have.

bgfx

Quoting: webcreatureI think you refer to D3D11on12. That is primarily made for porting purposos, or reuse D2D, text and UI. It is by no means easy to use or in any way recommendable. And it is definately not wise (or simply impossible) to mix a D3D11 and D3D12 in the renderpipeline.
For me the 3d portability initiative is a way for every parttaking company to tell Microsoft and Apple: "We want open cross platform APIs".
We'll see how much members the initiative will have.

Yes, D3D11on12 which does automatic D3D11 to D3D12 conversion at the driver level ( i.e. you don't actually mix D3D11 and D3D12 ). It's downsides are some CPU overhead and significant CPU-side memory overhead, since it is keeping both D3D11 and D3D12 copies of data and synchronizing them at the driver level. This may not be good for everything, as there are some parts of D3D11 that are not supported, but it still allows gradual migration of code that is likely to be more appealing to some than trying to shoehorn an entirely new and alien API ( not C++, not COM ) into code that they may not want to re-architect. Even if the render functions are converted to Vulkan, the rest of the code is likely tied to Visual C++ and DirectX/COM. At least in the short term, I think you will see many existing Windows games companies ( that are not engine vendors or users ) move to D3D12 first before adding Vulkan, if they do at all.