[llvm] [DirectX] Add DXIL_MODULE_FLAG for ShaderFlags. (PR #83217)
Tex Riddell via llvm-commits
llvm-commits at lists.llvm.org
Wed Mar 6 14:20:03 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:
I'm not sure that's solving the issue. I'm trying to think about a breakdown design that results in consistent terminology, and exposes the important distinctions.
What do you think of this?
Terminology:
1. "DXIL Module Flags" - flag values used in DXIL metadata - could these be called "DXIL Shader Flags"?
2. "Shader Feature Flags" - flags used in shader feature info (SFI0) part and FeatureInfo fields in RDAT part - Could we call these "Shader Feature Info Flags"? It's a bit longer, but clarifies their connection with something more specific.
3. Option flags - we could refer to these simply as "Option Flags". These are a subset of "DXIL Shader Flags".
4. Computed flags - we could refer to these as "Computed Shader Flags". These are a subset of "DXIL Shader Flags", most of which are reflected directly into Shader Feature Info flags, some indirectly (like min-precision), and some not at all.
With this terminology, we could use three different macros for defining the flags:
1. `SHADER_FEATURE_INFO_FLAG` - also defines corresponding `DXIL_SHADER_COMPUTED_FLAG` bit for ones with 1:1 correspondence (not requiring that separate declaration, like it is now), otherwise -1. If -1, we need another way to compute this flag from the DXIL Shader Flags. If we allowed an expression to be supplied (perhaps with a different variant of the macro), it could be computed using that expression. This could solve the min-precision and low-precision feature flag cases.
2. `DXIL_SHADER_OPTION_FLAG` - option flag, not computed from usage. Copied from module when initializing flags for computation per-function, compared when checking linking compatibility, etc... Flags could be module scope or per-function or entry point scope if needed.
3. `DXIL_SHADER_COMPUTED_FLAG` - for additional computed flags that do not have 1:1 correspondence to `SHADER_FEATURE_INFO_FLAG`.
Potential definition for the `SHADER_FEATURE_INFO_FLAG` variant computed from DXIL shader flags with expression:
```
// SHADER_FEATURE_FLAG2(bit offset for the shader info flag, expression based on DXIL shader flags, name, description)
#ifndef SHADER_FEATURE_INFO_FLAG2
#define SHADER_FEATURE_INFO_FLAG2(FeatureInfoBit, ShaderFlagExpr, FlagName, Str) \
SHADER_FEATURE_INFO_FLAG(FeatureInfoBit, -1, FlagName, Str)
#endif
```
Maybe these should all be defined in a TableGen file instead. What do you think about that?
https://github.com/llvm/llvm-project/pull/83217
More information about the llvm-commits
mailing list