New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[DX] Shader parameter semantics are ignored #6282

Jjagg opened this Issue Apr 15, 2018 · 3 comments


None yet
2 participants

Jjagg commented Apr 15, 2018

Shader parameters are bound by position rather than by semantics for WindowsDX projects. For DesktopGL parameters are bound correctly.

I set up a minimal project that shows the issue:
The vertex shader:

struct VertexShaderOutput
	float4 Position : SV_POSITION;
        float4 Red : COLOR1;
	float4 Color : COLOR0;

VertexShaderOutput MainVS(float4 position : POSITION0, float4 Color : COLOR0)
    VertexShaderOutput output = (VertexShaderOutput)0;
    output.Position = position;
    output.Red = float4(1, 0, 0, 1);
    output.Color = color;
    return output;

and the pixel shader:

float4 MainPS(float4 position : SV_POSITION, float4 color : COLOR0, float4 red : COLOR1) : COLOR
    return color;

For DesktopGL this correctly outputs the color that's passed in (green), but for WindowsDX this outputs red. So output.Red is bound to color and output.Color is bound to red because of the order.

What version of MonoGame does the bug occur on:

  • MonoGame 3.7

What operating system are you using:

  • Windows

What MonoGame platform are you using:

  • WindowsDX

This comment has been minimized.

JSandusky commented Apr 18, 2018

That's a DX runtime thing with user-semantics needing to be in sequence between stages when passed argument style. You'd have to parse and automatically restructure the HLSL to fix, since when a shader for a stage is compiled it's clueless about the other stages.

Shows its head all the time when you're plugging in some GS/HS+DS into some existing shaders that use that awful function style.


This comment has been minimized.


Jjagg commented Apr 19, 2018

You'd have to parse and automatically restructure the HLSL to fix

I think this is what the effect-compiler tool (fxc) does. Though I can't seem to find documentation on it.

This is a bit tricky to do for us right now since our effects parser is very limited. Once we switch to a more complete parsing approach, rewriting the parameter order should become pretty doable with some syntax tree manipulations.


This comment has been minimized.

JSandusky commented Apr 21, 2018

It would require adding SharpDX.Direct3D11 as a dependency but as far as I'm aware the signature checking functions don't require an actual device context to be active, so could maybe at least provide an error ahead of time. Granted I've never bothered with using them since turning on the debug layer has it screaming at you about signature compliance.

O/T: Is there anything more detailed on the 2MGFX pipeline and where it's going? It's seemingly stagnated so long that I just said screw it and added GS/HS/DS a few days ago despite some minor confusion with d3dx_state's operation field and some seemingly nonsensical parser constructs for parameters (commits, runtime untested - compiling checks out so far). It felt like everything in there was being pulled all sorts of ways.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment