[quote="tqchen, post:27, topic:11372"]
>From N0’s pov, the ability to directly pass in Target with a host field is a
>good default solutions for this most comon combo, so in the case of API/UX
>design, we might want to encourage this kind of usage without worrying about
>additional fields for hetergenous setups in a config.
[/quote]
This was covered in the original post:
[quote="Mousius, post:1, topic:11372"]
>From Python the module will be passed into C++ with the `CompilationConfig` to
>start the compilation flow:
```
def relay.build(ir_mod, config: Union[CompilationConfig, Target], ...):
if isinstance(config, Target):
config = CompilationConfig.from_target(config)
mod["build"](ir_mod, config)
```
[/quote]
[quote="tqchen, post:27, topic:11372"]
Under the context of config and target, we will need to be able to say that a
tag can refers to either a config and Target, which effectively complicates the
tagging system and explaination here. Additionally, there will be needs to have
a common mechanism to register the tags for both target and config. Making them
more uniformed would make this perspective more streamlined.
[/quote]
Ah, I understand, if we don't pass a `Target` and instead just pass a tag then
you have to figure out which one to go for. The approach taken in [Command Line
Configuration
Files](https://github.com/apache/tvm-rfcs/blob/main/rfcs/0030-tvmc-comand-line-configuration-files.md)
is to wrap the `Target` in the JSON configuration. Which leads me to believe
we should default to a `Config` level tag which is the highest level available?
If we add in-between layers then this still holds? For the same reason I
wouldn't want to use `Target` to define everything, I can see the error in
trying to explain a `Target` tag and a `Config` tag and leading to confusion as
to what a tag is - which I think we're agreeing on?
[quote="tqchen, post:27, topic:11372"]
>From the N4’s pov, we will need to be able to represent the objects during
>decompositions, which means there will be need of smooth transitions of
>related information at the function level. For example, for some a function
>that involves mixed target host/device mixing the transitions to a device
>only. If that entails a difference in terms of the “target constraints”, e.g.
>for functions with multi-target it starts with a “config” attr, then for
>functions with a single device it becomes a “target” attr. Such transition is
>not as uniform.
[/quote]
This RFC doesn't aim to address how you use the configuration so much as define
the fact the configuration will be there for you to use and rely on. [Unified
device/target/memory scope
planning](https://github.com/apache/tvm-rfcs/pull/38) stands out to me as an
RFC which discusses how to correctly annotate a function for a specific
use-case and other than providing a consistent view of the world the
`CompilationConfig` does not impact this.
[quote="tqchen, post:27, topic:11372"]
In the context of N5, there will be a need to be able to log both single device
target, or multitarget config as part of the autotuning logs in the same way.
From the automation’s pov they are all “target constraints” of a function, or a
collection of functions. As in N4, this would favor a single entity that
captures the “target constraint” in an uniformed way, or at least a unified
serialization mechanism and perhaps repr printing that covers the target
involved.
[/quote]
Are you suggesting something as simple as `configuration.to_json()` or
`configuration.serialize_targets()` which would return the array of JSON
represented `Target` ? Re-using the already defined schema for `Target` and
providing some way to extract it seems to function here?
---
[Visit
Topic](https://discuss.tvm.apache.org/t/pre-rfc-compilation-configuration-representation/11372/28)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](https://discuss.tvm.apache.org/email/unsubscribe/d25387a57cd2b4ae3ef7325c5d6028eb188d7f8f26274c5207e90857725215c5).
