Request for official OpenGL support

[Ollhax]

I want to raise the question on adding official support for OpenGL's flavor of GLSL shaders. I've been using Slang for a while for my OpenGL game and it's working fine most of the time. I've reported some hiccups but had no major issues, most of the GLSL works just fine in OpenGL. My most recent issue is the first time I've encountered something that requires a workaround (or a contribution - I'm hoping I can find some time for that). But I am concerned that I'll run into a larger roadblock later and that I'll have to rewrite my shaders.

I do not know what the demand for OpenGL's GLSL is, but at least from my experience most of it is already working, so perhaps reaching a level of full support would not be that much work?

[mkeshavaNV]

@Ollhax - GLSL is supported for the most part. Other than issues like #7247, do you foresee any major roadblocks?

[gtong-nv]

@Ollhax, thank you for raising this issue. Slang is rapidly evolving, and at this time, we are not ready to claim full OpenGL support. If you encounter any major roadblocks, please let us know—we will do our best to address them.

[Ollhax]

Understood! The biggest issue so far is the GroupMemoryBarrierWithGroupSync() problem I mentioned, it prevents me from doing more fine-grained compute shader work.

I'll post here when I encounter new issues.

[ArielG-NV]

@Ollhax
To unblock according to what has been described, you can define and use the following function:

[require(cuda_glsl_hlsl_metal_spirv_wgsl, memorybarrier)]
void OpenGLGroupMemoryBarrierWithGroupSync()
{
    __target_switch
    {
    case glsl: 
        __intrinsic_asm "groupMemoryBarrier(); barrier()";
    default:
        GroupMemoryBarrierWithGroupSync();
    }
}

Playground link

[Ollhax]

@Ollhax To unblock according to what has been described, you can define and use the following function:

That's great, I didn't know that was possible! Thank you for the help.

[ArielG-NV]

Your welcome.

[tim-rex]

I came here looking for the same.. possible duplicate of #6142 ? (nevermind, just noticed this is a discussion item rather than an issue)

I'm having trouble at the first hurdle myself with built-in blocks not being redeclared

ARB_separate_shader_objects requires built-in block gl_PerVertex to be redeclared before accessing its members

I'm also wondering if it isn't better to try targeting spirv for OpenGL 4.6 as per #4257

[jkwak-work]

Can you open an issue with a repro shader so that we can follow it up properly.

[Ollhax]

I'm reworking my shaders to use generated binding numbers (layout(binding = ...)) rather than manually specified ones, and Ive hit a number of issues:

• I need to keep track of the max number of supported objects, and for e.g. SSBOs (through StructuredBuffers) the standard guarantees only 8 of them. I had assumed that I can set any binding index and as long as I don't bind more than 8 in total I'd be fine, but it seems like it's the index that matters - i.e. I have indices 0-7 to work with. This is a minor annoyance, I need to go back to setting indices manually or making sure the StructuredBuffers are listed first in the file.
• Slang generates binding numbers in the same space for samplers and other objects like uniforms. In OpenGL these are separate number spaces, it's okay to bind samplerA to 0 and uniformA to 0 at the same time. I can't even specify bindings manually in this case, slang complains that the bindings collide. This leads to some wasted slots, but it's not a big deal for me since the minimum object counts are fairly high.
• When I declare an array of samplers it sets a binding for the array, but does not bump the binding index by the array size like I would have expected. E.g:

Sampler2D colorPalette; // Binding 0
Sampler3DUI[2] colorIndices; // Binding 1
Sampler2D someOtherSampler; // Binding 2 - I assumed it'd be 3!

All of these are fairly easy to work around, but I just wanted to mention the problems here.

[jkwak-work]

Can you open an issue with a repro shader so that we can follow it up properly.

[Ollhax]

Done: #8149 and #8150

[Ollhax]

I ran into a new issue. The problem occurs when linking a shader's vertex and fragment stages:

error: struct fields mismatch between shaders for uniform (named block_EnvironmentConstants_std140_0)

The vertex and fragment shader both use this struct:

public struct EnvironmentConstants
{
	// (All irrelevant fields removed)
	float4x4 LightDirectionalWorldToProjection;
};

If I dig into the generated glsl code for the vertex and fragments shaders they both use this block:

layout(std140) uniform block_EnvironmentConstants_std140_0
{
    _MatrixStorage_float4x4std140_0 LightDirectionalWorldToProjection;
}environment_0;

The block_EnvironmentConstants_std140_0 struct looks the same but the generated _MatrixStorage_float4x4std140_0 differ:

struct _MatrixStorage_float4x4std140_0
{
    vec4  data_3[4];
};

and

struct _MatrixStorage_float4x4std140_0
{
    vec4  data_0[4];
};

Note that one is data_0, the other data_3. This is unfortunately enough to throw off the linker.

It’s unfortunate that it generates a type for the float4x4 matrices rather than just outputting a mat4.
I tried using the compiler API to generate the fragment and vertex shader in one call, but it did not help.

My current workaround is to specify matrices as four float4's instead when I get this problem:

public struct EnvironmentConstants
{
	public float4 LightDirectionalWorldToProjection0;
	public float4 LightDirectionalWorldToProjection1;
	public float4 LightDirectionalWorldToProjection2;
	public float4 LightDirectionalWorldToProjection3;

	public property float4x4 LightDirectionalWorldToProjection { get { return float4x4(LightDirectionalWorldToProjection0, LightDirectionalWorldToProjection1, LightDirectionalWorldToProjection2, LightDirectionalWorldToProjection3); } }
};