local workgroup specification while selecting alternative entrypoint

[phr34k]

To my understanding glslang presently supports for selecting an alternative entrypoints. While working with multiple compute shaders, I wondered what the correct way is to specifcy the workgroup size when their parameters differ for the respective entrypoints.

Consider the following example:

[numthreads(1,1,1)]
void shader1() {
}

[numthreads(2,2,2)]
void shader2() {
}

This would roughly be mapped like this, but also illustrates the problem. Most glsl snippets the local size is uniformly specified in global scope disassociated from the effective entrypoint so this causes double declaration problem.

layout(local_size_x = 1, local_size_y = 1,​ local_size_z = 1​) in; 
void shader1() {
}

layout(local_size_x = 2​, local_size_y = 2​, local_size_z = 2​) in; 
void shader2() {
}

One of the question I have is what is the official approach to this behavior without invoking/relying on preprocessor directives. After some quick tests I noticed this declaration statement can be inside the function body scope, that behavior seems conform the documented grammer outlined in "Ch 9. Shading Language Grammer" of "OpenGL Shading Language, Version 4.60.8".

void shader1() { layout(local_size_x = 1, local_size_y = 1,​ local_size_z = 1​) in;  }
void shader2() { layout(local_size_x = 2​, local_size_y = 2​, local_size_z = 2​) in;  }

In specific the "layout_qualifier" is reachable from the "function_definition" however lack of clear documented cases makes me question if it's actually a case of valid or undefined behavior, and/or if I can rely on traditional compiler optimisations e.g. function call elimination to negate the potentional double declaration.

layout_qualifier :
LAYOUT LEFT_PAREN layout_qualifier_id_list RIGHT_PAREN <----

single_type_qualifier :
storage_qualifier
layout_qualifier <----
precision_qualifier
interpolation_qualifier
invariant_qualifier
precise_qualifier

type_qualifier :
single_type_qualifier <----
type_qualifier single_type_qualifier

declaration :
function_prototype SEMICOLON
init_declarator_list SEMICOLON
PRECISION precision_qualifier type_specifier SEMICOLON
type_qualifier IDENTIFIER LEFT_BRACE struct_declaration_list RIGHT_BRACE SEMICOLON
type_qualifier IDENTIFIER LEFT_BRACE struct_declaration_list RIGHT_BRACE IDENTIFIER
SEMICOLON
type_qualifier IDENTIFIER LEFT_BRACE struct_declaration_list RIGHT_BRACE IDENTIFIER
array_specifier SEMICOLON
type_qualifier SEMICOLON <----
type_qualifier IDENTIFIER SEMICOLON
type_qualifier IDENTIFIER identifier_list SEMICOLON

declaration_statement :
declaration <----

simple_statement :
declaration_statement <----
expression_statement
selection_statement
switch_statement
case_label
iteration_statement
jump_statement

statement :
compound_statement
simple_statement <----

statement_list :
statement <----
statement_list statement

compound_statement_no_new_scope :
LEFT_BRACE RIGHT_BRACE
LEFT_BRACE statement_list RIGHT_BRACE <----

function_definition :
function_prototype compound_statement_no_new_scope <----

Related to:

• Support multiple entry points in a single module glslang#605
• Is --source-entrypoint intended to work with GLSL? glslang#1970

[arcady-lunarg]

This sounds more like a GLSL spec question, perhaps something that can be added via a GLSL extension and thus perhaps it is something best discussed in the GLSL repository. If you would like, I can transfer this issue there for discussion of an extension spec, which would be needed before any glslang implementation could be accepted.

[antaalt]

This could be solved with things such as :

layout(my_entry_point, local_size_x = 1, local_size_y = 1,​ local_size_z = 1​) in;
layout(entry_point=my_entry_point, local_size_x = 1, local_size_y = 1,​ local_size_z = 1​) in;

That would not break most current implementation: If its not specified, local_size are uniform to all entry point, the same it is currently. If specified, we can override specific entry point.

That could also be propagated to every layout qualifier to add specific layout parameters to specific entry points. That would allow having multiple shader stage in a single file aswell. This way, we can have a closer control for every entry point than the one we have with current HLSL.

[phr34k]

@arcady-lunarg I think you're right that it's intertwined with glsl specification, however to my knowledge alternative entrypoints is also a non-standard glslang specific (compiler-)feature, so I'm not sure if it should only be left to specification level to rectify the problem. I'd be quite okay with the solution @antaalt coins, at least to me it seems like a non-invasive solution that could likely be adapted to other scenarios where global state interferes with entry points feature.