-
Notifications
You must be signed in to change notification settings - Fork 193
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
Flip Y axis in SPIR-V frontend and backend #652
Conversation
Alright, here is the plan. The SPIR-V backend would always do this Let's consider the following scenarios:
|
Okay so, the thing is: why do we prefer one of the other? I have read in gpuweb/gpuweb#416 that there possibly would be a discussion for getPreferredOrientation which let the user specifiy the orientation. Because of this I think we need to support the direction conversion at IR/proc level, not at front- and back-end level. The IR would need to figure out if it needs to be flipped in the other direction. Be it up or down. What we can do however, is having some metadata about what direction every back-ends expect, and also have this metadata passed from the front-end. If both match when analyzing, nothing has to be done. If they don't match, flip the direction. By having this, we also support other front-ends that are not necessarily implemented at Naga, but for consumers that use their own kind of front-end (or maybe even back-end?). Where it differs from your proposal is that you want to have the control at both the front-end and back-end, and what this thought is, is about having this control at proc level. This proc will have the responsibility to convert it. |
It's not clear (at this point) if
The scheme you are describing is basically having a flag in Right now, the IR is generated once by a fronted, then validated, the extra information is generated ( Once we start going from IR(1) to IR(2), we face the following complication. The processor itself has to assume the IR(1) is valid, and potentially use So this is a part of a larger discussion: how do we do IR processing?
What we have today works so far. We may need to change it, so far it's not clear, but doing this for the Flip-Y issue doesn't sound like a good reason, since it's relatively minor. The code in this PR can be ported into a real IR processor if we decide this to be a way to go (most of the changes here are in tests, there isn't that much code). |
I totally agree with your concerning points. I didn't know about the use case that an IR itself can be potentially re-used for back-ends. The best way forward would be indeed landing this PR, and when and if we encounter more of this cases we can consider going down one of the roads that we have been proposing. I will review this PR, so we can land this. Thanks for your input! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thank you!
@Napokue thank you being vigilant! |
3714: Update naga to gfx-20 r=kvark a=kvark See gfx-rs/naga#652 (comment) Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
@kvark I currently have a I noticed some of my scenes were drawing upside down and eventually found this issue. For my workflow, would you recommend: 1.) Passing Essentially I want to write a wgpu-rs game which runs on mac/linux/windows, with shaders written in WGSL, and I'd like the game logic to always assume positive Y is "up" in normalized device coordinates. Thanks for your help! |
I strongly recommend (2). There is substantially less work for wgpu/gfx to work with WGSL than to SPIR-V. We are still trying to figure out some of the nasty spots about SPIR-V control flow. |
Got it! I had no idea, bad assumption on my part. Thanks for the recommendation, and again for all your work on the rust graphics ecosystem :D |
Fixes #651
Unblocks gfx-rs/gfx#3707
Our IR has the coordinate system that matches everything but Vulkan. So in order to correctly translate, we need to flip the Y of vertex outputs in both SPV-in and SPV-out.
This is a draft because I'm still trying to figure out what flags are needed to be exposed to control this.