zlacker

MS had a rigorous certification and internal testing process, new D3D versions came out quickly to support new hardware features, and through the Xbox Microsoft had more real world experience for what games actually need than the GPU vendors themselves, which probably helped to rein in some of the more bizarre ideas of the GPU designers.

I don't know how the D3D design process worked in detail, but it is obvious that Microsoft had a 'guiding hand' (or maybe rather 'iron fist') to harmonize new hardware features across GPU vendors.

Over time there have been a handful of 'sanctioned' extensions that had to be activated with magic fourcc codes, but those were soon integrated into the core API (IIRC hardware instancing started like this).

Also, one at the time controversial decision which worked really well in hindsight was that D3D was an entirely new API in each new major version, which allowed to leave historical baggage behind quickly and keep the API clean (while still supporting those 'frozen' old D3D versions in new Windows versions).

>>flohof+(OP)
> Also, one at the time controversial decision which worked really well in hindsight was that D3D was an entirely new API in each new major version, which allowed to leave historical baggage behind quickly and keep the API clean (while still supporting those 'frozen' old D3D versions in new Windows versions).

This is interesting. I have always wondered if that is a viable approach to API evolution, so it is good to know that it worked for MS. We will probably add a (possibly public) REST API to a service at work in the near future, and versioning / evolution is certainly going to be an issue there. Thanks!

>>moring+oe
It’s a COM based API and so everything is an interface described via an IDL. You add a new member or change the parameters to a method, you must create a new version of the interface with a new GUID descriptor. You can query any interface for other interfaces it supports, so it’s easy for clients to check for newer functionality on incremental versions of DirectX.

In practice for DirectX you just use the header files that are in the SDK.

>>moring+oe
I've never had to migrate between DirectX versions but I don't imagine it's the easiest thing in the world due to this approach. Somewhat related I saw a library to translate DirectX 9 function calls to DirectX 12 because apparently so much of the world is still using DirectX 9.

>>jamesf+Wr2
That's what the drivers for the new Intel GPUs have to do, since the GPUs were only designed for DX12, and need earlier versions to be emulated

>>kalleb+kE2
Ah yeah, and it looks like this is what they're using: https://github.com/microsoft/D3D9On12 And it looks like DirectX 11 to DirectX 12 translation exists as well: https://github.com/microsoft/D3D11On12