Implement compute shaders support, make fragment shader non-mandatory

[VReaperV]

Requires #1124.

Cherry-picked from #1137 to split a large pr up a bit.

Adds some code to allow using compute shaders. Shaders can now have either of vertex, fragment, or compute shaders enabled/disabled.

[slipher]

It seems like compute shaders are a totally separate workflow from the existing draw shaders, which would ideally be a separate class. Like instead of just GLShader you have one class with fragment shader, vertex shader, and vertex attribs; and another with just compute shader.

[VReaperV]

It seems like compute shaders are a totally separate workflow from the existing draw shaders, which would ideally be a separate class. Like instead of just GLShader you have one class with fragment shader, vertex shader, and vertex attribs; and another with just compute shader.

I considered that, the reason I made it part of GLShader is that they can still make use of the way uniforms are set, vertex/fragment includes, same paths for loading/compiling shaders including shader binaries, as well as GLHeaders. Maybe both classes should be derived from GLShader which would just provide the aforementioned functionality.

[slipher]

A really easy way to make things a bit clearer could be to have two constructors for GLShader, one for each use case. Instead of having a constructor that allows all 3 shader types at once.

[VReaperV]

So something like

GLShader( const std::string &name, const std::string &mainShaderName, uint32_t vertexAttribsRequired, GLShaderManager *manager,
const bool hasVertexShader, const bool hasFragmentShader)

and

GLShader( const std::string &name, const std::string &mainShaderName, uint32_t vertexAttribsRequired, GLShaderManager *manager,
const bool hasComputeShader

?

[slipher]

I guess there's nothing that distinguishes the constructors very well so maybe it would be easier to go ahead and define the subclasses even if all the functionality is in the base class. Like

class GLShaderBase {
    // everything that's in GLShader right now
};
class GLShader : public GLShaderBase { //draw shader
   // constructor does _hasFragment = true, _haveVertex = true?
};
class ComputeShader : public GLShaderBase {
    // constructor does _hasCompute = true
};

[VReaperV]

Yeah, I ran into some issues with GLShader constructors earlier too, since the wrong one was being selected with some types being converted.

[VReaperV]

I guess there's nothing that distinguishes the constructors very well so maybe it would be easier to go ahead and define the subclasses even if all the functionality is in the base class. Like

class GLShaderBase {
    // everything that's in GLShader right now
};
class GLShader : public GLShaderBase { //draw shader
   // constructor does _hasFragment = true, _haveVertex = true?
};
class ComputeShader : public GLShaderBase {
    // constructor does _hasCompute = true
};

This should be evaluated later because #1105 and some further PRs add more GLShader constructors.

[illwieckz]

LGTM.

[illwieckz]

Don't forget to squash the fix commit. ;-)

[VReaperV]

Yep, done.