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-out] Emit globals of any type, as required by Naga IR. #1823

Merged
merged 5 commits into from
Apr 14, 2022

Conversation

jimblandy
Copy link
Member

Fixes #1811.

@jimblandy
Copy link
Member Author

jimblandy commented Apr 13, 2022

Draft because:

  • needs tests
  • should be split up into cleaner commits

@jimblandy jimblandy force-pushed the glsl-flexible-global-types branch from 0ef61e4 to 4cd8f0a Compare April 13, 2022 01:38
@jimblandy jimblandy marked this pull request as ready for review April 13, 2022 01:55
@jimblandy jimblandy requested a review from JCapucho April 13, 2022 01:55
// unsized arrays can only be in storage buffers, for which we use `ByteAddressBuffer` anyway.
continue;
}
if module.types[members.last().unwrap().ty]
Copy link
Collaborator

Choose a reason for hiding this comment

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

An empty struct in input shader will break this code? I think it would be better to use if let Some(member) = members.last() ....

Copy link
Member Author

Choose a reason for hiding this comment

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

Empty structures are forbidden in WGSL, and I thought the validator enforced this - but it does not. GLSL doesn't allow empty structures either, but SPIR-V does (and Vulkan doesn't seem to add any further restrictions about that).

But for the time being, since we do have empty structs passing through Naga, I'll change this and the other sites.

Copy link
Member Author

Choose a reason for hiding this comment

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

@kvark suggested just banning empty structs in validation; that's implemented in #1826.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Can we avoid unwrap here and return EmptyStruct error instead? In case where validation is disabled (it disabled by default).

Copy link
Collaborator

Choose a reason for hiding this comment

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

The general stance backends have over panicking is that it's fine if the IR is illegal there are multiple cases where we panic if the IR isn't good, just grep unwrap, if validation isn't enabled it's the responsibility of the user to ensure it's legal, otherwise the behavior may include panics.

Copy link
Member Author

Choose a reason for hiding this comment

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

That principle makes sense; I've submitted #1828 to write it down.

src/back/glsl/mod.rs Show resolved Hide resolved
src/back/glsl/mod.rs Show resolved Hide resolved
Copy link
Collaborator

@JCapucho JCapucho left a comment

Choose a reason for hiding this comment

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

Besides what Gordon already pointed out I have some more worries about this changes.

src/back/glsl/mod.rs Outdated Show resolved Hide resolved
src/back/glsl/mod.rs Show resolved Hide resolved
Copy link
Collaborator

@JCapucho JCapucho left a comment

Choose a reason for hiding this comment

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

everything looks good on my part now

No change in behavior. Exhaustive matches aid error detection, and are
clearer when the number of match arms isn't excessive.
"Storage qualifier" is the term used in the GLSL ES specification.
Delete `GlobalTypeKind`.

Break out `Writer::write_global`'s code into two new functions,
`write_simple_global` and `write_interface_block`. This introduces
some repeated code, but the way we need to produce interface blocks
and normal globals are sufficiently different that I think it's
clearer overall to just separate them entirely. Much of the details
are handled by their callees.

Loosen the interface block code to support arbitrary types.
@jimblandy jimblandy force-pushed the glsl-flexible-global-types branch from cd83790 to b36b67e Compare April 14, 2022 16:44
@jimblandy jimblandy merged commit 27d0fee into gfx-rs:master Apr 14, 2022
@jimblandy jimblandy deleted the glsl-flexible-global-types branch April 18, 2022 17:06
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 this pull request may close these issues.

GLSL backend can't handle matrix-typed globals
3 participants