[SOLVED] Render Pipeline issue
- SIC
- Topic Author
Less
More
Hi there, I'm having an issue with using multiple passes per a single technique.
From my understanding, each pass has to be completed before the next one begins. If you do not set a render target, and, your source texture / sampler is the same per each called pass -- as per code snippets below -- then the same frame color texture will be feed into the next pass with the effects of that pass applied to that texture and the accumulative changes made to that texture from previous effect passes.
This seems to be how SweetFX is structured, but, not MasterEffects -- uses (more or less two target render textures which alternate per pass, with the last feeding into the next. I could set it up like MasterEffects but, that seems like it is unnecessary (and inefficient) from my understanding and going off of SweetFX code.
However, as I have it structured -- as code above shows -- one pass does not feed into the next but rather, each pass is getting a "clean" original source of the frame color buffer. So, the HDR pass is lost and the Final pass is the only one that gets run.
I'm guessing this has come up before and is rather obvious with the hindsight of experience -- which I don't have and can't find an answer to via searches. So, does anyone have an idea about what I am doing wrong here..?
From my understanding, each pass has to be completed before the next one begins. If you do not set a render target, and, your source texture / sampler is the same per each called pass -- as per code snippets below -- then the same frame color texture will be feed into the next pass with the effects of that pass applied to that texture and the accumulative changes made to that texture from previous effect passes.
// Called shaders -- "wrappers" to included effect scripts
float3 PS_HDR(VS_OUTPUT_POST IN) : SV_Target
{
float4 color = tex2D(SamplerColor, IN.txcoord.xy);
color = FX_HDR(color, IN.txcoord.xy);
return color.rgb;
}
float4 PS_Final(VS_OUTPUT_POST IN) : SV_Target
{
float4 color = tex2D(SamplerColor, IN.txcoord.xy);
color = FX_Splitscreen(color, IN.txcoord.xy);
#if (__RENDERER__ == 0x061 && __VENDOR__ == 0x10DE)
color.rgb = color.bgr;
#endif
return color;
}
// Technique pass code:
pass HDR
{
VertexShader = VS_PostProcess;
PixelShader = PS_HDR;
}
pass Final
{
VertexShader = VS_PostProcess;
PixelShader = PS_Final;
}
This seems to be how SweetFX is structured, but, not MasterEffects -- uses (more or less two target render textures which alternate per pass, with the last feeding into the next. I could set it up like MasterEffects but, that seems like it is unnecessary (and inefficient) from my understanding and going off of SweetFX code.
However, as I have it structured -- as code above shows -- one pass does not feed into the next but rather, each pass is getting a "clean" original source of the frame color buffer. So, the HDR pass is lost and the Final pass is the only one that gets run.
I'm guessing this has come up before and is rather obvious with the hindsight of experience -- which I don't have and can't find an answer to via searches. So, does anyone have an idea about what I am doing wrong here..?
Please Log in or Create an account to join the conversation.
- crosire
Less
More
9 years 2 months ago - 9 years 2 months ago #2
by crosire
Replied by crosire on topic Render Pipeline issue
If no rendertarget is set, ReShade will write the output to the framebuffer (where the original game image was in). That one is usually set up as R8G8B8A8 = 32bit buffer. This is usually enough for SweetFX, but not for MasterEffect, which uses the ping-pong technique with its own rendertargets because it requires more precision between passes: it uses R32G32B32A32F = 128bit floating-point buffers and only writes the final output to the framebuffer.
The ping-pong switching between two rendertargets is needed because you can't read and write to one rendertarget at the same time, so what MasterEffect does is: it first renders to the first texture, in the next pass it then samples from that texture but renders to the second texture, the next pass then samples from the second texture but renders to the first texture etc. There's one exception where this is not needed, that's sampling from the framebuffer. ReShade already copies the content to a separate texture, so in this case you can retrieve that picture and still write to it in the same pass (which is why you don't see any ping-ponging in SweetFX).
I hope this wasn't explained too complicated, I'll try to make it better to understand in case it was
To get to your issue:
Your code actually looks totally fine, provided "SamplerColor" is a sampler to the framebuffer (a texture using the ": COLOR"/": SV_Target" semantic). Are you sure precision of the framebuffer is enough for the HDR pass? Maybe information is lost due to the small buffer format. Try to add something like "color.r = 1.0f;" to the HDR pass to see if that is preserved to the final pass. Also, are you sure anything is drawn at all and you don't just see the original game without modification?
The ping-pong switching between two rendertargets is needed because you can't read and write to one rendertarget at the same time, so what MasterEffect does is: it first renders to the first texture, in the next pass it then samples from that texture but renders to the second texture, the next pass then samples from the second texture but renders to the first texture etc. There's one exception where this is not needed, that's sampling from the framebuffer. ReShade already copies the content to a separate texture, so in this case you can retrieve that picture and still write to it in the same pass (which is why you don't see any ping-ponging in SweetFX).
I hope this wasn't explained too complicated, I'll try to make it better to understand in case it was
To get to your issue:
Your code actually looks totally fine, provided "SamplerColor" is a sampler to the framebuffer (a texture using the ": COLOR"/": SV_Target" semantic). Are you sure precision of the framebuffer is enough for the HDR pass? Maybe information is lost due to the small buffer format. Try to add something like "color.r = 1.0f;" to the HDR pass to see if that is preserved to the final pass. Also, are you sure anything is drawn at all and you don't just see the original game without modification?
Last edit: 9 years 2 months ago by crosire.
Please Log in or Create an account to join the conversation.
- SIC
- Topic Author
Less
More
Yes, they are making changes; I've been putting calls to the effects within the same pass in order to continue working on and testing them. I also added in the extra line to the "HDR" pass to set red to max and it had the intended effect - red tinged screen. However, the "final" pass didn't appear to do anything as it didn't correct the RGB channels for my Nvidia card or apply the split-screen effect.
The HDR effect and Split-screen are both from SweetFX with minimal changes -- so "ping pong" method shouldn't be necessary. The frame texture and sampler are set up as follows:
It may be best I use the ping pong approach anyways, as I want to adapt some of the MasterEffect scripts -- basically custom SweetFX and MasterEffect scripts with something new I'm working on. Still, nice to get a sense of what I'm doing wrong for future reference as shaders is still a new area for me
The HDR effect and Split-screen are both from SweetFX with minimal changes -- so "ping pong" method shouldn't be necessary. The frame texture and sampler are set up as follows:
texture2D texColor : SV_Target;
sampler2D SamplerColor
{
Texture = texColor;
MinFilter = LINEAR;
MagFilter = LINEAR;
MipFilter = LINEAR;
AddressU = Clamp;
AddressV = Clamp;
SRGBTexture=FALSE;
MaxMipLevel=8;
MipMapLodBias=0;
};
It may be best I use the ping pong approach anyways, as I want to adapt some of the MasterEffect scripts -- basically custom SweetFX and MasterEffect scripts with something new I'm working on. Still, nice to get a sense of what I'm doing wrong for future reference as shaders is still a new area for me
Please Log in or Create an account to join the conversation.
- crosire
Less
More
You could send me the whole shader, so I can take a look at it or we can get in contact over Steam/Skype. I'd sure be happy to help you to get it working
Please Log in or Create an account to join the conversation.
- SIC
- Topic Author
Less
More
I got around to cleaning up my code, as there was a lot of commented out junk, in the hopes that I might stumble on the culprit before sending the shader scripts off to you and found some curious things.
The below Nvidia check and color channel correction appears to be completely unnecessary as long as you are executing multiple passes -- I've only tried it with 2 via the 1 technique, for all I know if you use a 3rd pass you may get the weird colors again in that each pass is "correcting" the RGB channels.
I think this was a major source of my confusion, as it appeared to me that the Nvidia correction lines in the final pass were not executing when they were -- they were just flipping them back, if you follow.
Also, it looks like the second pass was executing, however, unless I add in an effect prior to the Splitscreen shader effect call, then for some reason it fails to run -- I know it does, because, the Nvidia color channels are correct; I also added in another effect call that modified the screen colouring and it was applied along with the Splitscreen. Not sure why, but I think it has something to do with all the "return" lines in the SweetFX Splitscreen script being in an "#if... #endif" block; perhaps the compiler thinks that the script isn't returning anything and therefore the pass does nothing..?
EDIT: Yes, if you add an additional 3rd pass then you need to apply the Nvidia correction; appears that this needs to be used if you have an odd number of passes in use and that each pass is causing this "flipping" somehow . Simplest fix is to make sure that the Nvidia statement is in every pass.
The below Nvidia check and color channel correction appears to be completely unnecessary as long as you are executing multiple passes -- I've only tried it with 2 via the 1 technique, for all I know if you use a 3rd pass you may get the weird colors again in that each pass is "correcting" the RGB channels.
#if (__RENDERER__ == 0x061 && __VENDOR__ == 0x10DE)
color.rgb = color.bgr;
#endif
I think this was a major source of my confusion, as it appeared to me that the Nvidia correction lines in the final pass were not executing when they were -- they were just flipping them back, if you follow.
Also, it looks like the second pass was executing, however, unless I add in an effect prior to the Splitscreen shader effect call, then for some reason it fails to run -- I know it does, because, the Nvidia color channels are correct; I also added in another effect call that modified the screen colouring and it was applied along with the Splitscreen. Not sure why, but I think it has something to do with all the "return" lines in the SweetFX Splitscreen script being in an "#if... #endif" block; perhaps the compiler thinks that the script isn't returning anything and therefore the pass does nothing..?
EDIT: Yes, if you add an additional 3rd pass then you need to apply the Nvidia correction; appears that this needs to be used if you have an odd number of passes in use and that each pass is causing this "flipping" somehow . Simplest fix is to make sure that the Nvidia statement is in every pass.
Last edit: 9 years 2 months ago by SIC.
Please Log in or Create an account to join the conversation.
- crosire
Less
More
If you update to latest NVIDIA drivers, you can leave out that stuff. They appearently fixed the bug now (according to users in another thread here and some quick tests I did myself).
Please Log in or Create an account to join the conversation.
- BrandonHortman
Less
More
SIC, did you get HDR compiled into Master effects?
I am really interested in that! I was going to try to reverse engineer that tonight, but I am totally ignorant to coding so I doubt I will do well
I am really interested in that! I was going to try to reverse engineer that tonight, but I am totally ignorant to coding so I doubt I will do well
Please Log in or Create an account to join the conversation.