Advertisement

DirectX 12

Started by August 08, 2014 06:15 AM
2 comments, last by _the_phantom_ 10 years, 3 months ago

Okay,

Next year is supposed to be the year of the release of DirectX 12. I had another article on DX 12 in GDNet Lounge but the reply time limit was reached. More has come to light about DX12.

Microsoft believes that DirectX 12 will run on all NVidia Hardware in which DirectX 11 runs. About 40% of AMD graphics that runs DirectX 11 will also take DirectX 12 "out the box". NVidia worked with Microsoft for the last 4 years on DirectX 12 in contrast with AMD developing Mantle API in recent years. DirectX 12 is targeting mainly personal PCs, though will be support for other computing devices. The partnership of Microsoft and NVidia has the aim of "creating the next generation graphics for PC games", while offering both a leaner API layer and opening more access to resources in hardware acceleration. Previous versions of DirectX added more coding overhead to handle legacy issues and cross-platform implementation, among other things. It looks as though DirectX 12 will be more targeting to later system and hardware than previous DX versions.

Big title game developers will have an adjustment to make in their approach to DX graphics. DX 12 seems to be made to provide all that NVidia graphics has to offer. Microsoft wants to reply to Mantle and keep competitive pressure on OpenGL. It would seem that each major hardware developer is being offered a certain API solution. Is the day of cross-platform APIs nearing a close?

There is a nice article in July Edition of Maximum PC about DirectX 12.

Personal life and your private thoughts always effect your career. Research is the intellectual backbone of game development and the first order. Version Control is crucial for full management of applications and software. The better the workflow pipeline, then the greater the potential output for a quality game. Completing projects is the last but finest order.

by Clinton, 3Ddreamer

I was under the impression that DX12 will be like DX11, in that it will have several "feature levels"
i.e. it will be possible to write code that runs on a DX9-class GPU device, using the DX12 API (and a low feature level).
One of the main reasons behind this is because they'll want to use it on PC games (who at least want to support DX10-level GPUs), Xbone games (AMD DX11.1-level), and Phones/tablets (ARM, Intel low power, Tegra, PowerVR, Qualcomm, etc)...
So:

Microsoft believes that DirectX 12 will run on all NVidia Hardware in which DirectX 11 runs. About 40% of AMD graphics that runs DirectX 11 will also take DirectX 12 "out the box".

Sounds like you might be talking about a FEATURE_LEVEL_12?

Is the day of cross-platform APIs nearing a close?

DX12 is supposed to be fairly cross-platform. It's designed to cover both tiled vs non-tiled GPUs, register-based vs bindless-resource GPUs, tessellation-enabled vs traditional pipeline GPUs, compute vs non-compute GPUs, programmable-DMA vs CPU driven GPUs, etc... The thing is, they've thought about all these problems from scratch, building an API that fits all of these kinds of GPUs very neatly, without imposing a huge "interface mismatch" with any of them.

Is the day of cross-platform APIs nearing a close?

Depends. We already do DX9 or GL* for WinXP, DX11 (level 9/10/11) or GL* for WinVista+, GL* for Linux, GL# for Mac, GLES* for Mobile, and a unique API for every different games console (that's 4 APIs for devs at the moment doing cross-generation PS/Xbox work, but could be as high as 8 or more)...

DX12 is going to be cross-vendor, just like all other versions of DX11 (it will run just as well on nVidia/AMD/Intel/Qualcomm/etc).
Mantle is currently AMD-only (and not publicly available / "private beta"), but it is designed to be cross-vendor as well! It's just currently unknown how the other vendors will react -- whether they'll support it or not... I'm in the beta, so I'm certainly going to do my best to help get Intel/nVidia interested in supporting it.

GL* = Intel, nVidia and AMD's individual implementations of OpenGL 2/3/4 (9 versions x Windows+Linux = 18 versions).
GL# = Apple's implementations of OpenGL 2/3/4 (3 APIs)
GLES* = Dozens and dozens of individual implementations of OpenGL|ES 1/2/3.

A current game could in theory be:
* written for cross-platform GL3 ("one API"), but then tested/tweaked/fixed for 7 different implementations of GL3.
* written for Dx11-FL10, Xbox360, PS3, Xbone, PS4 (5 APIs).
* written for cross-platform GL3, Xbox360, PS3, Xbone, PS4 (5 APIs, but 11 implementations).
* written for Dx9, Dx11-FL9, Dx11-FL10, Dx11-FL11, Xbox360, PS3, Xbone, PS4 (8 APIs).
* written for cross-platform GL2, GL3, GL4, Xbox360, PS3, Xbone, PS4 (7 APIs, but 25 implementations).
* written for cross-platform GLES and then tested/tweaked/fixed until the end of time.
Advertisement

It's more the case that we're currently in a transitional phase for hardware and APIs. We've had a few of these in the past - the first introduction of consumer graphics hardware, shaders, compute - and the typical pattern has been that we get a relatively short period of shaking-out while vendors try out proprietary solutions that compete with other cross-vendor solutions, until eventually a cross-vendor solution that may not be as good as the proprietary solutions but is good enough for mainstream acceptance wins out. Right now we're transitioning from high-level fairly abstract APIs that do a lot of the work for you but come with overhead and baggage as a result to lower-level APIs where the opposite applies. Give it a few years and you may see things settle down.

One complicating factor however is that having to write to multiple graphics APIs is no longer seen as such a big deal (if it ever was). It's now more of an accepted norm due to people having to do it for console support, and as a result seeing that (1) it's certainly possible, (2) the API-specific code need not be too large, and (3) maintenance is not that huge an overhead.

Direct3D has need of instancing, but we do not. We have plenty of glVertexAttrib calls.

It's not so much that's "not a big deal" its more a case of "fuck it, we have to do it anyway so meh..." - no one WANTS to write umpteen versions of their backend because Vendor 2321 couldn't get their shit together but the unfortunately reality is graphics APIs are just broken basically everywhere.

Fortunately they have such a low code footprint that you can take the 'meh' approach and tune the fuck out of each backend to work on the target platform.

Everyone would love a world where a sane version of something like OpenGL (low overhead, sensible API, extendable) really did work everywhere so we only had to write one backend and the drivers just worked.. but alas that isn't the case, be it desktop or mobile... (and this segues into a whole Android rant at this point...).

When the dust settles chances are the landscape won't have changed that much;
- D3D via D3D12 will still be the primary 'go to' API for Windows based devices
- OpenGL will continue to ignore multi-threading and pretend the API is just fine and this is still the 90s when single threads are getting faster
- OpenGL|ES will continue to be an amusingly half implemented API in the mobile world

With the changes being;
- Mantle, while cool, lives and dies on 3rd party adoption and NV seem dead against it, Intel less so.. its in engines now so it'll be around for a while at least.
- Metal will be needed for those doing iOS dev who want any performance - again, already in some engines so that'll stick
- Google finally making an effort to enforce OpenGL|ES correctness via an extension pack... although how that'll pan out is anyone's guess.

This topic is closed to new replies.

Advertisement