Skip to content

[HLSL][SPIRV] Generate sign extended image instructions #144580

Open
@s-perron

Description

@s-perron

In HLSL, a RWBuffer is suppose to be loading value as if they are signed integers. This is important because if the format of the image is 8-bit, then the value on a load is implicitly sign extended. The problem in the current Clang implementation is that the signedness of the sampled type is lost because llvm-ir interpreted whether or not an integer is sign or not based on the instruction that is using it.

Without knowing the signedness of the sample type, SPIR-V generates all code assuming the integers are unsigned. This causes problems.

There are two possible solutions in the SPIR-V:

  1. Pass information along so that the sampled type can be modified to be a signed integer.
  2. Pass information along so that the OpImage* instructions can get the signExtend image operand when necessary.

The difficulty with 1 is that the sampled type of the image must match the Texel components of the OpImage* instructions. This means that the type information will have to propagate further.

Seems like 2 is the best solution. It is a more local change, making the code generation easier.

Now we still need to figure out how to pass the information from the FE to the BE. There are again a few options

  1. Use a new target type that has a bit for isSigned as is done for DXIL.
  2. Incorporate the sign into the type for the spirv.Image type.
  3. Add a target attribute to the "gethandlefrombinding" call.
  4. Add an annotation to the loads and stores.

Option 4 does not work. The annotation would have to be metadata, which the optimizer is allowed to drop.

Option 2 does not work well either. It would require special handling to make sure the sampled type matches other integers. Not a reasonable option.

To know if 1 will work, I'll have to see if the SPIR-V backend has easy access to the lllvm type when generating the load and stores. The SPIR-V type will have lost the signedness informations.

If that does not work, we will have to go with option 3. However, that has it own uglyness.

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

Status

Ready

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions