• Advertisement
Sign in to follow this  

Passing interpolated screenpos can be better than declaring SV_POSITION in pixel shader especially if PS is short

This topic is 1361 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

From this PDF of performance tips by AMD:

 

http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/05/GCNPerformanceTweets.pdf

 

GCN Performance Tip 38: Passing interpolated screenpos can be better than 
declaring SV_POSITION in pixel shader especially if PS is short. 
Notes: Declaring SV_POSITION in the pixel shader will not be as efficient as passing 
screen coordinates from the previous shader stage because its use is hard-coded to 
fixed-function hardware that is also used for other purposes. 
If a pixel shader needs access to fragment position it is recommended to pass it via 
texture coordinates instead.

 

 

 This statement isn't making much sense to me based on testing this in a VX/PS combo.

 

Take this VS output.

 

struct VS_OUTPUT_SIMPLE{
    float4 Position   : SV_POSITION; 
    float3 Normal     : NORMAL;     
    float4 Color : TEXCOORD0;
};
 
If I write these in the VS, and create a PS like so
 

Output PixelShader(VS_OUTPUT_SIMPLE In){}

 

The AMD statement would lead me to believe I can create an alternate struct that lacks SV_Position, and use that as input to the PS.

 

PS_INPUT_SIMPLE{

    float3 Normal      : NORMAL;      
    float4 Color : TEXCOORD0;
};
 
Output PixelShader(PS_INPUT_SIMPLE In){}
 
But this does not compile

 

It fails with this error.

 

Stage linkage warning: Semantic NORMAL has been placed in different registers in the two stages.
 
(which is what I'd expect, aside from this mysterious AMD statement).
 
Anyone grok what AMD is saying here?
Edited by AndyPandyV2

Share this post


Link to post
Share on other sites
Advertisement

 Well I figured it out..  and it did give a significant speed up which surprised me.

 

Rearrange the VS output like so. Moving the SV_POSITION value to the last location.

 

struct VS_OUTPUT_SIMPLE{
    float3 Normal     : NORMAL;     
    float4 Color : TEXCOORD0;
    float4 Position   : SV_POSITION; 
};
 
And using this as PS input.
 

PS_INPUT_SIMPLE{

    float3 Normal      : NORMAL;      
    float4 Color : TEXCOORD0;
};
 
I had assumed the order wasn't relevant because it is being bound to NORMAL/TEXCOORD0 etc, but it appears that it is.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement