Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


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


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
1 reply to this topic

#1 AndyPandyV2   Members   -  Reputation: 298

Like
1Likes
Like

Posted 29 April 2014 - 02:35 PM

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, 29 April 2014 - 02:36 PM.


Sponsor:

#2 AndyPandyV2   Members   -  Reputation: 298

Like
3Likes
Like

Posted 29 April 2014 - 05:20 PM

 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.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS