[Impeller] Implement YUV texture import and sampling for video player frames. (#50730) This patch rounds out support for importing Android Hardware Buffers as Vulkan images and sampling from them. Not all Android Hardware Buffers are in formats that Vulkan (let alone Impeller) understands. Some YUV textures have formats with no equivalent `vk::Format` enum and need extra information on how to sample from them. This patch adds support for correctly importing and sampling from such formats. There are severe restrictions on how sampling from such external formats works. For one, it isn’t possible to assign a combined image sampler in the render pass. The pipeline itself needs to be rebuilt to reference a specially created immutable sampler. This immutable sampler is a combination of the usual information present in an Impeller SamplerDescriptor as well as a custom “conversion” object obtained while importing the Android Hardware Buffer. There is no way to predict what conversion object will be necessary ahead of time as this will depend on the source of the Android Hardware Buffers and is likely different for different video feeds, camera sources, and other Android Hardware Buffer texture sources. To handle this uncertainty, a new pipeline variant with a JIT determined immutable sampler will be hashed and cached before being used in a render pass. The number of pipeline variants created just-in-time will depend on the number of sampler variants used in the render pass to sample from wrapped Image. For instance, specifying a sampler with a different address mode will likely result in a new pipeline variant being created. In most cases however, there will just be one or two additional pipeline variants per application. Impellers sampler diversity is very low with most samplers being the usual NN samplers. It may be possible to preload even this pipeline by trying known conversions. As said previously, there can only be a handful of these conversions. More restrictions on sampling from such images includes being limited to `VK_FILTER_LINEAR` without additional format and extension wrangling and performance penalties. Fixes https://github.com/flutter/flutter/issues/142082. https://dart.googlesource.com/external/github.com/flutter/engine/+/6594bca63f3ffda94806546ef1907a4228e8d7db
Monorepo is:
With depot_tools installed and on your path, create a directory for your monorepo checkout and run these commands to create a gclient solution in that directory:
mkdir monorepo cd monorepo gclient config --unmanaged https://dart.googlesource.com/monorepo gclient sync -D
This gives you a checkout in the monorepo directory that contains:
monorepo/ DEPS - the DEPS used for this gclient checkout commits.json - the pinned commits for Dart, flutter/engine, and flutter/flutter tools/ - scripts used to create monorepo DEPS engine/src/ - the flutter/buildroot repo flutter/ - the flutter/engine repo out/ - the build directory, where Flutter engine builds are created third_party/ - Flutter dependencies checked out by DEPS dart/ - the Dart SDK checkout. third_party - Dart dependencies, also used by Flutter flutter/ - the flutter/flutter repo
Flutter's instructions for building the engine are at Compiling the engine
They can be followed closely, with a few changes:
goma_ctl ensure_start is sufficient.Example build commands that work on linux:
MONOREPO_PATH=$PWD if [[ ! $PATH =~ (^|:)$MONOREPO_PATH/flutter/bin(:|$) ]]; then PATH=$MONOREPO_PATH/flutter/bin:$PATH fi export GOMA_DIR=$(dirname $(command -v gclient))/.cipd_bin goma_ctl ensure_start pushd engine/src flutter/tools/gn --goma --no-prebuilt-dart-sdk --unoptimized --full-dart-sdk autoninja -C out/host_debug_unopt popd
The Flutter commands used to build and run apps will use the locally built Flutter engine and Dart SDK, instead of the one downloaded by the Flutter tool, if the --local-engine option is provided.
For example, to build and run the Flutter spinning square sample on the web platform,
MONOREPO_PATH=$PWD cd flutter/examples/layers flutter --local-engine=host_debug_unopt \ -d chrome run widgets/spinning_square.dart cd $MONOREPO_PATH
To build for desktop, specify the desktop platform device in flutter run as -d macos or -d linux or -d windows. You may also need to run the command
flutter create --platforms=windows,macos,linux
on existing apps, such as sample apps. New apps created with flutter create already include these support files. Details of desktop support are at Desktop Support for Flutter
Tests in the Flutter source tree can be run with the flutter test command, run in the directory of a package containing tests. For example:
MONOREPO_PATH=$PWD cd flutter/packages/flutter flutter test --local-engine=host_debug_unopt cd $MONOREPO_PATH
Please file an issue or email the dart-engprod team with any problems with or questions about using monorepo.
We will update this documentation to address them.
flutter commands may download the engine and Dart SDK files for the configured channel, even though they will be using the local engine and its SDK.gclient sync needs to be run in an administrator session, because some installed dependencies create symlinks.