mirror of
https://github.com/saymrwulf/pytorch.git
synced 2026-05-14 20:57:59 +00:00
e4c887fbf6
Fix: #120336 This PR fixes an issue on AOTAutograd, specifically on backends that don't support views by themselves (e.g. XLA). Previously, AOTAutograd tried to reconstruct output views by calling `as_strided` on the concrete bases using sizes and strides of the outputs that aliased them. Since backends such as XLA doesn't support tensor aliasing, the sizes and strides would be that of a contiguous tensor (not a view tensor). Because of that, calling `as_strided` would error, since the output tensor would be bigger than its base. Instead, this PR applies the sequence of `ViewMeta` gathered for each output during the functionalization phase. **Note:** we intentionally don't support base tensors that went through metadata mutation, i.e. in-place view operations. In summary, this PR: - Introduces one `FunctionalTensorWrapper` member function alongside its Python APIs - `apply_view_metas(base)`: applies the `ViewMeta` sequence of the given instance onto another base - Introduces a `OutputAliasInfo.functional_tensor` field - Saves the `FunctionalTensorWrapper` instance collected by the functionalization phase - Wraps it with a new `FunctionalTensorMetadataEq` class for comparing only the metadata of the tensors - Plumbs `OutputAliasInfo.functional_tensor` to `gen_alias_from_base` function - Applies the `ViewMeta` sequence of the saved `FunctionalTensor` onto `aliased_base_tensor` - Propagates `OutputAliasInfo.functional_tensor` when updating `fw_metadata` (this PR description was updated in order to reflect the most recent changes) Pull Request resolved: https://github.com/pytorch/pytorch/pull/121007 Approved by: https://github.com/bdhirsh |
||
|---|---|---|
| .. | ||
| alerts | ||
| amd_build | ||
| autograd | ||
| bazel_tools | ||
| build/bazel | ||
| build_defs | ||
| code_analyzer | ||
| code_coverage | ||
| config | ||
| coverage_plugins_package | ||
| dynamo | ||
| gdb | ||
| github | ||
| iwyu | ||
| jit | ||
| linter | ||
| lite_interpreter | ||
| lldb | ||
| onnx | ||
| pyi | ||
| rules | ||
| rules_cc | ||
| setup_helpers | ||
| shared | ||
| stats | ||
| test | ||
| testing | ||
| __init__.py | ||
| bazel.bzl | ||
| BUCK.bzl | ||
| BUCK.oss | ||
| build_libtorch.py | ||
| build_pytorch_libs.py | ||
| build_with_debinfo.py | ||
| download_mnist.py | ||
| extract_scripts.py | ||
| gen_flatbuffers.sh | ||
| gen_vulkan_spv.py | ||
| generate_torch_version.py | ||
| generated_dirs.txt | ||
| git_add_generated_dirs.sh | ||
| git_reset_generated_dirs.sh | ||
| nightly.py | ||
| nvcc_fix_deps.py | ||
| pytorch.version | ||
| README.md | ||
| render_junit.py | ||
| substitute.py | ||
| update_masked_docs.py | ||
| vscode_settings.py | ||
This folder contains a number of scripts which are used as
part of the PyTorch build process. This directory also doubles
as a Python module hierarchy (thus the __init__.py).
Overview
Modern infrastructure:
- autograd - Code generation for autograd. This includes definitions of all our derivatives.
- jit - Code generation for JIT
- shared - Generic infrastructure that scripts in
tools may find useful.
- module_loader.py - Makes it easier to import arbitrary Python files in a script, without having to add them to the PYTHONPATH first.
Build system pieces:
- setup_helpers - Helper code for searching for third-party dependencies on the user system.
- build_pytorch_libs.py - cross-platform script that builds all of the constituent libraries of PyTorch, but not the PyTorch Python extension itself.
- build_libtorch.py - Script for building libtorch, a standalone C++ library without Python support. This build script is tested in CI.
Developer tools which you might find useful:
- git_add_generated_dirs.sh and git_reset_generated_dirs.sh - Use this to force add generated files to your Git index, so that you can conveniently run diffs on them when working on code-generation. (See also generated_dirs.txt which specifies the list of directories with generated files.)
Important if you want to run on AMD GPU:
- amd_build - HIPify scripts, for transpiling CUDA
into AMD HIP. Right now, PyTorch and Caffe2 share logic for how to
do this transpilation, but have separate entry-points for transpiling
either PyTorch or Caffe2 code.
- build_amd.py - Top-level entry point for HIPifying our codebase.
Tools which are only situationally useful:
- docker - Dockerfile for running (but not developing) PyTorch, using the official conda binary distribution. Context: https://github.com/pytorch/pytorch/issues/1619
- download_mnist.py - Download the MNIST dataset; this is necessary if you want to run the C++ API tests.