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

[glsl-in] Validation fixes #898

Merged
merged 7 commits into from
May 25, 2021
Merged

[glsl-in] Validation fixes #898

merged 7 commits into from
May 25, 2021

Conversation

JCapucho
Copy link
Collaborator

@JCapucho JCapucho commented May 22, 2021

Fixes #884
Fixes #887

Fixes included

  • The output struct no longer produces a VaryingError
  • Builtins are checked if they can be emitted in the stage now
  • Globals now have proper storage access
  • Single argument vector and matrix constructors now support dimension casting
  • The lod value in TextureLod is now casted
  • Parameter qualifiers now set the type of the argument
  • Default interpolation is now provided

@JCapucho
Copy link
Collaborator Author

For whoever reviews this the commit message for the commits fixing the vector/matrix constructors and the one fixing the parameter qualifier have some more information in them

@JCapucho JCapucho marked this pull request as draft May 22, 2021 20:47
@JCapucho JCapucho force-pushed the glsl-fixes branch 2 times, most recently from a05f1ba to b3bfc23 Compare May 22, 2021 21:23
@JCapucho JCapucho marked this pull request as ready for review May 22, 2021 21:23
@@ -524,6 +525,26 @@ impl Program<'_> {
}
}

fn should_read(built_in: BuiltIn, stage: ShaderStage) -> bool {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like a list that the validator uses. Let the validator take care of this. Here, if you need to exclude specific things, then make it an exclusion list specifically, instead of listing all the possibilities.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem here is that the validator complains if a builtin is added as a function argument in a stage where it shouldn't

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't quite understand. If you have an entry point in GLSL that's using some built-in, then just add it to the arguments. If it's not using this built-in, and you aren't adding it to the arguments, then the validator have nothing to complain about.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You have the case where the built in is being used but shouldn't be written for example (vertex stage)

void main() {
  gl_Postition = vec4(1);
}

without this fix the backend would produce this pseudocode

vec4 position;

void wrapper(
  [builtin=position] vec4 x
) -> [builtin=position] vec4 {
  position = x;
  main();
  return position;
}

void main() {
  position = vec4(1);
}

this is invalid because position can't be read in the vertex stage, with this change the generated pseudocode would look like this

vec4 position;

void wrapper() -> [builtin=position] vec4 {
  main();
  return position;
}

void main() {
  position = vec4(1);
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for writing this down! I think there is a problem in the first step. Why does the pseudocode have "position = x" at all? When GLSL is parsed, we should see that gl_Position (not specifically it, anything goes) is on the left side of an assignment, so there is no reading going on.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The frontend doesn't keep global use information even though it should because with multiple stages we can't blindly emit globals arguments, I think we should add this for now and I'll make another PR which collects the global use of the functions and the functions it calls recursively and only emit the loads and the stores for the return based on it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. Ok, in this case, let's add a TODO above this function to follow-up.

src/front/glsl/ast.rs Outdated Show resolved Hide resolved
src/front/glsl/parser.rs Outdated Show resolved Hide resolved
src/front/glsl/variables.rs Show resolved Hide resolved
src/front/glsl/variables.rs Outdated Show resolved Hide resolved
src/front/glsl/variables.rs Outdated Show resolved Hide resolved
@kvark
Copy link
Member

kvark commented May 24, 2021

Thank you for addressing the concerns! I think only "should_read" stuff is left to discuss.

JCapucho added 6 commits May 25, 2021 17:41
Matrix and vector constructors expected a vector (in the case of the
matrix) or a scalar (in both cases). Now they handle resizing such that
the following code now works

```glsl
mat3 a;
mat4(a); // This would return a validation error because it emitted a cast
```
Previously the types where changed in a later phase now they are changed
right when the argument is added, this makes the implementation slightly
less spec compliant because the following code will compile whilst it shouldn't

```glsl
void test(float a) {}
void test(out float b) {}
```
@JCapucho
Copy link
Collaborator Author

@kvark it should be ready for merging now

@kvark kvark merged commit f57739d into gfx-rs:master May 25, 2021
@JCapucho JCapucho deleted the glsl-fixes branch July 5, 2021 11:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants