You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[Relay] Support 'external codegen targets'. (apache#11173)
* [Relay] Support 'external codegen targets'.
(Part of Collage, https://github.com/apache/tvm-rfcs/blob/main/rfcs/0062-collage.md)
This change prepares the VM and Relay target handling machinery to support
external codegen targets in addition to 'regular' targets. This allows us
to configure the build with Collage as follows:
```
host_target = tvm.target.Target("llvm")
targets = [tvm.target.Target("cuda", host_target),
tvm.target.Target("cutlass", host_target),
tvm.target.Target("cudnn", host_target)]
with tvm.transform.PassContext(...):
exe = tvm.relay.vm.compile(module, target=targets)
```
Four changes are required:
1. I introduce four new target kinds for the external codegens currently supported
by Collage. Others can be added as they are vetted for use by Collage. These
are given a device type matching the external codegen's assumption (ie just CUDA
currently), and given a target kind attribute "is_external_codegen" of True. The
latter is needed by Collage to signal the target kind name represents and external
codegen 'compiler' name. See the RFC for specifics.
2. I introduce the binary relation Target::IsExternalCodegenFor so that
external codegen targets can be related back to the 'underlying' targets
they are implicitly using in their codegen.
3. I rework the VMCompiler and BuildModule interfaces to accept an Array<Target> of
'raw targets' instead of a Map<Integer, Target>. This more general representation
is needed because we may now have multiple targets of the same device type
active simultaneously. I add new static methods on the Python Target to
convert to this form in a way that mimics check_and_update_host_consist.
4. I rework CompilationConfig to work from Array<Target> directly, to not depend
on the host_target argument (since dealt with on the Python side), and to
understand that if we have two targets for the same device type the non-external
codegen target takes precedence.
The change to CompilationConfig seems neutral with respect to the recent discussions
on compilation configuration representation and tvmc.
I made a few attempts to remove Target.check_and_update_host_const entirely in favor
of using CompilationConfig as the definitive target handling choke point but backed
out once they became too large.
* - Working on unit tests
* - Fix two Debug-only failures
* - Use Array<Target> in GraphExecutorCodegen/AOTExecutorCodegen ifaces instead
of CompilationConfig (don't want to bake it into any official APIs).
- Started unit tests.
* - Lints
* - Moar Lints
* - Fix some unit tests
* - Fix last unit test failures
* - whitespace
* - Address Eric's comments.
CI likely to fail due to stricter FindPrimitiveTargetOrFail but let's see.
* - Comment adjustments.
- Unit test for new Target members.
0 commit comments