0004 - 202x Feature Removals

• Planned Version: 202x
• Issues: #300, #291, #259, #135, LLVM #117715

Note: this proposal was introduced in Microsoft’s hlsl-specs as deprecations. In Ecma the proposal is categorized as removals, because the proposal is to not include these features in the first edition of the specification.

Implementation Status

Introduction

HLSL 2021 supports syntaxes and features that either do nothing, or are potentially confusing. This proposal tracks a set of minimal breaking changes for HLSL to remove misleading or confusing functionality.

Motivation

This proposal is part of a larger effort to reduce carried forward technical debt in HLSL compiler implementations.

Proposed solution

Removal of Effects Syntax

DXC supports parsing much of the legacy FXC effects syntax, however it emits warnings and does not provide any behavior associated with the effects syntax.

In HLSL 202x mode, the effects parsing support should be disabled so that parsing failures generate errors as would otherwise occur in HLSL. Conformant compilers should not support parsing the effects syntax.

Examples of effects syntax

< int foo=1; >
<
  string Name = "texa";
  int ArraySize = 3;
>;

sampler S : register(s1) = sampler_state {texture=tex;};
Texture2D l_tex { state=foo; };

int foobar2 {blah=foo;} = 5;

texture tex1 < int foo=1; > { state=foo; };


technique T0
{
  pass {}
}
Technique
{
  pass {}
}

int foobar5[] {1, 2, 3};
int foobar6[4] {1, 2, 3, 4};

Removal of interface Keyword

DXC supports interface declarations, however the semantic utility of interfaces is limited. Instances of interfaces cannot be created or passed around to functions. They can only be used as a static-verification that all required methods of an object are implemented.

Template-based polymorphic patterns available in HLSL 2021 and later enable many of the code patterns that interface declarations would have previously been used for and should be the supported path going forward.

Conforming implementations will not treat the interface keyword as a reserved word, and will not support any special parsing or semantic handling for interface declarations. Use of the interface keyword as a class-key in the grammar for specifying a declaration shall be rejected and produce a diagnostic.

Removal of uniform Keyword

In DXC the uniform keyword is parsed and ignored. This may lead users to believing it has some impact when it does not. We should remove it.

Conforming implementations will not treat the uniform keyword as a reserved word, and will not support any special parsing or semantic handling for variables with the uniform type attribute applied. Use of the uniform keyword as a keyword attribute on any declaration shall be rejected and produce a diagnostic.

Removal of shared Keyword

In DXC the shared keyword is parsed and ignored. This may lead users to believing it has some impact when it does not. We should remove it.

Disallow cbuffer initializers

DXC allows variables within a cbuffer to have initializer clauses. The initializer clauses are ignored, and DXC does not issue a diagnostic. In HLSL 202x initializer clauses on declarations placed into an implicit or explicit cbuffer declaration are illegal and will produce an error.

Conforming implementations shall reject initializers on declarations inside cbuffer declarations and on declarations added to the implicit global cbuffer.

Detailed Design

The features referenced in this proposal are all removals, as such they do not have any associated normative language. Each of the following documentation sections will be added as subclauses of Annex B to explain the historical implementations.

Removals from [Lex.Keywords]

The keywords sampler_state, interface, shared and uniform should be removed from the grammar for keywords.

Legacy DirectX Features [AnnexB.LegacyDX]

The existing reference compilers support a set of features that worked in tandem with the Direct3D runtime or other support libraries which are no longer supported in the latest versions of Direct3D.

These features are not included in the standard, nor are they conforming extensions, as such conforming implementation will not support these features.

Effects For Direct3D [AnnexB.LegacyDX.Effects]

The Effects runtime support in Direct3D 9 through Direct3D 11 relied on a set of syntax extensions for HLSL. The latest documentation for the Direct3D 11 Effects APIs and shader syntax is available on Microsoft’s public documentation site.

The main additions to HLSL for the Effects feature are the annotation syntax and technique declarations.

int MyVar <int SomeVal=42;>; // Annotated variable.
sampler S : register(s1) = sampler_state {texture=tex;};

technique10 MyRender // Technique declaration.
{
	pass RenderPass
	{
		SetVertexShader(CompileShader(vs_2_0, VSMain()));
		SetPixelShader(CompileShader(ps_2_0, PSMain()));
	}
}

The effects syntax has three keywords: sampler_state, technique10, and pass.

Shader Interfaces [AnnexB.LegacyDX.Interfaces]

Direct3D 11 supported a limited level of dynamic symbol resolution based on interface declarations. A shader would declare an interface containing a set of function declarations, and any class that inherited from that interface was required to provide definitions of all functions declared in the interface.

This functionality used in conjunction with functionality exposed in DXBC and the Direct3D runtime could swap interface implementations at runtime enabling code reuse and specialization.

This feature is not supported in Direct3D 12, Vulkan, nor any actively supported shader bytecode. DXC’s implementation of the interface keyword is limited to static verification that objects inheriting from the interface provide definitions for all interface members.

A conforming implementation of this standard will not support the interface keyword.

Legacy HLSL Features [AnnexB.LegacyHLSL]

The actively supported reference compiler DXC has support for parsing some HLSL constructs that had meaning and impact in FXC’s implementation, but do nothing in DXC. These legacy language features are omitted from this standard.

cbuffer initializers [AnnexB.LegacyHLSL.cbuffer]

The FXC compiler captured initializers for variables in cbuffer declarations into shader reflection information. This information was used by the Effects for Direct3D runtime, but could also be used directly by users.

The DXC compiler supported parsing initializers but did not capture them into the shader reflection or any other metadata. This standard disallows initializing variables in cbuffer declarations, an initializer in such a declaration is ill-formed and a conforming implementation must issue a diagnostic.

uniform and shared keyword [AnnexB.LegacyHLSL.Keywords]

The current implementation of DXC parses but ignores the uniform and shared keywords which had meaning in earlier versions of HLSL. A conforming implementation will not support these keywords, will treat them as identifier tokens, and will error if they are encountered in grammar formations where identifiers are disallowed.