Direct3D 12 documentation is now public

[This documentation is preliminary and is subject to change.]

This should be highlighted.

Anyway, please note that the documentation is also incomplete and contains some mistakes (eg: resource binding tiers), and some additions are coming too.

Thank you!

EDIT, so this post is not completely useless: Let's see who draws the first triangle on D3D12. :)

Thanks for posting this.

After reading the documentation a little, I noticed on the Direct3D 12 programming environment set up page they state "The Direct3D 12 headers and libraries are part of the Windows 10 SDK".

I did a little digging and it turns out Microsoft quietly released a preview version of D3D12 with the "Windows SDK for Windows 10", available at step 3 of the instructions here.

The build date on the installed D3D12.h/D3D12.lib is 13th March.

The Windows SDK is for build 10041, so you probably need the matching Win10 Tech Preview build 10041 to go with it (available here ). I haven't installed VS2015 CTP6 yet to verify D3D12 apps can build/debug correctly, but it certainly appears you can start writing/building/debugging D3D12 projects right now. Note you probably also need a WDDM 2.0 graphics driver installed to run/debug D3D12 applications (dxdiag in win10 to check WDDM version).

UPDATE:

It looks like you only need to install "Visual Studio Tools for Windows 10 Technical Preview", rather than the Windows SDK, to get the D3D12 headers. The tools download also includes the sdklayer and warp driver. The Windows SDK appears unnecessary.

So the install order is: Windows 10 Technical Preview, VS 2015 CT6, then Visual Studio Tools for Windows 10 Technical Preview. That's all you need to start building D3D12 apps. You also don't require a WDDM 2.0 graphics card to get started, although the D3D12 warp driver will get pretty slow with any heavy workloads.

WDDM 2.0 drivers should be available through Windows Update (at least for AMD GPus), however driver status is still a "work in progress": Some features may not work correctly or may not work at all as far I tested.

A quick confirmation/update on my earlier post. You can indeed build and run applications that use the D3D12 header/lib installed with the Windows SDK for Windows 10, by using VS2015 CTP6, on Windows 10 Tech Preview March Update (build 10041).

The Windows SDK only installs the headers/libs, but not the debug runtime, so a really important addition worth getting is the "Visual Studio Tools for Windows 10 Technical Preview" from the same page I linked for the Windows SDK (it's the download above the SDK on that page). That will install the D3D12 debug layer (and warp driver etc.), which is incredibly useful considering the WIP nature of the documentation.

The docs are a bit patchy, as Alessio1989 was good to point out, but it seems the outdated parts of the docs aren't too bad to correct for, using the newer reference section of the docs or the installed header definitions, from the half hour I've spent so far. Enough to create a valid device, swapchain, and command queue/list, at least.

See the updated post #4.

Is there any list of hardware that can run dx12?

Is there any list of hardware that can run dx12?

AMD GCN 1.0 and beyond (no VLIW4/5 GPUs)

Intel Haswell and beyond (no Sandy/Ivy bridge GPUs)

NVIDIA Kepler and beyond (support for Fermi GPUs is pending for a future driver release).

Hybrid notebook systems should not be currently supported (again, support is pending for a future driver release).

Is there any list of hardware that can run dx12?

AMD GCN 1.0 and beyond (no VLIW4/5 GPUs)

Intel Haswell and beyond (no Sandy/Ivy bridge GPUs)

NVIDIA Kepler and beyond (support for Fermi GPUs is pending for a future driver release).

Hybrid notebook systems should not be currently supported (again, support is pending for a future driver release).

Just to clarify the hybrid graphics issues, it can happen on desktop too if you have your integrated gpu enabled. So if you have, for example, an intel i5/i7 with a hd4600 and a Geforce 770, you can only use the intel gpu to create a d3d12 device. If you try with the discrete gpu it will fail.

So in order to use your discrete gpu, you need to disable the integrated GPU first (from bios for example). The problem is that on laptops, it may be impossible to do. I have a 980m and I can only use the HD4600 that comes with the CPU :P

Hybrid notebook systems should not be currently supported

That's sad. I hope D3D_DRIVER_TYPE_REFERENCE is implemented.

Is there any list of hardware that can run dx12?

The WARP driver. Does it still exist?

The Windows SDK only installs the headers/libs, but not the debug runtime, so a really important addition worth getting is the "Visual Studio Tools for Windows 10 Technical Preview" from the same page I linked for the Windows SDK (it's the download above the SDK on that page). That will install the D3D12 debug layer (and warp driver etc.), which is incredibly useful considering the WIP nature of the documentation.

Apparently, yes.

That's sad. I hope D3D_DRIVER_TYPE_REFERENCE is implemented.

Not really. D3D_DRIVER_TYPE_WARP is the next best better (if not even the same) thing.

Hybrid notebook systems should not be currently supported

That's sad. I hope D3D_DRIVER_TYPE_REFERENCE is implemented.

You should give a try to WARP, at least it is feasible to get some small demos that are not only a yellow triangle into a blue window.

I would not be surprised if MS decided to roundhouse kick the reference driver...

I would not be surprised if MS decided to roundhouse kick the reference driver...

Don't know - the reference driver may be more useful on the driver side. Remember it's a reference, not a generic soft rast. It exists to be a stable basis of comparison.

Yes, however have a look a the dxcapsviewer: the WARP driver has a better support to optional features compared to the reference driver, it's not only a lot faster. With the WARP driver you can test code that does not run on you GPUs if do not have the last piece of hardware available on the market.
Also, I honestly do not know where the reference driver provides better and more accurate results.

I would not be surprised if MS decided to roundhouse kick the reference driver...

I really doubt that they would do that, it's very useful for verification.

The reference driver is heavily instrumented to help debugging and tracing, whereas the WARP driver isn't.

As with all software, heavy instrumentation and high performance tend to fight each other, because accurate instrumentation makes some optimizations impossible.

One could think that the WARP is the "release build" and REF is the "debug build". In reality, the difference is probably larger than this, though. Despite having connections to MS, I haven't seen the source code to either of them lately.

They probably won't "roundhouse kick" it, because it's still needed for backwards compatibility with older versions of D3D (including the lower Feature Levels in D3D12).

Debug/Release has nothing to do with this. They both support the Debug layer. The reference driver is probably also what they send to hardware manufacturers as example of driver implementations... The WARP driver is simply an implementation of the reference driver optimized to use SIMD/SSE, and I think it's used with Store apps when there is no hardware acceleration available.

Probably.

In fact, MSDN has this to say:

Because WARP uses the same software interface to Direct3D as the reference rasterizer does, any Direct3D 10 or 10.1 application that can support running with the reference rasterizer can be tested by using WARP. To use WARP, rename D3d10warp.dll to D3d10ref.dll and place it in the same folder as the sample or application. Next, when you switch to ref, you will see WARP rendering.

But the only good reason they can't drop the reference rasterizer is probably ( ) because officially Microsoft only requires that SSE is supported by the CPU for 64-bit versions of Windows. The 32-bit Widnows can still be installed on machines without SSE (or even MMX?), and there the WARP driver cannot be used.

Of course, we can all just take a look at (and test) D3D12CreateDevice to see what it supports.

I checked out the reference driver with D3D12, and there is no support for it, only warp/hardware. Trying to use D3D_DRIVER_TYPE_REFERENCE greets you with the output:

DX ERROR: D3D12CreateDevice: Unsupported DriverType specified. D3D12 only supports hardware and WARP devices. [ INITIALIZATION ERROR #506: ]

I had a proper go at getting something onscreen today, by roughly following the instructions on the Creating a basic Direct3D 12 component page of the documentation. It seems like it omits some useful things like how to use fences (kinda required when using a single command allocator), and a few other parts which tripped me up a bit (can't set RTV descriptor heap on a GPU command list as the page sort-of suggests you would). In the end I got the gist of that page working - clearing the back buffer to a specific color every frame without any fatal D3D12 debug layer errors.

I can upload the project (it's a single cpp file) if anyone is interested.

I still have one non-fatal error when SwapChain->Present(1,0) is called, where Present seems to preempt/ignore the executed command list's final resource barrier that transitions the back buffer state from D3D12_RESOURCE_USAGE_RENDER_TARGET (0x4) to a state of D3D12_RESOURCE_USAGE_PRESENT (0x800). The debug layer reports:

D3D12 ERROR: IDXGISwapChain::Present: Resource state (0x0) of resource (0x005FF178 Debug Object Name: mRenderTarget0) (subresource: 0) does not match the required resource state (0x800) for use as a: PRESENT_SOURCE. [ EXECUTION ERROR #534: INVALID_SUBRESOURCE_STATE]

It's a non-fatal error because present overrides whatever state it sees the resource in and forces it to USAGE_PRESENT, according to the docs. All the same I'd like to correct it, so if anyone has any experience with that error I'd be grateful.

Over the weekend I'm going to work on getting some VS/PS shaders working, rather than simply clearing the backbuffer to different colours. It certainly interesting to figure out this new API.

I checked out the reference driver with D3D12, and there is no support for it, only warp/hardware. Trying to use D3D_DRIVER_TYPE_REFERENCE greets you with the output:

DX ERROR: D3D12CreateDevice: Unsupported DriverType specified. D3D12 only supports hardware and WARP devices. [ INITIALIZATION ERROR #506: ]

I had a proper go at getting something onscreen today, by roughly following the instructions on the Creating a basic Direct3D 12 component page of the documentation. It seems like it omits some useful things like how to use fences (kinda required when using a single command allocator), and a few other parts which tripped me up a bit (can't set RTV descriptor heap on a GPU command list as the page sort-of suggests you would). In the end I got the gist of that page working - clearing the back buffer to a specific color every frame without any fatal D3D12 debug layer errors.

I can upload the project (it's a single cpp file) if anyone is interested.

I still have one non-fatal error when SwapChain->Present(1,0) is called, where Present seems to preempt/ignore the executed command list's final resource barrier that transitions the back buffer state from D3D12_RESOURCE_USAGE_RENDER_TARGET (0x4) to a state of D3D12_RESOURCE_USAGE_PRESENT (0x800). The debug layer reports:

D3D12 ERROR: IDXGISwapChain::Present: Resource state (0x0) of resource (0x005FF178 Debug Object Name: mRenderTarget0) (subresource: 0) does not match the required resource state (0x800) for use as a: PRESENT_SOURCE. [ EXECUTION ERROR #534: INVALID_SUBRESOURCE_STATE]

It's a non-fatal error because present overrides whatever state it sees the resource in and forces it to USAGE_PRESENT, according to the docs. All the same I'd like to correct it, so if anyone has any experience with that error I'd be grateful.

Over the weekend I'm going to work on getting some VS/PS shaders working, rather than simply clearing the backbuffer to different colours. It certainly interesting to figure out this new API.

By any chance, did you pass a D3D12CommandQueue as first parameter for the SwapChain creation instead of a device? like...

D3D12CommandQueue* d3dQueue = ...;     

HRESULT hr = dxgiFactory->CreateSwapChain(d3dQueue, &descSwapChain, &dxgiSwapChain);

Because in the new D3D12 SDK, the first parameter should be a D3D12CommandQueue, instead of a ID3D12Device.

It took me a couple of days to find out why I got that weird bug (but no warning nor error during the swap chain creation), but once I fixed that everything start to work fin :).

I really doubt that they would do that, it's very useful for verification.

The big trick here though is that it isn't very good at reproducing threading issues. Since the reference device is so CPU heavy, any threading issues you are having can look like driver issues that disappear on the reference device...

Still though, I completely agree that it is extremely useful for validation of anything not related to threading / timing.