There are two major differences: first, the D3D12Core component of the OS will be serviced by Windows Update to automatically include the latest released version (while this particular OS remains supported); second, developers only need to declare two export symbols in the executable file (which specify the minimum supported SDK version and the path to the redistributable D3D12Core.dll), while the D3D12.dll thunk library should automatically load the latest available version of D3D12Core.This is more or less similar to how MS has provided D3D12 support on Win7 for some games I'd say.
that's looks reasonable... in before devs discover they still continue to use absolute paths when asking about dlls (lol jokin.. but that happened a lot of time in the past!)second, developers only need to declare two export symbols in the executable file (which specify the minimum supported SDK version and the path to the redistributable D3D12Core.dll). while the d3d12.dll thunk library should automatically load the latest available version of D3D12Core.
I will look into supporting D3D12Core, so people could test new video driver features without installing Insider Preview builds. I need to check if the redistributable D3D12Core.dll has to be included with the executable at all times, or the D3D12.dll thunk will substitute the version that comes with the downlevel OS...
There are several servicing strategies - they can either 'force-upgrade' to the latest SDK version, or make a service release for the same SDK version of the redistributable D3D12Core.dll - I guess this will be decided on a case-by-case basis, according to specific feature requests from major publishers.there will be too many OS-DX runtime versions combo support and that is not good that some dll cannot updated and controlled by their OS... And in before more driver madness... and DXGI compatibility issues
Where do you post your files DmitryKo? Directly embedded here on B3D? Is there no GIT? =P Your tool is maturing quite a bit beyond the scope of its original intention. On github others may pool in to expand on itMeanwhile, I've made a minor update to my Direct3D12 Feature Checker tool to report new options in the Direct3D 12 Agile SDK headers, which are currently the same as Insider Preview 'Cobalt'.
I don't normally scrutinize these quotes, but the way NVIDIA and AMD are phrasing their support is wildly different!
NVIDIA has been working with Microsoft to empower game developers with DirectX 12 Ultimate through the introduction of Mesh Shading, Variable Rate Shading, Sampler Feedback, and DirectX Raytracing.
AMD’s RDNA™ 2 graphics architecture fully supports DirectX® 12 Ultimate and is available on a broad spectrum of hardware, including Xbox Series X|S and AMD Radeon™ RX 6000 Series graphics cards
Considering that NVIDIA is including Sampler Feedback, feature that had to be scaled down to "0.9" so it would work with NVIDIA, I'd say it's safe to say it's just the way they want to talk.I don't normally scrutinize these quotes, but the way NVIDIA and AMD are phrasing their support is wildly different!
NVIDIA is bolder, bragging about working with Microsoft to introduce Mesh Shaders, Variable Rate Shading and Ray Tracing.
While AMD is more casual about it, citing support, nothing more.
One is phrasing their words as if they influenced the making of DX12U, while the other is just casually stating widespread support.
Does this mean anything? Or is it just a figure of speech? I don't know.
That's just the way you want to think, as for facts, nvidia introduced all these features years before MS in NVAPI and Vulkan extensions, so there is no way they couldn't have influenced Microsoft's API development.Considering that NVIDIA is including Sampler Feedback, feature that had to be scaled down to "0.9" so it would work with NVIDIA, I'd say it's safe to say it's just the way they want to talk.
0.9 SF tier lacks support for some obscure texture formats AFAIU. You can just as easily say that MS has decided to name that "0.9" because the main target for the feature was their XSX GPU - which supports SF for such formats.Considering that NVIDIA is including Sampler Feedback, feature that had to be scaled down to "0.9" so it would work with NVIDIA, I'd say it's safe to say it's just the way they want to talk.
No-one said or even remotely suggested NVIDIA didn't influence Microsoft API development, of course they did, just like AMD, Intel, Qualcomm and probably others did too.That's just the way you want to think, as for facts, nvidia introduced all these features years before MS in NVAPI and Vulkan extensions, so there is no way they couldn't have influenced Microsoft's API development.
The real widespread hardware support on PC is also all about Turing and Ampere GPUs, market share of RDNA2 in PC space is obviously statistically insignificant in comparison.
https://microsoft.github.io/DirectX-Specs/d3d/SamplerFeedback.html0.9 SF tier lacks support for some obscure texture formats AFAIU. You can just as easily say that MS has decided to name that "0.9" because the main target for the feature was their XSX GPU - which supports SF for such formats.
I think it's a weird choice of naming on MS's part as a 1.0 and 1.1 would be a better fit here probably. 0.9 makes it look like the feature isn't support - which isn't correct.
We don't know the logic behind this naming, so there are no facts why it was named 0.9.That doesn't change the fact that NVIDIAs Texture Space Shading isn't capable of everything what Microsoft wanted for Sampler Feedback, which is why it's not Tier 1 but 0.9.
It's a separate entity because MS has a plenty of low level stuff there not exposed on PC.You shouldn't view DirectX/Direct3D as just PC only, either, since Xbox is very much part of the process instead of separate entity with it's own APIs,
There are not, the only meaningful restrictions are address modes, other restrictions don't matter much.There seems to be quite a lot of restrictions in 0.9 to make it work other than "support for obscure texture formats" according to that.
https://microsoft.github.io/DirectX-Specs/d3d/SamplerFeedback.html
There seems to be quite a lot of restrictions in 0.9 to make it work other than "support for obscure texture formats" according to that.
It seems more likely MS agreed to implent 0.9 for NVIDIA because of their market share with hardware supporting all the rest of DX12U, rather than just bad naming.
Before if you couldn't meet everything some feature required, you didn't support it, end of story. IIRC there has been plenty of cases where hardware x meets most of feature y's requirements, but not all, and end up not supporting the feature because of it.
https://microsoft.github.io/DirectX-Specs/d3d/SamplerFeedback.html
There seems to be quite a lot of restrictions in 0.9 to make it work other than "support for obscure texture formats" according to that.
It seems more likely MS agreed to implent 0.9 for NVIDIA because of their market share with hardware supporting all the rest of DX12U, rather than just bad naming.
Before if you couldn't meet everything some feature required, you didn't support it, end of story. IIRC there has been plenty of cases where hardware x meets most of feature y's requirements, but not all, and end up not supporting the feature because of it.
It puzzles me then why Nvidia hasn't catched up to SF Tier 1.0 with Ampere. Seems like this feature will remain to play a subordinate role for a long time, or Tier 0.9 will be good enough.
Splitting the user base on such minor feature wouldn't be of any help to anyone I'd imagine.It puzzles me then why Nvidia hasn't catched up to SF Tier 1.0 with Ampere.
Playing the devil's advocate here: It's entirely possible for a company to slow the adoption of a feature via such devices until said feature does not hurt their performance as much as it might do now. That's much more subtle than not to support it in the first place or to say "yes we support it, but please do not use it/use it only in small doses".Splitting the user base on such minor feature wouldn't be of any help to anyone I'd imagine.
This makes no sense as the company in question has actually introduced the feature in the first place.Playing the devil's advocate here: It's entirely possible for a company to slow the adoption of a feature via such devices until said feature does not hurt their performance as much as it might do now. That's much more subtle than not to support it in the first place or to say "yes we support it, but please do not use it/use it only in small doses".
No idea, if that's the case here and if so, how they got M$ to play along, but I think it's entirely possible.