-
Notifications
You must be signed in to change notification settings - Fork 29.7k
Don't hardcode ink sparkle SPIR-V #102674
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
Conversation
ef53dcc to
be137a9
Compare
|
@dnfield @jonahwilliams About the failing framework_tests_misc and framework_tests_libraries, do you happen to know how to get them to load the shader asset? |
|
Also cc @goderbauer @clocksmith This also still needs tool tests. |
|
We'd have to have each test manually load the asset. You could do that by overriding the root bundle and loading the bytes in with synchronous I/O. Unless we have a helper somewhere I've forgotten about |
be137a9 to
8cc2ecd
Compare
|
The flutter tool can actually build an asset bundle for the test runner, but the problems are that this doesn't go down the same exact path as copyAssets and that technically the flutter framework doesn't have use-material-design on - since that would imply all apps that use flutter would use material design. Anyway, here is a small diff to work from, this outputs the compiled spirv in an easier to get to directory which you might be able to get at with regular asset loading: |
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.
How confident can we be that this won't get accessed before the future completes?
How important is it to synchronously access this value?
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.
In particular, it lookslike the only actual callsite of this is line 524 above which is in an async method already. We should either expose this as a future or just remove it.
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.
newline at EOF
4d38885 to
dbc26ce
Compare
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.
This still isn't safe but we're no worse off than we used to be. We should file an issue to deprecate this and remove it. It's not safe for anyone to use.
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.
@dnfield Can you be more specific about what isn't safe, and what should be removed?
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.
Sorry, providing sync access to a late initialized variable that gets initialized in a future.
So if some program invokes the getter below here that refers to this static late var before the future completes, it will get a late initialization exception and it has no way to know if that getter is safe to call yet or not.
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.
Ah, I see. I think a bigger refactor to how these work is needed. In particular, the async nature of the shader load should probably be exposed in such a way that app developers know that they need to get it done before applying the shader in a widget tree. I'm not going to attempt that in this PR.
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.
Will that still be necessary once impeller is just using these as precompiled blobs?
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.
Do we need them as bytes, or could we load them in some other opaque format? I did re-open flutter/engine#32999 which would let you load assets into immutable buffers synchronously
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.
I guess technically we should be doing that async anyway to avoid jank on low end devices
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.
@dnfield What is the unsafe code pass? The only way to obtain an instance of this is to await the inkSparkle "static factory" above. At that point, it is guaranteed that _program is initialized, no?
(Side-note: I think compile should be a private method since it should only be invoked by inkSparkle?)
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.
(we could assert that _program is initialized in the inkSparkle method before the return)
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.
Ahhhh I see, in that case this is fine. I missed that part because of the way GitHub collapsed part of the diff...
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.
| ShaderCompiler({ | |
| ShaderCompiler({ |
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.
| }) : assert(processManager != null), | |
| assert(logger != null), | |
| assert(fileSystem != null), | |
| assert(artifacts != null), | |
| _processManager = processManager, | |
| }) : _processManager = processManager, |
dnfield
left a comment
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.
test?
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.
File or link bugs
|
This PR is blocked on #102805 |
dbc26ce to
77e80eb
Compare
77e80eb to
5a81b45
Compare
|
Tests are still failing on Windows. Another fix to fml for Windows is here flutter/engine#33029. |
5a81b45 to
37df309
Compare
dnfield
left a comment
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 as long as tests pass
37df309 to
e687e7b
Compare
|
There will be non-trivial work to do this in the internal build. I filed b/231004915 to track that. I am holding off on landing this until the internal roll catches up a bit, and I get feedback on the internal issue from the internal build team. |
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.
We should just update the fragment_shader_manager to generate the right code. AFAICT, it's only used for this purpose and nothing else?
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.
Yeah, we'll probably want to have a code gen solution, but it should likely be based on the reflection info emitted by impellerc and not on that package. So, spot fixes to fragment_shader_manager will probably not actually be too helpful.
e687e7b to
9ec26a0
Compare
|
The g3 side of this is in cl/446113910. |
f97075f to
2bab21f
Compare
2bab21f to
7470402
Compare
Fixes #99783