[flutter_tools] add tool support for shader hot reload#107963
[flutter_tools] add tool support for shader hot reload#107963auto-submit[bot] merged 16 commits intoflutter:masterfrom
Conversation
flutter-dashboard
bot
added
the
tool
|
Cool! |
jonahwilliams
changed the title
flutter-dashboard
bot
added
f: material design
| FragmentShaderManager._(); | ||
|
|
||
| static late ui.FragmentProgram _program; | ||
| static final ui.FragmentProgram _program = ui.FragmentProgram.fromAsset('shaders/ink_sparkle.frag'); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
A few thoughts:
-
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.
-
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
Futureconstructors.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
From discussion offline: I'm going to back out the ink sparkle specific changes from this PR. I need to investigate:
- Does the scheduling optimization we have work with shader compilation, or does it still lead to jank.
- Is the expensive part of shader creation on skia actually constructing the SkRuntimeEffect, or does work get deferred until we use it.
- How expensive is this operation on impeller
There was a problem hiding this comment.
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:
And also: https://github.com/google/skia/blob/main/src/core/SkRuntimeEffect.cpp#L330
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
This is just going to recompile the dirty ones, right? Otherwise, this should use a pool.
There was a problem hiding this comment.
Added a pool to the development compiler
| }); | ||
|
|
||
| testWithoutContext('compileShader invokes impellerc for .frag files', () async { | ||
| testWithoutContext('compileShader invokes impellerc for .frag files and spirv target', () async { |
There was a problem hiding this comment.
| testWithoutContext('compileShader invokes impellerc for .frag files and spirv target', () async { | |
| testWithoutContext('compileShader invokes impellerc for .frag files and sksl target', () async { |
| expect(fileSystem.file(outputPath).existsSync(), true); | ||
| }); | ||
|
|
||
| testWithoutContext('compileShader invokes impellerc for .frag files and sksl', () async { |
There was a problem hiding this comment.
Yes, since we removed SPIRV. Done
| expect(bundleProcessingDoneIndex, greaterThan(compileLibMainIndex)); | ||
| }); | ||
|
|
||
| group('Shader compilation',() { |
There was a problem hiding this comment.
| group('Shader compilation',() { | |
| group('Shader compilation', () { |
…into recompile_shaders
jonahwilliams
added
the
autosubmit
2 participants
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
FlutterDeviceinstance 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.