Gfx: Why supporting dx12 ?

Created on 27 Jan 2018  路  8Comments  路  Source: gfx-rs/gfx

I ask this a bit late.. But why do you spend human time and workforce for supporting dx12 while the only OS that support this proprietary jail is Window 10, that is also supported by the World industry standard Vulkan, that have as good drivers implementations (whatch DOOM performance for example), will extremely probably be like the next Web standard, and is supported on Windows 8,7,vista, etc that are the majority of the market, plus supporting Linuxes, BSDs, and that little thing called Android.

I really see no rational reasons and I would have hoped that the opensource world would promote open standards, but the opensource community in general is really paradoxal here, mozilla is pushing a dx12 prototype for webGL next.. And CUDA is everywhere on the opensource AI world despite being supported on 10% of the World hardware...

That was my first point, the second is why supporting Metal ? There are tools like moltenVK 1) and 2) why don't the opensource community in general don't understund that if the opensource community was not supporting metal, especially if the next Web standard is not supporting m茅tal, Apple would not have other choice than joining the standard instead of staying on their retarded proprietary spec.

Maybe @Kvark could give me the point of view of mozilla ?

Sorry if I'm too HS by generalising the problem to the opensource community, you can of course just answer the gfx rs bits.

Most helpful comment

@LifeIsStrange
First of all, gfx-rs is not a Mozilla project (at least, not yet), it's a truly Rust community project.

only OS that support this proprietary jail is Window 10, that is also supported by the World industry standard Vulkan

Here comes one problem: not all real-world windows machines can run Vulkan. Some just lack the drivers (Iris GPUs from Haswell/Broadwell generatios). Some just never happened to include the Vulkan SDK (you can check it in a local PC store).

One of the goals of gfx-rs is to power WebRender and Firefox/Gecko, in which case we can't require the user to go somewhere and fetch the SDK. We need to run fast out of the box.

will extremely probably be like the next Web standard

Where did you get this idea from? From what I see, it's not likely, even though we are putting considerable effort to make it real.

I really see no rational reasons and I would have hoped that the opensource world would promote open standards

This is what we do. Vulkan Portability initiative, which we are implementing, is precisely making Vulkan (the only open standard of next-gen graphics API) to be come available everywhere, including the walled garden.

but the opensource community in general is really paradoxal here, mozilla is pushing a dx12 prototype for webGL next.

You must have misunderstood Mozilla. No one even has a dx12-based WebGL Next prototype on their hands (or minds, for the matter), never mind pushing it.

And CUDA is everywhere on the opensource AI world despite being supported on 10% of the World hardware

Different markets, different reasons. Being open source doesn't change the fact that the software should do the jobs. AI market is such that people have a liberty to choose the server hardware to run on, so no need to use a standard that tries to cover everything.

why supporting Metal ? There are tools like moltenVK

We are competing with MoltenVK on this space, aiming to provide a faster, opener, more portable and robust implementation.

if the next Web standard is not supporting m茅tal, Apple would not have other choice than joining the standard instead of staying on their retarded proprietary spec.

Pushing on Apple is not the greatest way to make it a standard in the first place. For example, they've never updated GL past 4.1, and no one file lawsuits about that. A standard is more likely to be accepted and implemented if it respects the native differences between platforms.

Imagine a World Where the W3c would be the Equivalent of khronos but

These standards operate in vastly different constraints. There are plenty of rational reasons for MS and Apple to come up with their APIs. For one, they both appeared earlier than Vulkan. They match the platform native APIs better (COM interfaces on DX12) as well as the hardware (Apple can pick/make the HW and work with them to have good Metal support). Let's not try to blame anyone and instead attempt to bridge the gap that has emerged between platforms by implementing our gfx-rs portability layer.

TL;DR on "Why supporting dx12" ?

  • need WebRender running fast out of the box on more platforms
  • as we power WebGPU implementation, and it's only going to become a standard if Microsoft and Apple sign in, we need to respect and support their native backing APIs
  • alternative is always good to investigate performance pitfalls, bugs, etc

All 8 comments

A little abalogy for mozilla :
Imagine a World Where the W3c would be the Equivalent of khronos but Where Microsoft would suddenly launch new Web specs but they would be only designed by them and implementors would only have the right to implement them on Windows, would you support them, loosing control and making Linux, Android and OSX not supporting Windows only websites ?
I don't think mozilla employees would say yes.
But what is the difference between this thought experiment and Vulkan vs dx12 ? Despite the fact that you are more involved in the liberty of the Web (W3c/whatwg) than of the liberty of gpu computing (khronos, HSA foundation, gpuopen.com)?

@LifeIsStrange
First of all, gfx-rs is not a Mozilla project (at least, not yet), it's a truly Rust community project.

only OS that support this proprietary jail is Window 10, that is also supported by the World industry standard Vulkan

Here comes one problem: not all real-world windows machines can run Vulkan. Some just lack the drivers (Iris GPUs from Haswell/Broadwell generatios). Some just never happened to include the Vulkan SDK (you can check it in a local PC store).

One of the goals of gfx-rs is to power WebRender and Firefox/Gecko, in which case we can't require the user to go somewhere and fetch the SDK. We need to run fast out of the box.

will extremely probably be like the next Web standard

Where did you get this idea from? From what I see, it's not likely, even though we are putting considerable effort to make it real.

I really see no rational reasons and I would have hoped that the opensource world would promote open standards

This is what we do. Vulkan Portability initiative, which we are implementing, is precisely making Vulkan (the only open standard of next-gen graphics API) to be come available everywhere, including the walled garden.

but the opensource community in general is really paradoxal here, mozilla is pushing a dx12 prototype for webGL next.

You must have misunderstood Mozilla. No one even has a dx12-based WebGL Next prototype on their hands (or minds, for the matter), never mind pushing it.

And CUDA is everywhere on the opensource AI world despite being supported on 10% of the World hardware

Different markets, different reasons. Being open source doesn't change the fact that the software should do the jobs. AI market is such that people have a liberty to choose the server hardware to run on, so no need to use a standard that tries to cover everything.

why supporting Metal ? There are tools like moltenVK

We are competing with MoltenVK on this space, aiming to provide a faster, opener, more portable and robust implementation.

if the next Web standard is not supporting m茅tal, Apple would not have other choice than joining the standard instead of staying on their retarded proprietary spec.

Pushing on Apple is not the greatest way to make it a standard in the first place. For example, they've never updated GL past 4.1, and no one file lawsuits about that. A standard is more likely to be accepted and implemented if it respects the native differences between platforms.

Imagine a World Where the W3c would be the Equivalent of khronos but

These standards operate in vastly different constraints. There are plenty of rational reasons for MS and Apple to come up with their APIs. For one, they both appeared earlier than Vulkan. They match the platform native APIs better (COM interfaces on DX12) as well as the hardware (Apple can pick/make the HW and work with them to have good Metal support). Let's not try to blame anyone and instead attempt to bridge the gap that has emerged between platforms by implementing our gfx-rs portability layer.

TL;DR on "Why supporting dx12" ?

  • need WebRender running fast out of the box on more platforms
  • as we power WebGPU implementation, and it's only going to become a standard if Microsoft and Apple sign in, we need to respect and support their native backing APIs
  • alternative is always good to investigate performance pitfalls, bugs, etc

(Disclaimer: not a developer of this project, just a fan waiting for 0.1 release of gfx-hal)

I would add additional argument which I barely see mentioned in similar discussions. Microsoft is pushing heavily it's new UWP platform (see their magazine/blogs "propaganda", WinRT/C++ project being incorporated into Visual Studio in next version, etc.) based on WinRT APIs. However, there is a catch that if you want pure WinRT(without Win32) UI(XAML) application, package and ship it to store, you can't use Vulkan. (I believe similar case is with macOS+cocoa+metal)

We might not like it, but if one wants to develop modern windows application for store with their current design(fluent as of recently) and have some kind of viewport(think of photoshop, 3ds max kind of apps) accelerated through low-level api, your only option is DirectX12.

On the bright side, I see this as an opportunity for gfx-hal to be base for some next-gen UI frameworks capable of calling native apis for UI(cocoa, winrt, gtk, qt...) on each platform and using the right low-level api for custom viewports(metal, dx12, vulkan).

Thanks @MatusT , this makes sense in light of the recent Polaris OS news. You also reminded me of another strong reason to have dx12: XBox support.

On that note, I find the arguments pretty strong, and we haven't heard back from the OP. Closing, unless there are objections.

I think this conversation should be archived and linked from the README or maybe rewritten and merged into the README. Thoughts?

@anderejd there is quite a bit of info here that we'd want to be more available to anyone. I'm thinking about a wiki page explaining why each backend is needed. It could store the major points as well as point to this issue.

Some just never happened to include the Vulkan SDK

FTR the vulkano documentation very clearly states that you don't need the Vulkan SDK.

@jansol fair, but the point still stands: there is a large portion of machines that either don't ship with vulkan support (say "vulkan-1.dll" instead of Vulkan SDK), or simply don't have the drivers in existence (Intel Haswell/Broadwell, which support DX12 feature level 11.1 out of the box).

Was this page helpful?
0 / 5 - 0 ratings

Related issues

kvark picture kvark  路  3Comments

Fluci picture Fluci  路  5Comments

msiglreith picture msiglreith  路  3Comments

torkleyy picture torkleyy  路  4Comments

norru picture norru  路  4Comments