[Scenario] Adding hello world pixel/vertex shader support

[inbelic]

This issue tracks the work to outline what is required in clang to compile the hello world pixel/vertex shaders.

This requires:

• Outline missing support in obj2yaml to allow for object correctness inspection
• Outline required compiler flags/options
• Scoping a set of semantics that should be required for the milestone
• Outline work to correct code/metadata-generation during SemaHLSL:handleSemantic[Store|Load]
• Outline work required to lower the llvm.dx.load.input and llvm.dx.store.output intrinsics
• Outline work required to handle metadata and generate signature parts for the DXContainer are required (eg: root signatures, semantics).
• Outline if any updates to other parts are required (eg. PSVInfo)
• Outline offload test suite testing
• Work in progress...

AC:

• A proposal outlining the work required.

[inbelic]

Here are some relevant issues:

• [DirectX backend] generate metadata for input output signature llvm-project#57928: work to emit metadata to retain signature information (can re-use)

• [DirectX backend] generate ISG1, OSG1 parts for graphics shaders llvm-project#90504: backend work to build signatures for DXContainer (can re-use)

• [HLSL] Add support for user semantics llvm-project#153424: initial support for user semantics (has DX related fixmes)

• [HLSL] Add initial support for output semantics llvm-project#168095: initial support for output semantics (has DX related fixmes)

• [HLSL][SPIR-V] Implements SV_Position for VS/PS I/O llvm-project#168735: spirv support for SV_Position (has DX related fixmes)

Napkin summary:

It appears we already have the required front-end support for semantics in place (we can just extend HLSLSemanticAttr with a missing semantic). In terms of scoping which semantics we should support for this scenario, these are required (for here): SV_Position, SV_Target and user semantics. It might make sense to support all System Value (SV) and System Generated Values (SGV) as defined here that can be sensibly tested using the current offload test suite (no mesh/geometry related values).

We will need to fill in some gaps during code-generation of the llvm.dx.load.input and llvm.dx.store.output to correct the intrinsic call. See fixmes 1, 2.

We will need to define a metadata schema for storing signature information (all current DXIL supported semantics can be expressed as a system intrinsic call). Then update CGHLSLRuntime:handleSemantic[Store|Load] to generate this metadata.

We will then need to add support for parsing the metadata and generating the parts in the DXContainer.

obj2yaml already supports all parts that are produced by DXC (aside from STAT, which is optional). This means we have the required support to do testing for the generated signature parts.