-
-
Notifications
You must be signed in to change notification settings - Fork 21.4k
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
vulkan: Update all components to Vulkan SDK 1.3.283.0 #92010
Conversation
Re-done patch to spirv-reflect: |
b31df77
to
9c60045
Compare
Thanks, added to the PR. Should be good to go then. |
@bruvzg The macOS and iOS builds for glslang are failing with:
Sounds like using this glslang version would force us to bump our min macOS and iOS releases. Edit: Filed a bug report upstream: |
Vulkan (with a feature set used by Godot) won't properly work on macOS 10.14 and iOS 12, it's only for OpenGL backend. Both versions are unsupported for a long time (but current Xcode still can target both), so I'm not sure if there's much reason to keep supporting it, or bump the min versions. |
It probably doesn't make sense to attempt using our Vulkan/Metal renderers on macOS 10.14 or iOS 12 indeed, but for OpenGL I think it may still make sense if we can preserve compatibility. Judging by https://gs.statcounter.com/ios-version-market-share/ stats, iOS 12.5 (which seemed to be a LTS and only got EOL'ed in Jan 2023) still has around 1.5% market share among iOS users: For macOS, stats from the same website: https://gs.statcounter.com/macos-version-market-share/ |
Seems like it only for output prints with the specific flag, so we can patch it locally by removing |
9c60045
to
12066fd
Compare
if(loc.getFilename() == nullptr && shaderFileName != nullptr && absolute) { | ||
//append(std::filesystem::absolute(shaderFileName).string()); | ||
} else { | ||
std::string location = loc.getStringNameOrNum(false); | ||
//if (absolute) { | ||
// append(std::filesystem::absolute(location).string()); | ||
//} else { | ||
append(location); | ||
//} | ||
} |
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.
Made this small hack to restore compat for older Apple platforms, until the issue is resolved upstream or we decide to increase our min supported versions to drop iOS 12.0 and macOS 10.13 and 10.14.
That's some strange data, seem to include only outdated and unsupported versions of macOS, currently only Monterey (12) and newer are getting security updates. |
Yeah I think they simply didn't update their heuristics when macOS bumped from 10.15 to 11.0, so they seem to track all >= 10.15 into "Catalina". The data for older releases may still be somewhat reliable. |
Getting a test failure which does sound related to this PR:
|
12066fd
to
9fec403
Compare
I just rebased, and updated VMA to the newly tagged 3.1.0 release (no change compared to previous git snapshot in that PR). So I assume the CI will still fail similarly. Then I'll try reverting VMA to the previous version (that we have in the |
So reverting VMA to an older commit fixed it, i.e. this commit (which I'll now remove): 2b466bd The error on CI is:
And that's consistent with the fact that the VMA update mostly adds support for I don't know much about that, but maybe @DarioSamo or @RandomShaper could have a look at what we're missing? |
2b466bd
to
9fec403
Compare
This patch may do the trick:
Explanation: with Vulkan >= 1.3, Not tested, so, well, TIWAGOS. PS: There are other VMA creation flags related to extensions that we may want to set in case those are either implicitly enabled or explicitly by us in case they're available so maybe VMA can do a better job somehow. |
9fec403
to
7479f84
Compare
I gave it a try in the latest commit (7479f84), but that doesn't seem to solve it, it still fails at the same API test:
|
I can't reproduce on Windows. However, I've found that this is something else we'd want to do when initializing It stops VMA from assuming we're using Vulkan 1.0, and so lets it collect pointers to certain functions that make some operations more efficient. Can you test it and see if it interacts with the issue at hand? |
7479f84
to
ea471e8
Compare
Tried it, that doesn't seem to fix it either. I managed to reproduce the issue locally on Linux with a regular dev build from this branch, running the command from the test project in a new project:
It's not showing me the assert message for some reason but it crashes all the same:
|
That's been useful! The problem is that piece of script is trying to create a texture with not a single usage bit specified. See #92587. |
ea471e8
to
a99e6f1
Compare
That did the trick! Should I keep the changes we made to |
8d6cd62
to
9f5aeb2
Compare
Good question! The one in the patch is needed as part of the update. However, the other line of code is not strictly part of the scope of this PR. It may be better to keep it as a separate commit. Besides, it's good to have the ability to frame that other change in a bisect. |
Pass `VMA_ALLOCATOR_CREATE_KHR_MAINTENANCE5_BIT` to VMA when using Vulkan 1.3 features. Co-authored-by: Pedro J. Estébanez <pedrojrulez@gmail.com>
9f5aeb2
to
940d629
Compare
Draft as I need help to rediff the SPIRV-Reflect specialization constant patch. CC @godotengine/rendering
You can help me by checking out this PR, trying to apply
thirdparty/spirv-reflect/patches/specialization-constants.patch
withpatch -p3 < thirdparty/spirv-reflect/patches/specialization-constants.patch
, and then figuring out how to resolve the hunks that couldn't be applied. Once the changes are good, you can dogit diff > mydiff
and copy that file on top ofthirdparty/spirv-reflect/patches/specialization-constants.patch
, to include in the commit.It seems like upstream added a (more minimal?) spec constant struct with the same name, so we likely need to fold our changes into their new API:
Worth noting that there are two open PRs upstream to add the kind of spec constants support we have, which we could help drive to completion / merge:
SpecConstant
support KhronosGroup/SPIRV-Reflect#154 (derived from @reduz's Implement specialization constants #50325)