Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify discarded expressions of uniform block reference through instance name only #3644

Open
kkinnunen-apple opened this issue Apr 18, 2024 · 5 comments · May be fixed by #3693
Open

Clarify discarded expressions of uniform block reference through instance name only #3644

kkinnunen-apple opened this issue Apr 18, 2024 · 5 comments · May be fixed by #3693
Assignees

Comments

@kkinnunen-apple
Copy link
Contributor

kkinnunen-apple commented Apr 18, 2024

Consider uniform block declaration with a instance-name:

uniform MyBlock { int x; int y; } b;

The spec spends effort to disallow using b without any field access. You aren't allowed to use MyBlock, so it is not easy to refer to plain b in a valid program.

Except, you can use it in a discarded statement expression, like b; or in a comma expression like somethingsomething, b;

This is a problem because some rewrite steps don't anticipate uniform blocks, and ANGLE assert with these.

Would it be in the spirit of the spec to fail these programs, or should they pass?

As per my reading, that could affect the statically used uniform counts? However, I can't parse the spec to understand if individual members of an uniform block are affected with different static use counts. E.g. if I refer to b.x; does it mean that b.y can be optimized away if not used? Would b; in this case mean that all uniform variables of that block are statically used.

https://registry.khronos.org/OpenGL/specs/es/3.0/GLSL_ES_Specification_3.00.pdf

For uniform blocks, the application uses the block name to identify the block. Block names have no other use within a shader beyond interface matching; it is an error to use a block name at global scope for anything other than as a block name (e.g., use of a block name for a global variable name or function name is currently reserved). It is a compile-time error to use the same block name for more than one block declaration in the same shader interface (as defined above) within one shader, even if the block contents are identical.

@kkinnunen-apple
Copy link
Contributor Author

The discussion in 2024-04-18 meeting was that it likely would be invalid to refer to uniform block instance itself.
The discussion was that we would wait for OpenGL WG to discuss the issue.

@kkinnunen-apple
Copy link
Contributor Author

@lexaknyazev
Copy link
Member

OpenGL ES 3.0, Section 2.12.16:

All members of a named uniform block declared with a shared or std140 layout qualifier are considered active, even if they are not referenced in any shader in the program. The uniform block itself is also considered active, even if no member of the block is referenced.

WebGL 2.0:

The GLSL ES 3.00 specification supports the shared, packed, and std140 layout qualifiers for uniform blocks, defining how variables are laid out in uniform buffers' storage. Of these, the WebGL 2.0 specification supports only the std140 layout ...


I think it means that a discarded instance name has no effect on uniform usage limits - all members of such blocks are always considered active in WebGL.

@kenrussell
Copy link
Member

Per WebGL conference call from 2024-09-05, the next action on this issue is to write a new conformance test confirming the behavior. The OpenGL working group plans to update their specification, so there is no current plan to update the WebGL spec.

@kdashg kdashg self-assigned this Sep 19, 2024
@kdashg
Copy link
Contributor

kdashg commented Sep 19, 2024

I'm writing this

kdashg added a commit to kdashg/WebGL that referenced this issue Sep 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants