[pytorch][CI] end-to-end custom build script#34012
[pytorch][CI] end-to-end custom build script#34012ljk53 wants to merge 8 commits intogh/ljk53/107/basefrom
Conversation
Summary: Add script to show/test the flow to build libtorch locally with optimized binary size for mobile devices and the flow to integrate it with a simple predictor in c++. There are three custom build types that this script supports: 1. `TEST_DEFAULT=1 ./build.sh` - it is similar to the prebuilt libtorch libraries released for Android and iOS (same CMake build options + host toolchain), which doesn't contain autograd function nor backward ops thus is smaller than full LibTorch. 2. `TEST_CUSTOM_BUILD_STATIC=1 ./build.sh` - it further optimizes libtorch size by only including ops used by a specific model. 3. `TEST_CUSTOM_BUILD_DYNAMIC=1 ./build.sh` - similar as 2) except that it relies on the op dependency graph (instead of static dispatch) to calculate and keep all transitively dependent ops by the model. Type 2) will be deprecated by type 3) in the future. Type 3) custom build has not been fully supported yet so it's expected to fail. [ghstack-poisoned]
Summary: Add script to show/test the flow to build libtorch locally with optimized binary size for mobile devices and the flow to integrate it with a simple predictor in c++. There are three custom build types that this script supports: 1. `TEST_DEFAULT=1 ./build.sh` - it is similar to the prebuilt libtorch libraries released for Android and iOS (same CMake build options + host toolchain), which doesn't contain autograd function nor backward ops thus is smaller than full LibTorch. 2. `TEST_CUSTOM_BUILD_STATIC=1 ./build.sh` - it further optimizes libtorch size by only including ops used by a specific model. 3. `TEST_CUSTOM_BUILD_DYNAMIC=1 ./build.sh` - similar as 2) except that it relies on the op dependency graph (instead of static dispatch) to calculate and keep all transitively dependent ops by the model. Type 2) will be deprecated by type 3) in the future. Type 3) custom build has not been fully supported yet so it's expected to fail. [ghstack-poisoned]
Summary: Add script to show/test the flow to build libtorch locally with optimized binary size for mobile devices and the flow to integrate it with a simple predictor in c++. There are three custom build types that this script supports: 1. `TEST_DEFAULT=1 ./build.sh` - it is similar to the prebuilt libtorch libraries released for Android and iOS (same CMake build options + host toolchain), which doesn't contain autograd function nor backward ops thus is smaller than full LibTorch. 2. `TEST_CUSTOM_BUILD_STATIC=1 ./build.sh` - it further optimizes libtorch size by only including ops used by a specific model. 3. `TEST_CUSTOM_BUILD_DYNAMIC=1 ./build.sh` - similar as 2) except that it relies on the op dependency graph (instead of static dispatch) to calculate and keep all transitively dependent ops by the model. Type 2) will be deprecated by type 3) in the future. Type 3) custom build has not been fully supported yet so it's expected to fail. ghstack-source-id: a838dcc Pull Request resolved: #34012
Summary: Add script to show/test the flow to build libtorch locally with optimized binary size for mobile devices and the flow to integrate it with a simple predictor in c++. There are three custom build types that this script supports: 1. `TEST_DEFAULT=1 ./build.sh` - it is similar to the prebuilt libtorch libraries released for Android and iOS (same CMake build options + host toolchain), which doesn't contain autograd function nor backward ops thus is smaller than full LibTorch. 2. `TEST_CUSTOM_BUILD_STATIC=1 ./build.sh` - it further optimizes libtorch size by only including ops used by a specific model. 3. `TEST_CUSTOM_BUILD_DYNAMIC=1 ./build.sh` - similar as 2) except that it relies on the op dependency graph (instead of static dispatch) to calculate and keep all transitively dependent ops by the model. Type 2) will be deprecated by type 3) in the future. Type 3) custom build has not been fully supported yet so it's expected to fail. [ghstack-poisoned]
Summary: Add script to show/test the flow to build libtorch locally with optimized binary size for mobile devices and the flow to integrate it with a simple predictor in c++. There are three custom build types that this script supports: 1. `TEST_DEFAULT_BUILD=1 ./build.sh` - it is similar to the prebuilt libtorch libraries released for Android and iOS (same CMake build options + host toolchain), which doesn't contain autograd function nor backward ops thus is smaller than full LibTorch. 2. `TEST_CUSTOM_BUILD_STATIC=1 ./build.sh` - it further optimizes libtorch size by only including ops used by a specific model. 3. `TEST_CUSTOM_BUILD_DYNAMIC=1 ./build.sh` - similar as 2) except that it relies on the op dependency graph (instead of static dispatch) to calculate and keep all transitively dependent ops by the model. Type 2) will be deprecated by type 3) in the future. Type 3) custom build has not been fully supported yet so it's expected to fail. [ghstack-poisoned]
Summary: Add script to show/test the flow to build libtorch locally with optimized binary size for mobile devices and the flow to integrate it with a simple predictor in c++. There are three custom build types that this script supports: 1. `TEST_DEFAULT_BUILD=1 ./build.sh` - it is similar to the prebuilt libtorch libraries released for Android and iOS (same CMake build options + host toolchain), which doesn't contain autograd function nor backward ops thus is smaller than full LibTorch. 2. `TEST_CUSTOM_BUILD_STATIC=1 ./build.sh` - it further optimizes libtorch size by only including ops used by a specific model. 3. `TEST_CUSTOM_BUILD_DYNAMIC=1 ./build.sh` - similar as 2) except that it relies on the op dependency graph (instead of static dispatch) to calculate and keep all transitively dependent ops by the model. Type 2) will be deprecated by type 3) in the future. Type 3) custom build has not been fully supported yet so it's expected to fail. ghstack-source-id: b04cf66 Pull Request resolved: #34012
💊 CircleCI build failures summary and remediationsAs of commit e3727c1 (more details on the Dr. CI page): ✅ None of the build failures appear to be your fault 💚
❄️ 2 tentatively flaky failures2 failures tentatively classified as flaky but have not launched reruns to confirm:
|
Summary: Today some mobile simulator tests only run on landed PRs and it requires setting up special build environment to repro errors locally. The goal of the PR is to do end-to-end mobile custom build & integration tests with host toolchain (using same CMake options as mobile build). This way, non-mobile engineers can capture & debug mobile related build issues much more easily. There are three custom build types that this script supports: 1. `TEST_DEFAULT_BUILD=1 ./build.sh` - it is similar to the prebuilt libtorch libraries released for Android and iOS (same CMake build options + host toolchain), which doesn't contain autograd function nor backward ops thus is smaller than full LibTorch. 2. `TEST_CUSTOM_BUILD_STATIC=1 ./build.sh` - it further optimizes libtorch size by only including ops used by a specific model. 3. `TEST_CUSTOM_BUILD_DYNAMIC=1 ./build.sh` - similar as 2) except that it relies on the op dependency graph (instead of static dispatch) to calculate and keep all transitively dependent ops by the model. Type 2) will be deprecated by type 3) in the future. Type 3) custom build has not been fully supported yet so it's expected to fail. Replacing existing mobile build CI to run Type 1) build & integration test. [ghstack-poisoned]
Summary: Today some mobile simulator tests only run on landed PRs and it requires setting up special build environment to repro errors locally. The goal of the PR is to do end-to-end mobile custom build & integration tests with host toolchain (using same CMake options as mobile build). This way, non-mobile engineers can capture & debug mobile related build issues much more easily. There are three custom build types that this script supports: 1. `TEST_DEFAULT_BUILD=1 ./build.sh` - it is similar to the prebuilt libtorch libraries released for Android and iOS (same CMake build options + host toolchain), which doesn't contain autograd function nor backward ops thus is smaller than full LibTorch. 2. `TEST_CUSTOM_BUILD_STATIC=1 ./build.sh` - it further optimizes libtorch size by only including ops used by a specific model. 3. `TEST_CUSTOM_BUILD_DYNAMIC=1 ./build.sh` - similar as 2) except that it relies on the op dependency graph (instead of static dispatch) to calculate and keep all transitively dependent ops by the model. Type 2) will be deprecated by type 3) in the future. Type 3) custom build has not been fully supported yet so it's expected to fail. Replacing existing mobile build CI to run Type 1) build & integration test. ghstack-source-id: 4fdc7e6 Pull Request resolved: #34012
| echo "Clang version:" | ||
| clang --version | ||
| # Install torch & torchvision - used to download & trace test model. | ||
| pip install torch torchvision --progress-bar off |
There was a problem hiding this comment.
I see iOS simulator test is doing this - I'm not entirely sure whether it's a good idea to download and install torch & torchvision on every PR.
My goal is to download & trace & run a non-trivial model so I chose MobileNetV2 - shall I create a dummy TorchScript model with similar set of ops like MobileNetV2 but with small dummy weights instead so that I can commit the test model without downloading it from network?
Are there any similar integration tests for non-mobile builds that I can reuse?
There was a problem hiding this comment.
It's not great (I commented on this at #30133 (comment)) but it's certainly the most convenient way to dump the model (and we do this in a few other places). An alternative is to save the model in s3 directly and then suck it down directly, but that makes it more difficult to update the model later.
There was a problem hiding this comment.
As for your other question, let me read the patch and get back to you on it.
There was a problem hiding this comment.
It's not great (I commented on this at #30133 (comment)) but it's certainly the most convenient way to dump the model (and we do this in a few other places). An alternative is to save the model in s3 directly and then suck it down directly, but that makes it more difficult to update the model later.
I saw you commented there - "concerned about relying on nightlies for per PR tests" - it installs stable torch, isn't it?
| fi | ||
| } | ||
|
|
||
| generate_op_dependency_graph() { |
There was a problem hiding this comment.
selected mobile build with dynamic dispatch is not supported in OSS yet so this won't be called now.
When I enable it in the future, it will build libtorch twice - first generate the op dependency graph inline (which will build mobile libtorch into LLVM bitcode), then call the regular mobile build (which will build mobile libtorch again).
I could reuse the output of the other code-analysis CI's output to save some work, but it won't reduce latency of the job. Fortunately it takes much less time to build libtorch with mobile CMake options (as it skips autograd and caffe2) so it's probably not going to be too bad.
Let me know if you have better suggestions.
There was a problem hiding this comment.
This is the terminal state of the static analyzer, is that right? Because we cannot use LLVM to generate the op dependency graph without compiling everything, and then we need to build the actual build. Do you have some sense of how long these steps take?
It's kind of irritating that you have to build twice, but assuming you need LLVM bitcode I'm not sure how to get around it. I suppose that for OSS end users, we could directly distribute LLVM bitcode for libtorch, so they don't need to do this step.
There was a problem hiding this comment.
It's generally much faster than regular full pytorch build + test, so hopefully this won't be the bottleneck of our CI. But I'll test before adding the custom build + dynamic dispatch option to the CI (only this mode requires build twice).
For external users, we can simply add the op dependency graph to the release/nightly package. The only potential issue is that some cmake options will affect the op dependency graph, e.g.: whether to strip out error message, because full error message calls tensor.toString() which calls some other aten ops :)
Summary: Today some mobile simulator tests only run on landed PRs and it requires setting up special build environment to repro errors locally. The goal of the PR is to do end-to-end mobile custom build & integration tests with host toolchain (using same CMake options as mobile build). This way, non-mobile engineers can capture & debug mobile related build issues much more easily. There are three custom build types that this script supports: 1. `TEST_DEFAULT_BUILD=1 ./build.sh` - it is similar to the prebuilt libtorch libraries released for Android and iOS (same CMake build options + host toolchain), which doesn't contain autograd function nor backward ops thus is smaller than full LibTorch. 2. `TEST_CUSTOM_BUILD_STATIC=1 ./build.sh` - it further optimizes libtorch size by only including ops used by a specific model. 3. `TEST_CUSTOM_BUILD_DYNAMIC=1 ./build.sh` - similar as 2) except that it relies on the op dependency graph (instead of static dispatch) to calculate and keep all transitively dependent ops by the model. Type 2) will be deprecated by type 3) in the future. Type 3) custom build has not been fully supported yet so it's expected to fail. Replacing existing mobile build CI to run Type 1) build & integration test. [ghstack-poisoned]
| model = torchvision.models.mobilenet_v2(pretrained=True) | ||
| model.eval() | ||
| example = torch.rand(1, 3, 224, 224) | ||
| traced_script_module = torch.jit.trace(model, example) |
There was a problem hiding this comment.
Unrelated question: how come we're tracing here (and not using TorchScript, e.g.?)
There was a problem hiding this comment.
It's copied from a very old example, so the latest approach should be script_model = torch.jit.script(mode)?
| torch::autograd::AutoGradMode no_autograd_guard{false}; | ||
| // Disable graph optimizer to ensure list of unused ops are not changed for | ||
| // custom mobile build. | ||
| torch::jit::GraphOptimizerEnabledGuard no_optimizer_guard{false}; |
There was a problem hiding this comment.
The reasoning here makes sense, but in general, this seems a bit questionable, since I imagine that one might quite reasonably want to optimize graphs for mobile build. Wouldn't it be "more correct" to optimize first, and then compute the list of unused ops? Can this be conveniently supported?
I understand the goal of this PR is to get an e2e CI running, so this wouldn't be blocking, but it's something to think about...
| auto qengines = at::globalContext().supportedQEngines(); | ||
| if (std::find(qengines.begin(), qengines.end(), at::QEngine::QNNPACK) != | ||
| qengines.end()) { | ||
| at::globalContext().setQEngine(at::QEngine::QNNPACK); |
There was a problem hiding this comment.
Also not really related to this PR, but is there really any reason why you wouldn't want the lack of QNNPACK to be a hard error? This code (1) seems annoying boilerplate that everyone has to write, and (2) seems like it would mask build problems when QNNPACK is not available.
There was a problem hiding this comment.
It's copied from the Android JNI glue code (I guess we wanted to keep it flexible to support custom mobile build without QNNPACK?) I can remove this from e2e CI code, though.
And yes, it's annoying to copy this type of boilerplate code (including MobileCallGuard) to Android/iOS and here - shall we add them to torch/script.h header for mobile builds?
There was a problem hiding this comment.
Ideally, it wouldn't be necessary to write this boilerplate at all! I guess it would be better to figure out who added this in the first place and ask them about it. @jerryzh168, any comments here?
There was a problem hiding this comment.
Ideally, it wouldn't be necessary to write this boilerplate at all! I guess it would be better to figure out who added this in the first place and ask them about it. @jerryzh168, any comments here?
I think this is introduced since @supriyar unified fbgemm & qnnpack interface at dispatcher level. Now they look the same but the underlying packed weights format / etc are different. So we introduced the concept called "qengine" to switch between these two quantization implementations. And it's possible to have both qnnpack/fbgemm available in one build so I guess it needs to be set explicitly. Yet another dispatching mechanism? :)
There was a problem hiding this comment.
For mobile build though we turn off FBGEMM, right? In that case the default qengine should be set to QNNPACK. We control that here - https://github.com/pytorch/pytorch/blob/master/aten/src/ATen/Context.cpp#L122
There was a problem hiding this comment.
yeah it is another runtime dispatcher because we unified the API for fbgemm and qnnpack.
There was a problem hiding this comment.
@supriyar did you add this boilerplate code? could you talk about why did we do this? Do we ever run this code with fbgemm backend?
There was a problem hiding this comment.
@jerryzh168 see my comment above. I don't think this boilerplate is necessary because we set a default backend (for mobile it should be qnnpack) in Context.cpp.
| @@ -0,0 +1,145 @@ | |||
| #!/bin/bash | |||
| ############################################################################### | |||
| # This script shows/tests the flow to build libtorch locally with optimized | |||
There was a problem hiding this comment.
Mentioning a pet peeve of mine: I generally don't like build scripts intended for general use by users, because they can make it difficult to toggle build parameters on the underlying cmake invocations (we had this problem for the longest time in setup.py until xuhdev wrote a general framework for passing environment variables into cmake flags for the underlying cmake invocation).
There was a problem hiding this comment.
Make sense. First, I wasn't thinking about exposing this to external users - I meant to say "shows" how things works to internal developers who need repeat the build process locally.
Right now the exposed mobile build scripts are under scripts/build_ios.sh, scripts/build_pytorch_android.sh, scripts/build_mobile.sh, which kinda support overriding cmake options from command line.
This scripts invokes multiple other shell scripts, and some of them are meant to take specialized cmake options;
Large part of this script (building analyzer tool, building LLVM bitcode, running analyzer against bitcode) is also done by the other CI (mobile_code_analysis) - we should pack its output to release package so external users don't need to do it by themselves.
The whole custom build + dynamic dispatch workflow is still evolving so it's not set in stone - I'll take a look at xuhdev's general framework and might migrate to it in the future.
There was a problem hiding this comment.
removing "shows" from the comment to avoid confusing external developers :)
There was a problem hiding this comment.
Not too sure xuhdev's stuff in setup.py is all that useful, since it's specific for building PyTorch on Windows. But worth taking a look :)
| # relies on the op dependency graph (instead of static dispatch) to calculate | ||
| # and keep all transitively dependent ops by the model. | ||
| # Note that LLVM_DIR environment variable should be set to the location of | ||
| # LLVM-dev toolchain. |
There was a problem hiding this comment.
Is this intended to be an example for users for how they set things up? :)
There was a problem hiding this comment.
I guess yes for internal developers if they need debug why their change breaks custom build + dynamic dispatch? But probably not for external users?
Summary: Today some mobile simulator tests only run on landed PRs and it requires setting up special build environment to repro errors locally. The goal of the PR is to do end-to-end mobile custom build & integration tests with host toolchain (using same CMake options as mobile build). This way, non-mobile engineers can capture & debug mobile related build issues much more easily. There are three custom build types that this script supports: 1. `TEST_DEFAULT_BUILD=1 ./build.sh` - it is similar to the prebuilt libtorch libraries released for Android and iOS (same CMake build options + host toolchain), which doesn't contain autograd function nor backward ops thus is smaller than full LibTorch. 2. `TEST_CUSTOM_BUILD_STATIC=1 ./build.sh` - it further optimizes libtorch size by only including ops used by a specific model. 3. `TEST_CUSTOM_BUILD_DYNAMIC=1 ./build.sh` - similar as 2) except that it relies on the op dependency graph (instead of static dispatch) to calculate and keep all transitively dependent ops by the model. Type 2) will be deprecated by type 3) in the future. Type 3) custom build has not been fully supported yet so it's expected to fail. Replacing existing mobile build CI to run Type 1) build & integration test. Differential Revision: [D20193328](https://our.internmc.facebook.com/intern/diff/D20193328) [ghstack-poisoned]
Summary: Today some mobile simulator tests only run on landed PRs and it requires setting up special build environment to repro errors locally. The goal of the PR is to do end-to-end mobile custom build & integration tests with host toolchain (using same CMake options as mobile build). This way, non-mobile engineers can capture & debug mobile related build issues much more easily. There are three custom build types that this script supports: 1. `TEST_DEFAULT_BUILD=1 ./build.sh` - it is similar to the prebuilt libtorch libraries released for Android and iOS (same CMake build options + host toolchain), which doesn't contain autograd function nor backward ops thus is smaller than full LibTorch. 2. `TEST_CUSTOM_BUILD_STATIC=1 ./build.sh` - it further optimizes libtorch size by only including ops used by a specific model. 3. `TEST_CUSTOM_BUILD_DYNAMIC=1 ./build.sh` - similar as 2) except that it relies on the op dependency graph (instead of static dispatch) to calculate and keep all transitively dependent ops by the model. Type 2) will be deprecated by type 3) in the future. Type 3) custom build has not been fully supported yet so it's expected to fail. Replacing existing mobile build CI to run Type 1) build & integration test. Differential Revision: [D20193328](https://our.internmc.facebook.com/intern/diff/D20193328) [ghstack-poisoned]
Summary: Pull Request resolved: pytorch#34012 Today some mobile simulator tests only run on landed PRs and it requires setting up special build environment to repro errors locally. The goal of the PR is to do end-to-end mobile custom build & integration tests with host toolchain (using same CMake options as mobile build). This way, non-mobile engineers can capture & debug mobile related build issues much more easily. There are three custom build types that this script supports: 1. `TEST_DEFAULT_BUILD=1 ./build.sh` - it is similar to the prebuilt libtorch libraries released for Android and iOS (same CMake build options + host toolchain), which doesn't contain autograd function nor backward ops thus is smaller than full LibTorch. 2. `TEST_CUSTOM_BUILD_STATIC=1 ./build.sh` - it further optimizes libtorch size by only including ops used by a specific model. 3. `TEST_CUSTOM_BUILD_DYNAMIC=1 ./build.sh` - similar as 2) except that it relies on the op dependency graph (instead of static dispatch) to calculate and keep all transitively dependent ops by the model. Type 2) will be deprecated by type 3) in the future. Type 3) custom build has not been fully supported yet so it's expected to fail. Replacing existing mobile build CI to run Type 1) build & integration test. Test Plan: Imported from OSS Differential Revision: D20193328 Pulled By: ljk53 fbshipit-source-id: 48c14cae849fde86e27123f00f9911996c1cf40e
Summary: Pull Request resolved: pytorch#34012 Today some mobile simulator tests only run on landed PRs and it requires setting up special build environment to repro errors locally. The goal of the PR is to do end-to-end mobile custom build & integration tests with host toolchain (using same CMake options as mobile build). This way, non-mobile engineers can capture & debug mobile related build issues much more easily. There are three custom build types that this script supports: 1. `TEST_DEFAULT_BUILD=1 ./build.sh` - it is similar to the prebuilt libtorch libraries released for Android and iOS (same CMake build options + host toolchain), which doesn't contain autograd function nor backward ops thus is smaller than full LibTorch. 2. `TEST_CUSTOM_BUILD_STATIC=1 ./build.sh` - it further optimizes libtorch size by only including ops used by a specific model. 3. `TEST_CUSTOM_BUILD_DYNAMIC=1 ./build.sh` - similar as 2) except that it relies on the op dependency graph (instead of static dispatch) to calculate and keep all transitively dependent ops by the model. Type 2) will be deprecated by type 3) in the future. Type 3) custom build has not been fully supported yet so it's expected to fail. Replacing existing mobile build CI to run Type 1) build & integration test. Test Plan: Imported from OSS Differential Revision: D20193328 Pulled By: ljk53 fbshipit-source-id: 48c14cae849fde86e27123f00f9911996c1cf40e
Summary: According to #34012 (comment), this `at::globalContext().setQEngine(at::QEngine::QNNPACK);` call isn't really necessary for mobile. In Context.cpp it selects the last available QEngine if the engine isn't set explicitly. For OSS mobile prebuild it should only include QNNPACK engine so the default behavior should already be desired behavior. It makes difference only when USE_FBGEMM is set - but it should be off for both OSS mobile build and internal mobile build. [ghstack-poisoned]
Summary: According to #34012 (comment), this `at::globalContext().setQEngine(at::QEngine::QNNPACK);` call isn't really necessary for mobile. In Context.cpp it selects the last available QEngine if the engine isn't set explicitly. For OSS mobile prebuild it should only include QNNPACK engine so the default behavior should already be desired behavior. It makes difference only when USE_FBGEMM is set - but it should be off for both OSS mobile build and internal mobile build. ghstack-source-id: 139184c Pull Request resolved: #34556
…ors (#34556) Summary: Pull Request resolved: #34556 According to #34012 (comment), this `at::globalContext().setQEngine(at::QEngine::QNNPACK);` call isn't really necessary for mobile. In Context.cpp it selects the last available QEngine if the engine isn't set explicitly. For OSS mobile prebuild it should only include QNNPACK engine so the default behavior should already be desired behavior. It makes difference only when USE_FBGEMM is set - but it should be off for both OSS mobile build and internal mobile build. Test Plan: Imported from OSS Differential Revision: D20374522 Pulled By: ljk53 fbshipit-source-id: d4e437a03c6d4f939edccb5c84f02609633a0698
Summary: Pull Request resolved: pytorch#34012 Today some mobile simulator tests only run on landed PRs and it requires setting up special build environment to repro errors locally. The goal of the PR is to do end-to-end mobile custom build & integration tests with host toolchain (using same CMake options as mobile build). This way, non-mobile engineers can capture & debug mobile related build issues much more easily. There are three custom build types that this script supports: 1. `TEST_DEFAULT_BUILD=1 ./build.sh` - it is similar to the prebuilt libtorch libraries released for Android and iOS (same CMake build options + host toolchain), which doesn't contain autograd function nor backward ops thus is smaller than full LibTorch. 2. `TEST_CUSTOM_BUILD_STATIC=1 ./build.sh` - it further optimizes libtorch size by only including ops used by a specific model. 3. `TEST_CUSTOM_BUILD_DYNAMIC=1 ./build.sh` - similar as 2) except that it relies on the op dependency graph (instead of static dispatch) to calculate and keep all transitively dependent ops by the model. Type 2) will be deprecated by type 3) in the future. Type 3) custom build has not been fully supported yet so it's expected to fail. Replacing existing mobile build CI to run Type 1) build & integration test. Test Plan: Imported from OSS Differential Revision: D20193328 Pulled By: ljk53 fbshipit-source-id: 48c14cae849fde86e27123f00f9911996c1cf40e
…ors (pytorch#34556) Summary: Pull Request resolved: pytorch#34556 According to pytorch#34012 (comment), this `at::globalContext().setQEngine(at::QEngine::QNNPACK);` call isn't really necessary for mobile. In Context.cpp it selects the last available QEngine if the engine isn't set explicitly. For OSS mobile prebuild it should only include QNNPACK engine so the default behavior should already be desired behavior. It makes difference only when USE_FBGEMM is set - but it should be off for both OSS mobile build and internal mobile build. Test Plan: Imported from OSS Differential Revision: D20374522 Pulled By: ljk53 fbshipit-source-id: d4e437a03c6d4f939edccb5c84f02609633a0698
Stack from ghstack:
Summary:
Today some mobile simulator tests only run on landed PRs and it requires
setting up special build environment to repro errors locally.
The goal of the PR is to do end-to-end mobile custom build & integration
tests with host toolchain (using same CMake options as mobile build). This
way, non-mobile engineers can capture & debug mobile related build issues
much more easily.
There are three custom build types that this script supports:
TEST_DEFAULT_BUILD=1 ./build.sh- it is similar to the prebuilt libtorchlibraries released for Android and iOS (same CMake build options + host
toolchain), which doesn't contain autograd function nor backward ops thus is
smaller than full LibTorch.
TEST_CUSTOM_BUILD_STATIC=1 ./build.sh- it further optimizes libtorchsize by only including ops used by a specific model.
TEST_CUSTOM_BUILD_DYNAMIC=1 ./build.sh- similar as 2) except that itrelies on the op dependency graph (instead of static dispatch) to calculate
and keep all transitively dependent ops by the model.
Type 2) will be deprecated by type 3) in the future.
Type 3) custom build has not been fully supported yet so it's expected to fail.
Replacing existing mobile build CI to run Type 1) build & integration test.
Differential Revision: D20193328