Heterogeneous Flag Failing with Multiple Entry Points

[Checkmate50]

Currently, if you have more than one entry point and use the flag -heterogeneous with a GPU target, the compiler fails with the error Slang::InternalError: unexpected: No blob to emit. I believe there is a workaround (which I don't recall), but this still seems like an annoying hazard; as a user, I would expect the -heterogeneous flag to work without having to introduce an additional workaround.

I haven't narrowed down the issue exactly, but I've traced it back to emitEntryPoint, which, when multiple entry points exist, seems to emit an entry point without the blob -- I suspect this is actually just a reflection of an earlier issue or lack of flag, but this is the most immediate failure point.

[tangent-vector]

What was the full command line you used?

If emitEntryPoint failed to produce a blob output, that would seem to imply that it ran into some other kind of compilation error. I wonder if there were any other error messages produced (usually written to the DiagnosticSink) but that weren't yet written to the console, and then never got written because of the internal error that came up?

[Checkmate50]

Sorry for the slow reply, I didn't notice your reply earlier (I've updated my email settings now).

The full command line arguments I used were: examples/heterogeneous-hello-world/shader.slang -o examples/heterogeneous-hello-world/shader2.cpp -target cpp -target dxbc -heterogeneous -entry computeMain -stage compute

I got the output of the DiagnosticSink before it crashed, and got the message: fxc: examples/heterogeneous-hello-world/shader.slang(57,25-27): error X3004: undeclared identifier '_S6'

Any ideas?

[Checkmate50]

I've experimented some more with the input, and found that this error only occurs when attempting to compile with the -heterogeneous flag and when the __GPU_FOREACH(...) code is uncommented. So I'm guessing something broke in my implementation of the __GPU_FOREACH_LOOP at some point, though I don't know why this is affecting the compilation of the shader blob...

[tangent-vector-personal]

The fact that you got an error from fxc implies some kind of compiler bug; it implies that Slang is generating invalid HLSL code and then asking fxc to compile it. That explains why there is no data in the DXBC result, because the compiler that would have produced the DXBC failed with an error.

I don't know if it was something in the code at the time the -heterogeneous flag got added, or something that came along after. The next step is probably to look at the generated HLSL (by stopping in the debugger before the call through the D3DCompile function pointer happens), and to see what _S6 is so that we can get an idea where the bad code generation is happening.

[Checkmate50]

Sounds good. I opened up the HLSL code and found this line is the source of the error: computeMain_wrapper(_S6, _S4, _S5);, though why this is part of compiling computeMain I'm not sure. I'm going to go back through the git history and see if a recent change (since Summer) caused the problem or if it was previously present.

[Checkmate50]

Alright, so I went back in Git history, and found that some change made since September has caused the generated HLSL text to also include all the C++ code in the file. I'm gonna try and binary search through Git history to narrow down exactly when this broke, since I think that will help my debugging efforts and help avoid having me break some change made since I designed this stuff.

[Checkmate50]

So this is the commit that breaks things, by introducing the C++ into the compiled HLSL: https://github.com/shader-slang/slang/commit/ee5842a01cdb2bd6cd4acee7214666f180b95d84

[Checkmate50]

So I narrowed it down to the deletion of line 1484. It seems like there was a decision to generalize the target to not be restricted to CPP and CUDA, which breaks my heterogeneous code by adding C++ to the HLSL block. Any thoughts on how I might be able to work around this? I'm not sure what effect changing this code has on the overall system...