Sign in to follow this  
L. Spiro

[DirectX 11] internal error: argument pulled into unrelated predicate

Recommended Posts

I am getting this error on my pixel shader.
Here is my shader (lack of comments because it is machine-generated).

SamplerState lsg_SamplerBiLinearRepeat : register( s0 ) {Filter = MIN_MAG_LINEAR_MIP_POINT;AddressU = WRAP;AddressV = WRAP;};
Texture2D g_sSampler2dTex0 : register( t0 );
cbuffer cb0 : register( b0 ) {
vector<float, 4> g_vDiffuseMaterial : packoffset( c0.x );
vector<float, 4> g_vSpecularMaterial : packoffset( c1.x );

vector<float, 4> cDiffuse;
vector<float, 4> cSpecular;

void Main( in vector<float, 3> _vInNormal : NORMAL0, in vector<float, 2> _vIn2dTex0 : TEXCOORD2, in vector<float, 4> _vInPos : SV_POSITION0, in vector<float, 4> _vInEyePos : TEXCOORD1, out vector<float, 4> _vOutColor : SV_Target0 ) {
vector<float, 4> vColorTemp;

vector<float, 3> vNormalizedNormal = normalize( _vInNormal );

vector<float, 4> vViewPosToEye = -normalize( _vInEyePos );

LSE_COLOR_PAIR cpLightColors = {
vector<float, 4>( 0.0, 0.0, 0.0, 0.0 ),
vector<float, 4>( 0.0, 0.0, 0.0, 0.0 )

vColorTemp = g_sSampler2dTex0.Sample( lsg_SamplerBiLinearRepeat, _vIn2dTex0 ); = ( *;

_vOutColor = vector<float, 4>( ( *, vColorTemp.w );

_vOutColor.w *= ((((1.0 / abs( dot(, vNormalizedNormal ))) - 1.0) * 0.1333) + 1.0);

_vOutColor.w = min( _vOutColor.w, 1.0 );
if( _vOutColor.w <= 0.10000000000000001 ) {
} = (( * + (g_vSpecularMaterial * cpLightColors.cSpecular).xyz);

_vOutColor = max( _vOutColor, vector<float, 4>( 0.0, 0.0, 0.0, 0.0 ) );

I don’t see what is causing this error. Looks like a fairly standard shader.
Any ideas?

L. Spiro

Share this post

Link to post
Share on other sites
I've never seen that error before, but it seems to be caused that return in the if statement. If I remove that it compiles fine, even if I move the subsequent code into an else block. In general I tend to have problems with the compiler when I try to put in a mid-function return statement, so I try to avoid doing that.

Share this post

Link to post
Share on other sites
That would explain why it is basically [b]only[/b] my transparent objects that are not being displayed in DirectX 11. Thank you for that however I have a follow-up question.

I know that discard is usually to be avoided, especially on machines such as iOS, but at the level of shader model 5 I would expect discard not to be so serious and a mid-function return to actually be an early-out, and thus possibly help save some cycles.
Assuming it actually compiles, is there any benefit from a return early in the life of the shader? I know that previous models would often still execute the whole shader so it made no difference back then, but that was a long time ago.

And speaking of optimizations, at one point I had to rearrange the order of my vertex shader outputs to make them the same order as the pixel shader inputs. This was not necessary in DirectX 9 (nor in OpenGL 3.2 or OpenGL ES 2). Is there a performance penalty in DirectX 9 when these are not in the same order (or asked another way, is there a gain when they are in the same order)?

L. Spiro

Share this post

Link to post
Share on other sites
I'm not sure if you need to branch to fully stop execution of shader that hits a discard, or if the hardware will stop it anyway. I haven't done any extensive performance tests to see if it's worth it or not.

As for VS outputs/PS inputs, I know that on recent AMD hardware the the VS outputs will get loaded into LDS (on-chip shared memory) and the pixel shader will read those values and perform interpolation based on the pixel position. This essentially means that the address of each input parameter is hard-coded into the shader program, which makes sense given that D3D10/D3D11 requires that the parameter ordering matches between VS and PS stages. I'm not sure how they handle the D3D9 case where the ordering doesn't have to match...I suspect that they probably patch the pixel shader at runtime based on the vertex shader that's bound when you issue the Draw call.

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this