septag / glslcc Goto Github PK

I've just started using the codebase so apologies if I'm missing something, but consider the following code in glslcc.cpp:

static bool parse_output_log(const char* str, std::vector<output_parse_result>* r) { const char* header = "ERROR: "; while (sx_strstr(str, header) == str) { str += sx_strlen(header); const char* divider = sx_strchar(str, ':'); <snip> r->push_back(lr); } return true; }

In my shader, the first output message in str is a "WARNING: ", not an "ERROR: ". The result appears to be that we write nothing to the output_parse_result vector as we only parse the array as far as the first non-error message and all further messages are ignored.

Hello is there any way to put as an input a .shader file (unity) ??

Hello,

There is two glslang automap options that should be interesting in this tool:

shader->setAutoMapBindings(true);
shader->setAutoMapLocations(true);

This remove binding and location requirement in shader.

Hi,

Excellent job on library, I'm working on personal game engine and come to your shader compiler, I added the HLSL stage semantics support (POSITION, COLOR0 etc) and it fits well.

Question is,
How you handle shader bindings? While vulkan has set and binding for uniform buffers, samplers etc, HLSL and DirectX has stage binding, do you plan to add some schema/trick for this part as well?

Thanks

It seems that glslcc is reordering the vertex layout according to usage when transpiling to MSL:

#version 450
layout (location = 0) in vec2 Position;
layout (location = 1) in vec2 UV;
layout (location = 2) in vec4 Color;

/* uniforms and outputs here... */

void main()
{
    Frag_UV = UV;
    Frag_Color = Color;
    gl_Position = Projection * vec4(Position.xy,0,1);
}

Gives me this input in MSL:

struct main0_in
{
    float2 UV [[attribute(0)]];
    float4 Color [[attribute(1)]];
    float2 Position [[attribute(2)]];
};

The attribute order is the usage order in the code, not the original location. If I change the source's main() to:

void main()
{
    gl_Position = Projection * vec4(Position.xy,0,1);
    Frag_UV = UV;
    Frag_Color = Color;
}

I get the 'correct' order.

When converting compute shaders to gles profile 310, glslcc converts multi-dimensional arrays to one-dimensionsal and adjusts index expressions accordingly. Unfortunately, the adjusting index multiplier constants lack type qualifiers, leading to load errors such as:

error: could not implicitly convert operands to arithmetic operator
error: operands to arithmetic operators must be numeric

Example:

$ cat binning.comp 
#version 450
layout(local_size_x = 256, local_size_y = 1) in;

shared uint bitmaps[8][256];

void main() {
    for (uint i = 0; i < 8; i++) {
        bitmaps[i][gl_LocalInvocationID.x] = 0;
    }
}
$ glslcc --compute binning.comp --lang gles --profile 310 -o blah && cat blah_cs
binning.comp
#version 310 es
layout(local_size_x = 256, local_size_y = 1, local_size_z = 1) in;

shared uint bitmaps[8 * 256];

void main()
{
    for (uint i = 0u; i < 8u; i++)
    {
        bitmaps[i * 256 + gl_LocalInvocationID.x] = 0u;
    }
}

Note how the constant 256 in i * 256 + gl_LocalInvocationID.x lacks a type qualifier; replacing it with 256u avoids the load error.

Hello, Thanks for your great works.

I just wanna know if i can use this library as cpp api by loading it.
I couldn't find api functions, It looks just supporting command line interface.

Or do you have ways to get translated code string from glslcc?

Hey again,
Just used your own samples and they refused to work:

> glslcc --vert=shader.vert --frag=shader.frag --output=shader.hlsl --lang=hlsl --reflect
ERROR: sample.vert:5: '' : vertex input cannot be further qualified
ERROR: sample.vert:5: '' : compilation terminated
ERROR: 2 compilation errors.  No code generated.

I have the following vertex shader inputs -

layout (location = 0) in vec3 a_position;
layout (location = 1) in vec3 a_normal;
layout (location = 2) in vec4 a_color;
layout (location = 3) in mat4 joint;
Using glslang to produce SPIR-V and then invoking SPIRV-cross targeting metal, the following MSL is produced -

struct main0_in
{
float4 joint_0 [[attribute(0)]];
float4 joint_1 [[attribute(1)]];
float3 a_position [[attribute(1)]];
float4 joint_2 [[attribute(2)]];
float3 a_normal [[attribute(2)]];
float4 joint_3 [[attribute(3)]];
float4 a_color [[attribute(3)]];
};

Which produces the following error when the msl is compiled -

error: 'attribute' index '1' is used more than once
I tried setting joint to location 0 and position, normal and color to 4 5 and 6 respectively, but the same code was generated.

Am I doing something wrong here, or is this a legitimate issue?

I have come to the following problem while trying to cross-compile from glsl to hlsl bytecode (D3D11).

One of my shaders contains the following code

int index = int(fsIn.tTexture); //casting from float to int
    switch(index)
    {
        case 0:
            return u_Textures[0].Sample(...);
        case 1:
            return u_Textures[1].Sample(...);
     ...

This is all fine if it is ported the same way in hlsl, however, it gets shortened to

int _21 = int(Texture);
FragColor = u_Textures[_21]

Which is not valid D3D11 hlsl code.

Any possible workarounds without having to rewrite the shaders completely?

May thanks.

Hey @septag

Just trying to compile your tool :D

It gave following error when linking:
sxd.lib(os.obj) : error LNK2019: unresolved external symbol _GetProcessMemoryInfo@12 referenced in function _sx_os_processmem [glslcc\.build\src\glslcc.vcxproj]

So I added #pragma comment(lib, "psapi.lib") somewhere to fix it :)

PS: Suggestion: what about providing binary releases?

My bad.

Hi there, not really an issue, but is there a chance you could add built binaries to the repo?

Guessed OK, since GLES could be treated as a subset.