Direct3D feature levels discussion

Alessio1989 said:
edit: just ntried with 17.4.2 (first AMD drivers marked as "WDDM 2.2"): no changes.
edit2: enabling experimental mode for shader model, both o my AMD GPUs, a GCN1 and a GCN3, reports SM6 support.
Click to expand...

Doesn't work for me. Installed 17.4.2 (driver 22.19.157.3) and enabled the Developer Mode - the call to D3D12EnableExperimentalFeatures()goes successfully, but my 290X (GCN2) still reports SM 5.1 as the highest supported model, and the Microsoft Basic Render Driver fails creating a Direct3D 12 device with 80004005 "Unspecified error".
 
Did you called it before creating the d3d12device?
I also used a ID3D12Device2 interface instead of a ID3D12Device1 or a ID3D12Device.
 
Oh. I stand corrected: when enabled after calling D3D12CreateDevice, the behavior is as described above; and if enabled before D3D12CreateDevice(), then both R9 290X and WARP12 return an "unspecified error".
Using ID3D12Device2 does not make any difference.
 
he
DmitryKo said:
Oh. I stand corrected: when enabled after calling D3D12CreateDevice, the behavior is as described above; and if enabled before D3D12CreateDevice(), then both R9 290X and WARP12 return an "unspecified error".
Using ID3D12Device2 does not make any difference.
Click to expand...
here's my code: https://gist.github.com/alessiot89/555afad08337d6f1658e9c2436e40b58

Be sure to call

D3D12EnableExperimentalFeatures( 1U, &D3D12ExperimentalShaderModels, NULL, 0U )

with null values for the last 2 arguments.
 
Last edited:
Thanks for posting your code Alessio, here's the output for pascal if anyone was wondering.

Nothing too surprising - programmable sample position is tier 2, and all of the command queue priorities are supported. Driver shader caching is the same as you got with GCN, support for single pso and libraries, but no support for either of the automatic flags.

I try to keep up with this thread as a lurker, but this was the first time I'd heard of these new automatic flags, I must've missed that. It looks like they're planning to move shader caching out of the vendor's drivers and instead let the OS handle it. I can see why they might want to shift that responsibility to the OS, but I'm a bit puzzled why as a developer I'd ever need to query whether it's the driver or OS managing the shader cache though.
 

Attachments

  • pascal_d3d12experimental.txt
    3 KB · Views: 11
I can't seem to edit that last post, but I was being retarded. Don't post when you've just woken up!

I think that I totally misunderstood what the shader_cache_support_automatic_ flags are about regarding driver vs OS caching of shader data. I can't post links here, but checking the msdn page for D3D12_SHADER_CACHE_SUPPORT_FLAGS, it looks like it's just some automation of the D3D12_CACHED_PIPELINE_STATE member of pso descs. Now it makes a lot more sense why you can query support for them - if the driver supports the OS level caching, particularly the automatic disk cache, then you wouldn't need to implement your own pso caching between runs. That's actually pretty useful to know. I'll go back to lurking now.
 
On my home PC I've been able to get entire programs up and running on SM6.0 running on my GTX 1070, but I haven't yet tried any of the new wave-level intrinsics. I also have a RX 460 in the same PC which reports that it supports SM6.0, however the driver crashes when creating a PSO containing SM6.0 bytecode. ¯\_(ツ)_/¯
 
Alessio1989 said:
here's my code
Click to expand...
No change - an exception is thrown by D3D12CreateDevice() if you invoke D3D12EnableExperimentalFeatures() in advance; otherwise, shader model 5_1 is reported.
Probably some driver bug or OS upgrade issue, will try to reset my Windows installation once again...
PS. Nope, reinstalling the OS and clean installing the video driver did not help.
 
Last edited:
BTW you need to modify your code for skipping adapters that fail D3D12CreateDevice, or there will be access violations in the Release build configuration and "vector iterator not incrementable" exceptions in the Debug build configuration. This is because vector<T>::erase() reallocates the memory and invalidates iterators, pointers and references for all objects at the current position and beyond, and returns an iterator pointing to the new location of the next element, which you should use to continue iterating.
You can rework the while cycle to use an integer index with a forward iterator: auto it = std::next(adapters.begin(), index);
 
Last edited:
DmitryKo said:
No change - an exception is thrown by D3D12CreateDevice() if you invoke D3D12EnableExperimentalFeatures() in advance; otherwise, shader model 5_1 is reported.
Probably some driver bug or OS upgrade issue, will try to reset my Windows installation once again...
PS. Nope, reinstalling the OS and clean installing the video driver did not help.
Click to expand...
Be sure the graphics tools are correctly installed , including to the last version related to the windows SDK (15063). you can verify the installed packages with

Dism /online /get-packages

Try also

Dism /online /add-capability /capabilityname:Tools.Graphics.DirectX~~~~0.0.1.0

DmitryKo said:
BTW you need to modify your code for skipping adapters that fail D3D12CreateDevice, or there will be access violations in the Release build configuration and "vector iterator not incrementable" exceptions in the Debug build configuration. This is because vector<T>::erase() reallocates the memory and invalidates iterators, pointers and references for all objects at the current position and beyond, and returns an iterator pointing to the new location of the next element, which you should use to continue iterating.
You can rework the while cycle to use an integer index with a forward iterator: auto it = std::next(adapters.begin(), index);
Click to expand...

oops!

corrected. https://gist.github.com/alessiot89/555afad08337d6f1658e9c2436e40b58
 
Last edited:
myshkinbob said:
Thanks for posting your code Alessio, here's the output for pascal if anyone was wondering.

Nothing too surprising - programmable sample position is tier 2, and all of the command queue priorities are supported. Driver shader caching is the same as you got with GCN, support for single pso and libraries, but no support for either of the automatic flags.

I try to keep up with this thread as a lurker, but this was the first time I'd heard of these new automatic flags, I must've missed that. It looks like they're planning to move shader caching out of the vendor's drivers and instead let the OS handle it. I can see why they might want to shift that responsibility to the OS, but I'm a bit puzzled why as a developer I'd ever need to query whether it's the driver or OS managing the shader cache though.
Click to expand...

Interesting, the Pascal architecture allows the driver to create a "realtime" priority queue for the default command buffers queue. But I also do not understand how much could be useful if current hardware/APIs allow/have only one default queue. Maybe in the future we will have silicon with cooler scheduling features :D
 
Alessio1989 said:
Be sure the graphics tools are correctly installed, including to the last version related to the windows SDK (15063)
you can verify the installed packages with Dism /online /get-packages
Click to expand...
The catch is, it only works with the x64 target platform, and not the x86 platform. Huh!
Doesn't really require ID3D12Device2 though, unlike what MSDN says.


BTW the OS upgrade didn't properly remove the previous version of the graphics tools:
Microsoft-OneCore-Graphics-Tools-Core-Package~31bf3856ad364e35~amd64~~10.0.14393.0
Microsoft-OneCore-Graphics-Tools-Core-Package~31bf3856ad364e35~x86~~10.0.14393.0
Microsoft-OneCore-Graphics-Tools-Package~31bf3856ad364e35~amd64~~10.0.15063.0
Click to expand...
 
Last edited:
I did not notice it since I usually build x64 projects only.
Well, the removal of ia32 support has been a long time coming, though I did not read any official statement about that.


EDIT: probably the previous graphics tools were not removed since you may require them for 32-bit code.
 
Last edited:
I assume it's just a bug in the Developer Mode library.

Support for x86 executables is definitely NOT being removed, and won't be any time soon. The x86 platform is fully supported for both UWP and Desktop applications going forward, including those targeting Windows Store.

And even when there is no separate x86 package for some feature, amd64 (x64) packages also include user-mode x86 components for WOW64 emulation.


As for the 'OneCore-Graphics-Tools-Core-Package', it's actually not an OS component but rather the VS2015 / VS2017 'Graphics Diagnostics' toolset, so it's not related to WARP12 which ships in the 'OneCore-Graphics-Tools-Package' a.k.a the 'Graphics Tools' for Windows 10.
 
Last edited:
Understood... This is also a clear example how Microsoft nomenclature sometimes is complete mess.

Also trying to install or just obtain some information about the x86 package results in 0x800f0805 (ie: invalid package name) :\
 
You mean the 'Graphics Diagnostics' tools from Visual Studio? You can find the x86 package in the VS 2017 directory: C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\Microsoft\Graphics\Debugger\Windows\x86\Microsoft-OneCore-Graphics-Tools-Core-Package.cab
 
Alessio1989 said:
I mean the OS x86 package (the "on-demand" package on dism)
Click to expand...
As I said above, an amd64 package will serve both x64 and x86 subsystems , so there is no separate x86-only package bundled with a x64 OS.
In general, x86-only packages are used for an x86 distribution of Windows or for some legacy Win32 technologies not ported to the 64-bit platform.

Download HLK_GRFX_FOD.zip (Windows 10, version 1703) ('Additional Windows Supplemental HLK Content' in Windows Hardware Lab Kit) and open the 'Microsoft-OneCore-Graphics-Tools-Package.CAB' file in the 'Tests\Desktop\x64' folder - there are two copies of each file and folder, for both x86 and amd64 platforms.
 
Last edited:
You must log in or register to reply here.
Back
Top