Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[flutter_tools] add tool support for shader hot reload #107963

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

Merged
merged 16 commits into from
Jul 27, 2022

Conversation

jonahwilliams
Copy link
Member

@jonahwilliams jonahwilliams commented Jul 19, 2022

Fixes #104788

Support hot reload of shaders in flutter run.

Create a new class called the development shader compiler. This holds some state about what kind of shaders to compile (impeller, platform, sksl) as well as the ability to convert from an arbitrary shader input to a DevFSContent for syncing.

Since -d all may potentially require multiple compilations for each target platform, we need to push compilation to each FlutterDevice instance instead of performing it in the resident runner. During the asset sync process, we attempt to identify any assets that are shaders. IF a shader changes, it must be recompiled and then the new contents synced to the target device in place of the original asset.

Finally, we add separate tracking for invalidated shaders so we can call the specific service extension to have the engine regenerate them.

@flutter-dashboard flutter-dashboard bot added the tool Affects the "flutter" command-line tool. See also t: labels. label Jul 19, 2022
@zanderso
Copy link
Member

Cool!

@jonahwilliams jonahwilliams marked this pull request as ready for review July 25, 2022 17:28
@jonahwilliams jonahwilliams changed the title [flutter_tools] draft support for shader hot reload [flutter_tools] add tool support for shader hot reload Jul 25, 2022
@flutter-dashboard flutter-dashboard bot added f: material design flutter/packages/flutter/material repository. framework flutter/packages/flutter repository. See also f: labels. labels Jul 25, 2022
Copy link
Member

@zanderso zanderso left a comment

Choose a reason for hiding this comment

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

This is great!

@@ -516,12 +501,11 @@ double _getTargetRadius(
class FragmentShaderManager {
FragmentShaderManager._();

static late ui.FragmentProgram _program;
static final ui.FragmentProgram _program = ui.FragmentProgram.fromAsset('shaders/ink_sparkle.frag');
Copy link
Member

Choose a reason for hiding this comment

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

This FragmentProgram.fromAsset() call takes ~9ms on my 2015 OnePlus 2. I'm wondering if fromAsset() should return a Future to force it to happen outside of frame workloads. Wdyt?

Copy link
Member Author

Choose a reason for hiding this comment

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

A few thoughts:

  1. How expensive would this be in impeller? If its just the asset loading, we may not need the future, but we can always add new APIs later.

  2. I don't really love the strategy of forcing a Future or microtask in dart:ui. That can still block by delaying the next frame if the UI thread would be quite busy. If these compilations are going to be that expensive on low end devices, maybe we should push compilation itself to a worker thread instead. That would also have the benefit of avoiding the poor interaction of the flutter test framework and the non-microtask Future constructors.

Copy link
Member

Choose a reason for hiding this comment

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

We have time before the next stable to benchmark on Impeller and then decide what to do. I expect the overhead to be lower, though, since the shader will already be lowered/compiled for OpenGL/Vulkan/Metal, and so we'd only be paying for the asset load and maybe a copy.

Copy link
Member Author

Choose a reason for hiding this comment

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

From discussion offline: I'm going to back out the ink sparkle specific changes from this PR. I need to investigate:

  1. Does the scheduling optimization we have work with shader compilation, or does it still lead to jank.
  2. Is the expensive part of shader creation on skia actually constructing the SkRuntimeEffect, or does work get deferred until we use it.
  3. How expensive is this operation on impeller

Copy link
Member Author

Choose a reason for hiding this comment

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

So the answer to: does Skia do expensive work when constructing an SkRuntimeEffect is, yes - that is where the actual program compilation appears to happen:

image

And also: https://github.com/google/skia/blob/main/src/core/SkRuntimeEffect.cpp#L330

Copy link
Member Author

Choose a reason for hiding this comment

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

Another thought - to support this on the web we'd essentially have to make fromAsset async (since it will need to make a network request). So why don't we make this async and then if we get to a world where it is always super fast, we can add a sync version?

assetPathsToEvict.add(archivePath);

if (bundle.entryKinds[archivePath] == AssetKind.shader) {
final Future<DevFSContent?> pending = shaderCompiler.recompileShader(content);
Copy link
Member

Choose a reason for hiding this comment

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

This is just going to recompile the dirty ones, right? Otherwise, this should use a pool.

Copy link
Member Author

Choose a reason for hiding this comment

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

Added a pool to the development compiler

@@ -33,7 +38,7 @@ void main() {
fileSystem.file(notFragPath).createSync(recursive: true);
});

testWithoutContext('compileShader invokes impellerc for .frag files', () async {
testWithoutContext('compileShader invokes impellerc for .frag files and spirv target', () async {
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
testWithoutContext('compileShader invokes impellerc for .frag files and spirv target', () async {
testWithoutContext('compileShader invokes impellerc for .frag files and sksl target', () async {

Copy link
Member Author

Choose a reason for hiding this comment

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

Done

expect(fileSystem.file(outputPath).existsSync(), true);
});

testWithoutContext('compileShader invokes impellerc for .frag files and sksl', () async {
Copy link
Member

Choose a reason for hiding this comment

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

Is this redundant?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, since we removed SPIRV. Done

@@ -575,6 +584,66 @@ void main() {
expect(compileLibMainIndex, greaterThanOrEqualTo(0));
expect(bundleProcessingDoneIndex, greaterThan(compileLibMainIndex));
});

group('Shader compilation',() {
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
group('Shader compilation',() {
group('Shader compilation', () {

Copy link
Member Author

Choose a reason for hiding this comment

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

Done

Copy link
Member

@zanderso zanderso left a comment

Choose a reason for hiding this comment

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

LGTM

engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Jul 27, 2022
engine-flutter-autoroll added a commit to engine-flutter-autoroll/plugins that referenced this pull request Jul 28, 2022
camsim99 pushed a commit to camsim99/flutter that referenced this pull request Aug 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
autosubmit Merge PR when tree becomes green via auto submit App f: material design flutter/packages/flutter/material repository. framework flutter/packages/flutter repository. See also f: labels. tool Affects the "flutter" command-line tool. See also t: labels.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support hot reload for automatically compiled fragment shaders
2 participants