Skip to content

Prevent experimental RDAT on released shader targets#8534

Open
tex3d wants to merge 8 commits into
microsoft:mainfrom
tex3d:exp-rdat-exp-sm-vv0
Open

Prevent experimental RDAT on released shader targets#8534
tex3d wants to merge 8 commits into
microsoft:mainfrom
tex3d:exp-rdat-exp-sm-vv0

Conversation

@tex3d

@tex3d tex3d commented Jun 10, 2026

Copy link
Copy Markdown
Contributor

This will prevent experimental RDAT parts from being emitted when compiling to a released shader target, unless you explicitly supply -validator-version 0.0.

  • Add experimental DXIL version detection.
  • Update MaxPartTypeForValVer to require prerelease shader model + experimental validator version or unbound validator version for experimental parts.
  • DxilRDATBuilder: separate Add/Get to avoid on-demand addition of parts to enforce strict versioning.
  • Add max validator version to RDAT_STRUCT_TABLE_DERIVED to automatically set table stride correctly.
  • Add experimental RDAT tests for release and experimental versions.

Fixes #8272

tex3d added 8 commits June 4, 2026 18:41
Separating Add and Get to make sure only supported tables are explicitly added, and to prevent any use of unsupported tables by not adding tables on-demand later. Empty parts will always be culled for serialization.
experimental_rdat.hlsl - test conditions requiring experimental (release+1) support.
experimental_rdat_rel_sm.hlsl - test conditions supported on released version.
Also require prerelease shader model or unbound validator for experimental RDAT data.
Logic for prerelease shader model and unbound validator version moved into MaxPartTypeForValVer, and Builder will return nullptr for GetTable on table that hasn't been added, so base AddShaderInfo on whether a key table in this experimental RDAT is present.
Add minimum validator version to RDAT_STRUCT_TABLE_DERIVED, allowing automatic record versioning (through stride).

@V-FEXrt V-FEXrt left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks reasonable to me but I wouldn't say I'm very fimiliar with RDAT yet so a more experienced review here would be good

#define RECORD_TYPE RuntimeDataFunctionInfo2
RDAT_STRUCT_TABLE_DERIVED(RuntimeDataFunctionInfo2, RuntimeDataFunctionInfo,
FunctionTable)
FunctionTable, 1, 8)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These should use constants right? Otherwise they'll likely be forgetten when the values are updated

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIUC those are already shipped values that can't change, so they are fine to be hard coded.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: New

Development

Successfully merging this pull request may close these issues.

Experimental RDAT parts exposed in released DXIL 1.9

3 participants