Jump to content
  • Advertisement
Sign in to follow this  
AxeGuywithanAxe

OpenGL Generic vs Hardcoded Shader

This topic is 1148 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

Hey guys, so I wanted to keep this short and to the point. I am re-implementing my shader pipeline and I wanted to get some outer thoughts on the best direction to take. As far as I know it, there are three main implementations for shader parameter setting at runtime; hard coding semantics through enums or constants, i.e kProjView, reflecting shader parameters through string look ups, enumulating .fx and opengl, and hard coding a shader class per hlsl/glsl. I am leaning towards the later two for their dynamic nature, though varying. The benefit of the effects framework-esque implementation is that it only requires a single class, and is quick to implement. All that's need is reflecting all the shader's parameters through ID3D11Reflect, put all the parameters in a parameter map for runtime searching, and you're done. The issue with a system like this is that setting shader parameters would require quite a few string comparisons i,e:
 
  m_pShader->SetFloatParameter("MyParameter",5.f);
 
This does not seem very efficient. I believe that this is the implementation that cryengine and unity use. The latter method would let me circumvent the need for string comparisons by hardcoding where each parameter should bind to and just passing a blob type of memory for setting
 
i.e
 
struct MyShaderParameters
{
        Matrix4 entityTM;
        Matrix4 cameraProj;
        Matrix4 cameraView;
};


class MyShader
{
public:

void SetParameters(uint8* Blob)
{
     MyShaderParameters* Parameters = (MyShaderParameters*)(Blob);
    CameraParameter.SetValue(Parameters->CameraProj);
     EntityParameter.SetValue(Parameters->entityTM);
}
//these parameters are reflected when this shader is instantiated
   FUniformBufferParameter CameraParameter;
   FUniformBufferParameter EntityParameter;

};   

MyShader Shader;
   
MyShaderParameters ShaderParams;  ShaderParms.cameraProj = gCamera.GetCameraProj(); etc..  

Shader.SetParameters(&ShaderParam);

A negative factor of a class per shader is well, it's a class per shader. This method would increase code size and reduce feature writing efficiency, but would surely run faster at runtime. Unreal Engine 4 uses a system like this. So with all of that out of the way, I wanted to get everyone else's thoughts, either in the Indie or AAA space, of the pros and cons, and what you implement in your own pipelines. Thank you.

 

Share this post


Link to post
Share on other sites
Advertisement
Well I'm actually targeting d3d11, but I thought that the same rules still apply. One would still need to send the constant buffer data to the shader, and the only way to do that would be to know the register that the constant buffer was bound to by querying the shader or hard coding it. Or maybe there is a better way that I seem to be missing?

Share this post


Link to post
Share on other sites

Ah, I see what you mean. I went the hardcoding route - specifying the registers directly in the shader, and binding to specific register by convention.

 

It's not terribly elegant, on some level, but it works and is pretty flexible.

Share this post


Link to post
Share on other sites

Ah, well that's good news for me to hear. That was the implementation I was going to try and do. I would have a set of core shader classes i.e, "OpaquePassVS", "OpaquePassPS", "OpaquePassHS" , "OpaquePassDS", "TranslucentVS", "TiledLightingCS" and etc, and then hard code the parameters that they are expecting to receive. I wanted to see if there was possibly a better implementation. I have been wracking my head on ways to implement shader parameter setting in a more elegant way , but this may just be one of the cases where i'm just overengineering. I wonder how larger studios would take on this implementation because writing a class on a per shader basis doesn't seem like the best solution to the given problem, but that may just be me overthinking again. Oh, Only if Frostbite was open source, but I guess a man can dream. Thank you for your help.

Share this post


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

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!