I have tested v0.8 release on microtvm physical hardware for Arduino and Zephyr
platforms. It passes the tests for these hardware:
- **Zephyr**: qemu_x86, nrf5340dk_nrf5340_cpuapp, nucleo_l4r5zi,
stm32f746g_disco, nucleo_f746zg
- **Arduino**: due
--
You are receiving this because you are subscr
What about we define a new target kind:
```
{
"kind": "packaged", # probably need a better name, please propose new ones
"runtime": "crt", # the "runtime" in the proposal
"executor": { # the codegen target for relay function
# i.e. the "executor" in the propos
@comaniac , sure, already add the future PR plan.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/issues/8596#issuecomment-966600356
@Mousius I totally agree to make things hygiene, and believe folding things
into Target is the correct and consistent approach.
First of all, the automation system solely relies on the target object to
understand the code dispatching, hardware specs and runtime information.
Without having the
Wow lots more discussion here! Thanks @junrushao1994 for writing up our
discussions. So one thing I'd like to point out is that the recursive Target
approach is not more expressive than the approach proposed by this original
RFC. Expressing a "contains" relation can be done equivalently well b
> @comaniac , thanks for the follow up, just saw this comments, already done.
Could you update the issue with a complete plan (e.g., milestones, expected
PRs) instead of adding one line when filing a PR? Otherwise people won't have
an idea about how many PRs you are going to send and what milest
@comaniac , thanks for the follow up, just saw this comments, already done.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/issues/8596#issuecomment-966581046
[quote="junrushao1994, post:32, topic:11372"]
On the other hand, my concern is the fragmentation of APIs. It has been a huge
problem in the recent 1-2 years, and we do have alternatives not to do so.
[/quote]
Could you elaborate on this? I believe this isn't solely a UX issue but also a
hygien
@areusch and I had long discussion yesterday offline, and he helped me
understand the concern from the UX perspective: If we fold executor into
target, then it's more difficult to separate the config coming from two
parties, where one party impl the codegen and the other impl the executor.
On
[quote="tqchen, post:29, topic:11372"]
This would results in two UX concepts. A target tag and config tag, and in the
case of system implementations, possible two similar impls.
[/quote]
Which leads me to believe we should default to a `Config` level tag which is
the highest level available?
Independent from the engineering discussion. It would be useful to come back to
the terminology and think about the UX consequence present that to the user.
Obviously this is subjective, but worth to think about what can serve as a good
story. I tried to search the term "Target" and "compiler
Thanks @Mousius I am not suggesting a decision on solutions, but just want to
broadly discuss the implication, of the engineering solutions. For example, to
build on what you said
> Which leads me to believe we should default to a `Config` level tag which is
> the highest level available? If
[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
All the the alternatives (A1a, A1b, A1c), should be able to cover the need that
we initially bought up -- around N3. Additionally, the Target system as it is
now is already powerful enough to resolve the N3 related needs that was bought
up, as the alternatives @junrushao1994 listed along the A
Hi @tqchen,
Reading through the various needs there's nothing which hasn't already been
covered by this RFC in combination with already accepted RFCs. Could you
articulate the next steps?
---
[Visit
Topic](https://discuss.tvm.apache.org/t/pre-rfc-compilation-configuration-representation/
Merged #9488 into main.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/pull/9488#event-5604056253
16 matches
Mail list logo
