I go away for a few weeks to focus on shipping Windows 10 and then all these posts appear... time to catch up
.
DX12 calls it VPAndRTArrayIndexFromAnyShaderFeedingRasterizerSupportedWithoutGSEmulation
Choose yourself whether you use the OpenGL extension name or the most awesome ever DX12 name. But choose wisely
A developer on my team likes being very specific with names when a capability is difficult to explain. In this case it's always legal to use the feature in pre-rasterizer shader stages. This cap indicates when a hidden GS is not instantiated to implement the functionality, it's a performance hint cap effectively.
Yes Maxwell 2 has stuff that goes above and beyond like the ability to "add" some attributes in GS but pass others through, and as you note the ability to multicast to several viewports. But I still thought that most NVIDIA hardware should be able to support the DX12 feature as-is, not just Maxwell 2, right? Guess it's probably just a driver thing.
Then again if everyone supports it, not sure why we need the cap bit
As mentioned, all 12 drivers support the shader language feature but the cap bit indicates whether the GS is actually used. The cap is useful when an engine has an alternate rendering path that avoids the RT/VP Index for better performance.
All the confusion, including
the clarifying statement on Guru3D, stems from the fact that UAVs in every stage were tied with increased UAV slot count in Direct3D 11.1 and were not made two separate optional features on feature level 11_0 - and whatever reasons Microsoft had for enforcing this requirement, they do not seem to be valid for current Direct3D 12 hardware anymore....
IIRC, the reason these were tied together has nothing to do with hardware support or business objectives. An interesting detail about adding rendering features to Direct3D is my team typically spends more time implementing hardware/driver conformance tests than we do adding feature support to the API itself. We were squeezing everything we could into our schedule for Windows 8 and the way we could fit this feature in was simplifying the test matrix. Or maybe I'm remembering a different feature....
Unrelated to this specific feature, but there are restrictions in Tier 1/Tier 2 that do not correspond to anything from hardware that I know of from the "main three" desktop GPU vendors. Speculate away
Direct3D is designed to consider a number of different hardware vendors' GPUs, some not in the announced Direct3D 12 partners of AMD, Intel, NVidia, and Qualcomm. It's just good business to support a wide variety of hardware that could potentially be used in a member of the Windows OS product family. Direct3D of course considers multiple generations of GPU design from each vendor as well.
All three desktop vendors also make mobile graphics parts though, so I don't think Qualcomm, ARM or PowerVR really need to make some vital contributions...
There are aspects of the Direct3D 12 design that are difficult to rationalize across all the different vendors and generations of GPU. It was important to consider all our partners' GPUs in the design process.
I believe it was time to market issue, rather that a message to drop the mobile support. ASTC has odd block sizes so combining it with advanced features such as tiled resources and volume textures (and volume tiled resources) requires some extra thought.
It wasn't a design related issue, we had to postpone for a different reason. ASTC should be back in the product at a later time.
Yes, those Microsoft documents describe only ASTC LDR profile formats and tile sizes. ASTC Full Profile includes HDR formats and 3d tile sizes (for 3d textures).
My team is following the same implementation pattern as hardware vendors where LDR is coming out first, with HDR and 3D to follow later.
Max McMullen
Direct3D Development Lead
Microsoft
