HLSL 6.0 ... 6.9 and GPUTexture for d3d12

[soufianekhiat]

Breaking changes

• Add support for HLSL 6.0 ... 6.9
• Add support for GPU Texture on d3d12compute

Details:

• Emit "//HALIDE_D3D12_SM XX" on HLSL version and being parsed to avoid complex infrastructure just to get that version KISS.
• Co-authored-by: Claude (all code formating, comments and mini_dxc.cpp was 100% written by Claude Opus 4.6)

Checklist

• Tests added or updated (not required for docs, CI config, or typo fixes)
• Documentation updated (if public API changed)
• Python bindings updated (if public API changed)
• Benchmarks are included here if the change is intended to affect performance.
• Commits include AI attribution where applicable (see Code of Conduct)

[soufianekhiat]

Is that possible to have a maintainer trigger the CI for this one please?

[alexreinking]

We don't seem to have any d3d12compute coverage on the buildbots. I'll need to add that prior to reviewing/merging this.

[soufianekhiat]

We don't seem to have any d3d12compute coverage on the buildbots. I'll need to add that prior to reviewing/merging this.

Added this to tests HLSL 6.x features:
test/correctness/cross_compilation.cpp
https://github.com/halide/Halide/pull/9077/changes#diff-8155bdbbeeb25a66365bbd00273602683aa90a2f220c98dbaa8e15f6f988403e

[alexreinking]

I've modified the buildbots to test d3d12compute_sm65, which is the highest version both Windows bots support. We'll see how this goes! I notice that several features here are gated behind higher versions than that. I've tagged this dev_meeting so we can discuss a testing plan.

[alexreinking]

Many tests require strict_float... it seemed easy enough to implement following the precise hint and copying the Vulkan backend's approach to lowering. The only tricky business is that we need a different key than the given expression (or we'd need to implement a bunch of strict_OP intrinsics with precise arguments).

[alexreinking]

@soufianekhiat -- can you look at the codegen failures here? There seem to be two classes of bug:

1. Globals have clashing names. I'm not sure what the best resolution here is.
2. "as" casts are misspelled, e.g. asfloat32_t instead of asfloat

[soufianekhiat]

@soufianekhiat -- can you look at the codegen failures here? There seem to be two classes of bug:

1. Globals have clashing names. I'm not sure what the best resolution here is.
2. "as" casts are misspelled, e.g. asfloat32_t instead of asfloat

Do we have tests for codegen? I just run locally the one I think are relevant.

[alexreinking]

Do we have tests for codegen? I just run locally the one I think are relevant.

We don't have (many) compile-only tests... I'm just looking at the buildbot failures here; the issues are with invalid code being generated which is why I called them "codegen failures".

Also, I'm noticing that there's some signed/unsigned mismatch happening somewhere.

https://buildbot.halide-lang.org/master/#/builders/391/builds/385

[alexreinking]

@soufianekhiat - I've opened #9080 to test patches that are generally needed to fix the D3D12 backend, even for HLSL <6.0. That should provide a more stable foundation for this PR, which should be scoped to extending support to 6.0-6.9, rather than also including fundamental bug-fixes.

[alexreinking]

@soufianekhiat - the HLSL 5.1 fixes are in, so please rebase/merge with main.

[soufianekhiat]

Thanks

[shoaibkamil]

Thanks for adding this! I took a first pass over the PR, and it's getting close to being finished. I found a few issues, however, so please take a look.

[soufianekhiat]

Updated the validation script for that PR found new issues:
https://gist.github.com/soufianekhiat/2a8d174b366b69ea4221c18a15711f6a
Make sure all generated shaders works and compile with dxc

[soufianekhiat]

@alexreinking @shoaibkamil @slomp Let me know if that changes fits.

[slomp]

Not particularly familiar with texture support in Halide itself, so I just want to make sure that MipLevels = 1 is expected/appropriated here.

[slomp]

I think retrofitting textures into the buffer interface will lead to trouble eventually.
Technically, things like Upload/Readback and ReadOnly/ReadWrite are properties of the buffer that are also applicable (with their own quirks) to textures.
Is this how the other Halide back-ends implement textures (by just piggy-backing on the buffer interface)?

[slomp]

So, the HLSL code gen just emits a comment about the shader model?
I think it would be more useful to emit an actual #define HALIDE_D3D12_SM <version-number> instead.
This way, we can inject/patch code later on with preprocessor checks.

[soufianekhiat]

It will be never be used by the code it will be just read by:
int parse_hlsl_sm_version(const char *source)

[slomp]

I'll give you and the other reviewers some time to discuss/address my points above, and once that's resolved, I'll give the runtime code another look.

I think the kernel argument packing logic which I wrote originally has some fundamental flaws that I want to explore, and adding/mixing 64bits to it has raised some concerns I need to verify in the meanwhile.