GLSLProgram::extractLayoutQualifiers() needed?

Discussion area about developing with Ogre-Next (2.1, 2.2 and beyond)


User avatar
bishopnator
Goblin
Posts: 299
Joined: Thu Apr 26, 2007 11:43 am
Location: Slovakia / Switzerland
x 11

GLSLProgram::extractLayoutQualifiers() needed?

Post by bishopnator »

Hi, when I am debugging the GLSL shaders, I am getting some strange assertions from the above function. I was surprised that the GLSL shaders created by HlmsPbs and HlmsUnlit are not hitting those assertions and narrow the behavior to this line:

Code: Select all

layout(std140) uniform;

The implementation in GLSLProgram::extractLayoutQualifiers() parses this line and then aborts the parsing:

Code: Select all

                StringVector parts = StringUtil::split( line, " " );

            if( parts.size() < 3 )
            {
                // This is a malformed attribute.
                // It should contain 3 parts, i.e. "attribute vec4 vertex".
                break;
            }

In my shaders I didn't write this statement "layout(std140) uniform" and hence it tried to continue the parsing. The first assertion it hits with the following line:

Code: Select all

layout(binding = 0, std430) readonly buffer worldMatricesBuf

Is this function still needed? For HlmsPbs and HlmsUnlit it does nothing. The behavior strongly depends on the way how the shader is written - even if there is a line "// layout(std140) uniform" (so commented out), the method aborts. Splitting the line using spaces is also strange as the spaces are not required by GLSL at some places - like "layout(binding=0)" is same as "layout ( binding = 0 )" and the behavior of the mentioned function is strongly influenced.

User avatar
bishopnator
Goblin
Posts: 299
Joined: Thu Apr 26, 2007 11:43 am
Location: Slovakia / Switzerland
x 11

Re: GLSLProgram::extractLayoutQualifiers() needed?

Post by bishopnator »

I found in a ogre wiki link to this old post viewtopic.php?f=25&t=83763 which mentioned also this problem with assertion. It is interesting that it is from 2015. Due to usage of layout qualifier to specify default alignment rules, the code is not active and it seems that it is mandatory to specify it to avoid those assertions (and get the proper offsets for the variables without necessity of querying it from the GL driver).

Still the question remains - the parser is very old and it is not too general as it relies on the proper spacing / formatting of the lines with layout qualifier and the format was heavily extended in the newer OpenGL versions. Added the default layout specification just disables the call.

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5433
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1341

Re: GLSLProgram::extractLayoutQualifiers() needed?

Post by dark_sylinc »

That parser is scary :oops:

It's from Ogre 1.x code that I'm keeping just in case. I'm basically taking a "if it's not broken, don't fix it" attitude towards that function.

It seems to be needed to find what vertex inputs are being used by legacy V1 materials: It's output is used in getAttributeIndex, which is used in GL3PlusRenderSystem::bindVertexElementToGpu, which is only used by v1 vertex operations by _render( const v1::RenderOperation &op ).

This overload is mostly used by Compositor's PASS_QUAD operations with low level materials (i.e. the Postprocessing and HDR samples are likely the one that stress test this the most).

As long as it doesn't break anything change it however you like.

This is basically kept for really old backwards compatibility + PASS_QUAD operations.

User avatar
bishopnator
Goblin
Posts: 299
Joined: Thu Apr 26, 2007 11:43 am
Location: Slovakia / Switzerland
x 11

Re: GLSLProgram::extractLayoutQualifiers() needed?

Post by bishopnator »

I will inject the "layout(std140) uniform;" to the GLSL to deactivate the function as you (or who?) did in HlmsPbs/HlmsUnlit. I found also those connections in ogre-next .. I think it should be probably in future somehow rewritten or use another GLSL parser with reflections to get those information out of the GLSL shader.

As I am not planning to use V1 materials, I will leave it as it is :-)