Find a solution for shader language support

[emberian]

Different graphics APIs have their own shading languages or ideas for what a shading language should be. In our quest to support multiple backend APIs, we need a way to unify these.

[emberian]

One idea is to just query for the backend in use and have the user themselves supply a shader per API.

[emberian]

Another is to use a single shader language and translate to whatever the backend needs. HLSL might be a mature choice here. (Valve has a tool available but I'm not sure how quality it is, and it only supports Shader Model 3.)

[emberian]

Another is to make our own shading language, but that just sounds like a bad idea.

[brendanzab]

A HM typed concatenative language!

jk.

[Kimundi]

I'm currently toying around with a "umbrella" struct for providing the source of the same logical shader in different languages. Nothing fancy, something like this:

pub enum DeviceShader {
    StaticBytes(&'static [u8]),
    OwnedBytes(Vec<u8>),
    NotProvided
}

pub struct ShaderSource {
    pub glsl_120: DeviceShader,
    pub glsl_150: DeviceShader,
    hlsl_sm_3: DeviceShader
    ...
}
...
static VERTEX_SRC: ShaderSource = shaders! {
GLSL_120: b"
    #version 120
    attribute vec2 a_Pos;
    varying vec4 v_Color;
    void main() {
        v_Color = vec4(a_Pos+0.5, 1.0, 1.0);
        gl_Position = vec4(a_Pos, 0.0, 1.0);
    }
"
GLSL_150: b"
    #version 150 core
    in vec2 a_Pos;
    out vec4 v_Color;
    void main() {
        v_Color = vec4(a_Pos+0.5, 0.0, 1.0);
        gl_Position = vec4(a_Pos, 0.0, 1.0);
    }
"
};

That should at least make it possible to hack some legacy compatibility into the libs without giving up on the newer shader versions at all.

[brendanzab]

#72 gets us some of the way there.

[kvark]

Found a good link for that: Cross Platform Shaders in 2014

[emberian]

I think what we have today is as good as we are going to get. Anything else can be built on top of it, externally, and possibly merged back in.

[kvark]

Shaders become one of the major usability bottleneck of gfx-rs. Let's continue this discussion, even if the code for it will end up in a separate library.