Direct3D feature levels discussion

[DmitryKo]

I did a clean install of Win 10 15063 on a notebook with Kaveri A10 7300 two days ago and the latest driver from AMD's site had it on WDDM 2.1. Crimson 17.7.2. Maybe it's a Kaveri thing.

I'm quite sure my laptop with A10 8700P and R7 M360 reported WDDM 2.2 last time I checked.

AMD Radeon Crimson 17.x does support WDDM 2.2 - you can tell by checking the first two digits of the driver version (2.2 is supposedly for Windows Mixed Reality, but the docs are not available yet).

Not sure where DXDiag takes WDDM version from - there are no public APIs to query this, it's just tied to the specific OS release and/or SP level since Windows 7 SP1.

Each successive WDDM iteration offers a few updated DXGK DDI callbacks and expanded structures, and the driver is expected to handle whatever version is available in the current OS environment - that's why there are separate driver packages for Windows 7 (WDDM 1.1), Windows 8.1 (WDDM 1.2/1.3) and Windows 10 (WDDM 2.0/2.1/2.2). But I doubt AMD driver would use separate code paths for very minor chip revisions such as GCN1/2.

 

[swaaye]

AMD Radeon Crimson 17.x does support WDDM 2.2 - you can tell by checking the first two digits of the driver version (2.2 is supposedly for Windows Mixed Reality, but the docs are not available yet).

Not sure where DXDiag takes WDDM version from - there are no public APIs to query WDDM/DXGI level, it's just tied to the specific OS release and/or SP level since Windows 7 SP1.

AFAIK each successive WDDM/DXGI iteration offers a few updated DXGK callbacks, and the driver is expected to just use what is available in the current OS environment. But I doubt AMD driver would use separate code paths for very minor chip revisions such as GCN1/2.

Yeah it was DXDiag that showed WDDM 2.1. I haven't had the notebook for weeks though so can't double check anything.

 

[Ethatron]

Not sure where DXDiag takes WDDM version from - there are no public APIs to query WDDM/DXGI level, it's just tied to the specific OS release and/or SP level since Windows 7 SP1.

There kind of is. Every DXGI version adds new Interface revisions like IDXGIDevice1/2/... (not nessesarily that one but you get the idea). You just query the interface you want to probe for and then you can imply the overall supported version. There is no DXGI version without added functionality that I know of, so you can test for all of them in some [granted] convoluted way.

 

[DmitryKo]

Every DXGI version adds new Interface revisions like IDXGIDevice1/2/...

Yes, but these APIs are for the application programmer, defined in the Windows SDK - and driver development is served by the separate Windows Driver Kit.

WDDM display drivers have a kernel-mode driver - which typically calls the kernel-mode display miniport driver which in turn calls the DirectX graphics kernel (DXGK) - for handling lowest-level tasks such as resource/memory/power management and device I/O, and higher-level tasks like actual rendering and shader processing are done in the user-mode display driver, which talks to Direct3D/DXGI runtime which in turn actually exposes the APIs defined in the SDK.

These low-level C-style DXGK interfaces have nothing in common with "lightweight COM" DXGI interfaces.

it was DXDiag that showed WDDM 2.1

Well, Windows Driver Kit documentation provides some helper functions/structures (in particular D3DKMTOpenAdapterFromLuid() / D3DKMT_OPENADAPTERFROMLUID, D3DKMTQueryAdapterInfo() / D3DKMT_QUERYADAPTERINFO, and D3DKMT_DRIVERVERSION) which are used by the user-mode OpenGL driver to query the display miniport for WDDM version supported by the kernel-mode driver, but I'm not sure if these are callable from desktop/UWP applications (i.e. the Win32 subsystem)... I guess I need to install the WDK and find out.

 

[Ethatron]

... These low-level C-style DXGK interfaces have nothing in common with "lightweight COM" DXGI interfaces. ...

Sorry, maybe this was a typo:

there are no public APIs to query WDDM/DXGI level

I just tried to explain how to "query" the DXGI level.
As I'm not dealing or having dealt or will deal with DXGK or WDDM directly I don't know anything about it, thank you for the information.

 

[DmitryKo]

New in Windows 10 WDK Preview and SDK Preview RS3:

•d3dukmdt.h: New DXGKDDI_INTERFACE_VERSION_WDDM2_3, D3D_UMD_INTERFACE_VERSION_WDDM2_3, D3D_UMD_INTERFACE_VERSION_WDDM2_3_1 ...

•dxgi1_6.h\idl: New DXGI_ADAPTER_FLAG3_SUPPORT_MONITORED_FENCES, DXGI_ADAPTER_FLAG3_SUPPORT_NON_MONITORED_FENCES & DXGI_ADAPTER_FLAG3_KEYED_MUTEX_CONFORMANCE enum values.

•dxgicommon.h\idl: New DXGI_COLOR_SPACE_RGB_STUDIO_G24_NONE_P709, DXGI_COLOR_SPACE_RGB_STUDIO_G24_NONE_P2020, DXGI_COLOR_SPACE_YCBCR_STUDIO_G24_LEFT_P709, DXGI_COLOR_SPACE_YCBCR_STUDIO_G24_LEFT_P2020 & DXGI_COLOR_SPACE_YCBCR_STUDIO_G24_TOPLEFT_P2020 enum values.

•d3d12.h\idl: New ID3D12Fence1, ID3D12GraphicsCommandList2 & ID3D12Device3 interfaces.
New D3D12_MAX_VIEW_INSTANCE_COUNT, D3D12_VIDEO_DECODE_MAX_ARGUMENTS, D3D12_VIDEO_DECODE_STATUS_MACROBLOCKS_AFFECTED_UNKNOWN, D3D12_VIDEO_PROCESS_MAX_FILTERS & D3D12_VIDEO_PROCESS_STEREO_VIEWS defines.
New D3D12_COMMAND_LIST_TYPE_VIDEO_DECODE, D3D12_COMMAND_LIST_TYPE_VIDEO_PROCESS, D3D12_PIPELINE_STATE_SUBOBJECT_TYPE_VIEW_INSTANCING, D3D12_FEATURE_D3D12_OPTIONS3, D3D_SHADER_MODEL_6_1, D3D12_RESOURCE_FLAG_VIDEO_DECODE_REFERENCE_ONLY, D3D12_RESOURCE_STATE_VIDEO_*, D3D12_FENCE_FLAG_NON_MONITORED, D3D12_QUERY_HEAP_TYPE_VIDEO_DECODE_STATISTICS, D3D12_QUERY_HEAP_TYPE_COPY_QUEUE_TIMESTAMP & D3D12_QUERY_TYPE_VIDEO_DECODE_STATISTICS enum values.
New D3D12_VIEW_INSTANCING_TIER, D3D12_COMMAND_LIST_SUPPORT_FLAGS, D3D12_VIEW_INSTANCING_FLAGS & D3D12_WRITEBUFFERIMMEDIATE_MODE enums.
New D3D12_FEATURE_DATA_D3D12_OPTIONS3, D3D12_VIEW_INSTANCE_LOCATION, D3D12_VIEW_INSTANCING_DESC, D3D12_WRITEBUFFERIMMEDIATE_PARAMETER structs.
New function in ID3D12GraphicsCommandList1 interface.

•d3d12video.h\idl: New header file with D3D Video interfaces including ID3D12VideoDecoderHeap, ID3D12VideoDevice, ID3D12VideoDecoder, ID3D12VideoProcessor, ID3D12VideoDecodeCommandList & ID3D12VideoProcessCommandList interfaces.

Preview RS3 SDK is available from https://www.microsoft.com/en-us/software-download/windowsinsiderpreviewSDK

 

[DmitryKo]

maybe this was a typo

I only mentioned DXGI because it is the lowest-level graphics API in Windows SDK and is often cited in tandem with WDDM in "what's new" MSDN docs.

Yes, applications are supposed to query IDXGFactory* for a supported interface rather than perform OS version check or component check, so IDXGIAdapter*.GetDesc* methods do not report WDDM version...

 

[Alessio1989]

So, we are going to have video decoding under Direct3D 12 too?

 

[DmitryKo]

Yes, a new header file d3d12video.h

There is ID3D12VideoDevice->CheckFeatureSupport() method with 12 parameter blocks to query (D3D12_FEATURE_VIDEO enumeration and D3D12_FEATURE_DATA_VIDEO_* structures), but AFAIK they mostly describe supported video decoding formats and decoder parameters, so the support matrix would be enormous... I might add some essential info on the supported video formats but this depends on Microsoft releasing the updated SDK documentation.

 

[DmitryKo]

I have updated my console tool to support D3D12_FEATURE_D3D12_OPTIONS3 and D3D12_FEATURE_EXISTING_HEAPS, available in Windows 10 Fall Creators Update version 1709.

Here's what WARP12 (Microsoft Basic Render Driver) currently reports in Windows 10 RS3 RTM (build 16299):

HighestShaderModel : D3D12_SHADER_MODEL_6_1 (0x0061)
CopyQueueTimestampQueriesSupported : 1
CastingFullyTypedFormatSupported : 1
WriteBufferImmediateSupportFlags : D3D12_COMMAND_LIST_SUPPORT_FLAG_DIRECT | BUNDLE | COMPUTE | COPY | VIDEO_DECODE | VIDEO_PROCESS (63) (0b0011'1111)
ViewInstancingTier : D3D12_VIEW_INSTANCING_TIER_1 (1)
BarycentricsSupported : 0
ExistingHeaps.Supported : 1

Note that WARP12 includes experimental support for Shader Model 6_1, but no support for barycentrics.

 

[Ext3h]

"D3D12_FEATURE_EXISTING_HEAPS", is that what I think it is?

The ability to finally say "map using THAT memory region, stop allocating new memory for my process and running into the the page fault interrupt" and "no, I don't want you to make another copy only so you can claim to be non-blocking at all cost"?

Asking because the performance of the page fault interrupt triggered when a zero-page mapped memory address gets remapped to a real RAM page on first write access (and at least all DX11 map or subresource update methods always give you zero-paged memory, or at least perform an internal copy to such if the GPU isn't by chance idle) caused me a lot of headache.

Inverse performance scaling on systems with too many cores (that's the horrible part, hooray for using a spin lock...), but even in best case I couldn't upload more than 2-3GB / second to the GPU due to overhead from the page faults. Even with a hack like aplying VirtualLock+VirtualUnlock, I still couldn't get beyond 5-8GB / second, still bound by the speed at which the page table could be updated (VirtualLock triggers the mapping from zero page to real RAM eagerly without relying on the interrupt, but it's still somewhat slow).

If that feature flag indicates what I think it does, then uploads at full PCIe 3.0 16x speeds should become possible at last. Tremendously helpful if you want to shovel data from one GPU to the next.

EDIT: Nope, just import functions for pre-baked resource heaps. Has nothing to do with the broken design of the map functions.

 

[Alessio1989]

I really hope so... Let's see how much architectures will support that..

 

[DmitryKo]

This feature is exposed by two new methods, ID3D12Device3::OpenExistingHeapFromAddress and ID3D12Device3::OpenExistingHeapFromFileMapping - not sure if this really does away with copy overhead though...

virtual HRESULT STDMETHODCALLTYPE OpenExistingHeapFromAddress(
_In_  const void *pAddress, REFIID riid, _COM_Outptr_  void **ppvHeap) = 0;

virtual HRESULT STDMETHODCALLTYPE OpenExistingHeapFromFileMapping(
_In_  HANDLE hFileMapping, REFIID riid, _COM_Outptr_  void **ppvHeap) = 0;

 

[Ext3h]

No, doesn't look like it, just an interface to load entire ready-made heaps at once. Once again with a guaranteed copy.

Sorry for getting the hopes up.

 

[DmitryKo]

Anyone with a GeForce 900/1000 series card running Windows 10 Insider Preview build 1629x - would you please install the NVidia 387.xx driver (version 23.21.13.87xx - i.e. WDDM 2.3 support) from the Windows Update and check the new "Direct3D 12.3" features above?

 

[Malo]

Anyone with a GeForce 900/1000 series card running Windows 10 Insider Preview build 1629x - would you please install the NVidia 387.xx driver (version 23.21.13.87xx - i.e. WDDM 2.3 support) from the Windows Update and check the new "Direct3D 12.3" features above?

GeForce 970 on 387.68. Windows Insider Build 16291

CopyQueueTimestampQueriesSupported : 1
CastingFullyTypedFormatSupported : 1
WriteBufferImmediateSupportFlags : D3D12_COMMAND_LIST_SUPPORT_FLAG_DIRECT | BUNDLE | COMPUTE | COPY (15) (0b0000'1111)
ViewInstancingTier : D3D12_VIEW_INSTANCING_TIER_NOT_SUPPORTED (0)
BarycentricsSupported : 0
ExistingHeaps.Supported : 1

 

[DmitryKo]

GeForce 970 on 387.68. Windows Insider Build 16291

Thank you! Could you please check if enabling experimental shader models (checkfeatures_experimental.cmd) makes any difference? What are the highest shader models reported in both cases?

I'm puzzled as to why WARP12 reports SM6_1 in experimental mode but doesn't set the BarycentricsSupported bit in D3D12_OPTIONS3.
As far as I understand, Shader Model 6.1 and DXIL 1.1 support for barycentric coordinates (SV_Barycentric) is unconditional... maybe this cap bit is intended only for SM6.0 code?

 

[Malo]

Do I need to do something to enable it?

Windows 10 version 1709 (build 16291)
Checking for experimental shader models
Failed to enable experimental shader models
Error 80004002: No such interface supported

 

[DmitryKo]

You need to enable the developer mode in Windows settings.

 

[Malo]

Highest shader model is now 6.1 in developer mode

HighestShaderModel : D3D12_SHADER_MODEL_6_1 (0x0061)

CopyQueueTimestampQueriesSupported : 1
CastingFullyTypedFormatSupported : 1
WriteBufferImmediateSupportFlags : D3D12_COMMAND_LIST_SUPPORT_FLAG_DIRECT | BUNDLE | COMPUTE | COPY (15) (0b0000'1111)
ViewInstancingTier : D3D12_VIEW_INSTANCING_TIER_1 (1)
BarycentricsSupported : 0
ExistingHeaps.Supported : 1

ViewInstancingTier now listed as supported as Tier 1 instead of not supported.