This is an archive of the discontinued LLVM Phabricator instance.

[HLSL][clang][Driver] Support target profile command line option.
ClosedPublic

Authored by python3kgae on Mar 31 2022, 10:18 PM.

Details

Summary

The target profile option(/T) decide the shader model when compile hlsl.
The format is shaderKind_major_minor like ps_6_1.
The shader model is saved as llvm::Triple is clang/llvm like dxil-unknown-shadermodel6.1-hull.
The main job to support the option is translating ps_6_1 into shadermodel6.1-pixel.
That is done inside tryParseProfile at HLSL.cpp.

To integrate the option into clang Driver, a new DriverMode DxcMode is created. When DxcMode is enabled, OSType for TargetTriple will be forced into Triple::ShaderModel. And new ToolChain HLSLToolChain will be created when OSType is Triple::ShaderModel.

In HLSLToolChain, ComputeEffectiveClangTriple is overridden to call tryParseProfile when targetProfile option is set.

To make test work, Fo option is added and .hlsl is added for active -xhlsl.

Diff Detail

Event Timeline

python3kgae created this revision.Mar 31 2022, 10:18 PM
Herald added a project: Restricted Project. · View Herald Transcript
Herald added a subscriber: mgorny. · View Herald Transcript
python3kgae requested review of this revision.Mar 31 2022, 10:18 PM

Change lit test to unit test to avoid require build DirectX target.

Looping in a few extra reviewers, also added some comments below.

clang/lib/Driver/ToolChains/HLSL.cpp
44

Do we need to verify this or can we just assume if there is no minor version specified that the version is 0?

58

Do we actually care if someone sets a compute shader as targeting shader model 4.8 (a version that doesn't really exist)?

For compatibility with DXC, when targeting DXIL we're going to end up bumping older shader model targets up to 6.0 anyways, so I'm not sure it makes sense to verify at this level.

I think it is sufficient to just verify that the version is >= the shader model that introduced the stage.

63

One down side to this type of version matching is that when new shader model versions are introduced all of this code needs to be updated.

If we don't need this in-depth verification we should leave it out. I suspect drivers providing runtime verification, and the dxil verification we do later means we can leave this off.

clang/lib/Driver/ToolChains/HLSL.h
29
python3kgae added inline comments.Apr 5 2022, 11:51 AM
clang/lib/Driver/ToolChains/HLSL.cpp
44

To match things like ps_6_0, it would be nice to require minor version.

58

I could add the code to bump to 6.0, then we don't need to validator lower shader model like 4_1 here.

63

The chance to hit this error should be very small.
Should be OK to report it in validation only.

clang/lib/Driver/ToolChains/HLSL.h
29

This is an override.

beanz added inline comments.Apr 5 2022, 12:42 PM
clang/lib/Driver/ToolChains/HLSL.cpp
44

That's for the option handling code path where we enforce that it is always set by the parsing code. There's no reason we need to require the minor version if the triple is explicitly provided.

58

I don't think we need to bump the value in this code.

My point is that targeting ShaderModel 4.2 isn't going to actually break anything in the compiler, and the rigidity of this code means it will need to be updated every time we update and alter shader models.

It should be sufficient to verify that a Compute shader is targeting shader model >= 4.0, we shouldn't need to verify that it is 4.0, 4.1, 5.0, 5.1 or 6.0-6.7. That's a lot of code to maintain for no real requirement.

clang/lib/Driver/ToolChains/HLSL.h
29

Doh! Please ignore :)

beanz added inline comments.Apr 12 2022, 4:00 PM
clang/lib/Driver/Driver.cpp
1203

nit: this can be an else for the if above

clang/lib/Driver/ToolChains/HLSL.cpp
40

I don't think there is a good reason to verify max versions in the compiler.

This kind of code just makes more places we have to update when things move forward.

Code cleanup.

beanz accepted this revision.Apr 13 2022, 6:42 PM

LGTM

This revision is now accepted and ready to land.Apr 13 2022, 6:42 PM
This revision was landed with ongoing or failed builds.Apr 15 2022, 12:18 PM
This revision was automatically updated to reflect the committed changes.

Hi, there seems to be a unit test failure, for example here.

/home/buildbot/as-worker-91/clang-with-lto-ubuntu/build/stage1/tools/clang/unittests/Driver/./ClangDriverTests --gtest_filter=DxcModeTest.TargetProfileValidation

/home/buildbot/as-worker-91/clang-with-lto-ubuntu/llvm-project/clang/unittests/Driver/ToolChainTest.cpp:484
Expected equality of these values:

DiagConsumer->Errors.back().data()
  Which is: "invalid profile : ps_6_x1"
"invalid profile : ps_6_x"

/home/buildbot/as-worker-91/clang-with-lto-ubuntu/llvm-project/clang/unittests/Driver/ToolChainTest.cpp:502
Expected equality of these values:

DiagConsumer->Errors.back().data()
  Which is: "invalid profile : foo_6_1"
"invalid profile : foo"
beanz added a comment.Apr 15 2022, 6:14 PM

@wolfgangp I can't reproduce the failure locally, but I have a guess what's going wrong. I _think_ the issue is that the SmallStrings aren't null terminated and the cleared allocations aren't zero'd. I pushed a speculative fix in rG329abac134a3. Hopefully that fixes it. If not feel free to revert the changes, @python3kgae you'll have to diagnose further issues as I'll be afk all of next week.

Created new patch to fix the test fail at https://reviews.llvm.org/D123887

Seems to be fine now. Thanks.