TL;DR
Many of the existing and future proposed components for the torch_tensorrt.dynamo.fx_ts_compat (Torch export) and torch_tensorrt.dynamo.backend (Torch compile) paths are common between the two. This includes some lowering phases, aten converters, certain aspects of partitioning, and TRT modules. The goal of this story is to improve the unification between the two frontends to streamline the codebase and reduce code replication.
Goal(s)
- Unification of the components used in the
torch_tensorrt.dynamo.fx_ts_compat (Torch export) and torch_tensorrt.dynamo.backend (Torch compile) paths
- Improving code cleanliness and reducing code replication
- Centralizing component/unit tests
- Increasing speed to diagnose, fix, and push changes for key issues
Implementation Phases
- Unify existing components of
fx_ts_compat and backend that could reasonably be used together
- Combine lowering phases + testing for both paths
- Combine partitioning systems + testing for both paths (or determine plan/rationale for having two separate partitioning systems)
- Add a
TRTInterpreter override class to dynamo for usage between the two frontends
- Add a
TRTModule override class to dynamo for usage between the two frontends
TL;DR
Many of the existing and future proposed components for the
torch_tensorrt.dynamo.fx_ts_compat(Torchexport) andtorch_tensorrt.dynamo.backend(Torchcompile) paths are common between the two. This includes some lowering phases,atenconverters, certain aspects of partitioning, and TRT modules. The goal of this story is to improve the unification between the two frontends to streamline the codebase and reduce code replication.Goal(s)
torch_tensorrt.dynamo.fx_ts_compat(Torchexport) andtorch_tensorrt.dynamo.backend(Torchcompile) pathsImplementation Phases
fx_ts_compatandbackendthat could reasonably be used togetherTRTInterpreteroverride class todynamofor usage between the two frontendsTRTModuleoverride class todynamofor usage between the two frontends