[llvm] [DirectX] Add DXIL_MODULE_FLAG for ShaderFlags. (PR #83217)

Tex Riddell via llvm-commits llvm-commits at lists.llvm.org
Tue Mar 5 16:55:18 PST 2024


================
@@ -13,43 +13,58 @@ CONTAINER_PART(PSG1)
 
 #ifdef SHADER_FEATURE_FLAG
 
-SHADER_FEATURE_FLAG(0, Doubles, "Double-precision floating point")
-SHADER_FEATURE_FLAG(1, ComputeShadersPlusRawAndStructuredBuffers, "Raw and Structured buffers")
-SHADER_FEATURE_FLAG(2, UAVsAtEveryStage, "UAVs at every shader stage")
-SHADER_FEATURE_FLAG(3, Max64UAVs, "64 UAV slots")
-SHADER_FEATURE_FLAG(4, MinimumPrecision, "Minimum-precision data types")
-SHADER_FEATURE_FLAG(5, DX11_1_DoubleExtensions, "Double-precision extensions for 11.1")
-SHADER_FEATURE_FLAG(6, DX11_1_ShaderExtensions, "Shader extensions for 11.1")
-SHADER_FEATURE_FLAG(7, LEVEL9ComparisonFiltering, "Comparison filtering for feature level 9")
-SHADER_FEATURE_FLAG(8, TiledResources, "Tiled resources")
-SHADER_FEATURE_FLAG(9, StencilRef, "PS Output Stencil Ref")
-SHADER_FEATURE_FLAG(10, InnerCoverage, "PS Inner Coverage")
-SHADER_FEATURE_FLAG(11, TypedUAVLoadAdditionalFormats, "Typed UAV Load Additional Formats")
-SHADER_FEATURE_FLAG(12, ROVs, "Raster Ordered UAVs")
-SHADER_FEATURE_FLAG(13, ViewportAndRTArrayIndexFromAnyShaderFeedingRasterizer, "SV_RenderTargetArrayIndex or SV_ViewportArrayIndex from any shader feeding rasterizer")
-SHADER_FEATURE_FLAG(14, WaveOps, "Wave level operations")
-SHADER_FEATURE_FLAG(15, Int64Ops, "64-Bit integer")
-SHADER_FEATURE_FLAG(16, ViewID, "View Instancing")
-SHADER_FEATURE_FLAG(17, Barycentrics, "Barycentrics")
-SHADER_FEATURE_FLAG(18, NativeLowPrecision, "Use native low precision")
-SHADER_FEATURE_FLAG(19, ShadingRate, "Shading Rate")
-SHADER_FEATURE_FLAG(20, Raytracing_Tier_1_1, "Raytracing tier 1.1 features")
-SHADER_FEATURE_FLAG(21, SamplerFeedback, "Sampler feedback")
-SHADER_FEATURE_FLAG(22, AtomicInt64OnTypedResource, "64-bit Atomics on Typed Resources")
-SHADER_FEATURE_FLAG(23, AtomicInt64OnGroupShared, "64-bit Atomics on Group Shared")
-SHADER_FEATURE_FLAG(24, DerivativesInMeshAndAmpShaders, "Derivatives in mesh and amplification shaders")
-SHADER_FEATURE_FLAG(25, ResourceDescriptorHeapIndexing, "Resource descriptor heap indexing")
-SHADER_FEATURE_FLAG(26, SamplerDescriptorHeapIndexing, "Sampler descriptor heap indexing")
-SHADER_FEATURE_FLAG(27, RESERVED, "<RESERVED>")
-SHADER_FEATURE_FLAG(28, AtomicInt64OnHeapResource, "64-bit Atomics on Heap Resources")
-SHADER_FEATURE_FLAG(29, AdvancedTextureOps, "Advanced Texture Ops")
-SHADER_FEATURE_FLAG(30, WriteableMSAATextures, "Writeable MSAA Textures")
-
-SHADER_FEATURE_FLAG(31, NextUnusedBit, "Next reserved shader flag bit (not a flag)")
+// SHADER_FEATURE_FLAG(bit offset for the flag, bit offset for DXIL module flag, name, description.
----------------
tex3d wrote:

`bit offset for the flag` - in what context?  This is the offset in the Shader Feature Info flags (in `SFI0` part) or per-function `FeatureInfo*` flags (in `RDAT` part).  Should this read `bit offset for the shader feature info flag`?

Next, I'm not sure `DXIL module flag` is the right term for all of these, since most of them are computed on a per-function or shader basis, and the resulting feature flags are preserved per-function for libraries in `RDAT`.  These are unioned into module-level shader flags, but they aren't all strictly module flags.  These are previously referred to as the DXIL Shader Flags, with the 64-bit flags value referred to as the raw shader flags.

Some of the flags *are* module-scope flags though, so it would seem we need to clarify the distinctions, or this will just be more confusing.  It would seem important to preserve true module-level flags/settings from CodeGen on, separately from the flags computed based on function usage later.  We should have a term for this subset of flags, separate from the raw shader flags, and something like DXIL module flags or DXIL module settings (if there are more than just flags) would seem appropriate for these.  Grouping them can make it easier to check for consistent settings between modules when linking, for instance.

These flags are part of the shader interface:
- Feature Flags, aka. Shader Feature Info flags encoded into the container's `SFI0` part, or per-function into the `RDAT` part.  This is part of the runtime interface, used to validate required feature support at runtime.  Many, but not all, of these flags have a 1:1 mapping from DxilShaderFlags.
- DXIL Shader Flags: all the flags including module flags and per-function/shader computed flags indicating feature usage.  This is a 64-bit value that is part of the driver interface.  This is what's being referred to as DXIL module flags here.

You could think of DxilShaderFlags as breaking down into:
- Global module flags indicating module interpretation, or allowed optimizations, such as `UseNativeLowPrecision`, `AllResourcesBound`, `DisableMathRefactoring`, etc...  These are set based on compilation options.
- Shader flags computed from functions/entry points or global state (or ComputedShaderFlags):
  - most indicating a required feature flag like most of the flags defined with `SHADER_FEATURE_FLAG` here
  - some potentially indicating something for the driver, without mapping to a required feature bit, such as `ForceEarlyDepthStencil`
  - others potentially indicating usage of a feature in a function that may restrict the context from which that function may be called.

I don't think this explanation gives a definitive answer to how we should clarify our flags terminology and organization, but I don't think we have it quite right at this time.

https://github.com/llvm/llvm-project/pull/83217


More information about the llvm-commits mailing list