Hi @driazati,
I think this is a great improvement to help empower more people to contribute
without having to synchronise with those with certain powers in the project
across many timezones and organisations, as well as providing some much needed
consistency on commit messages. Could this imp
[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
[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?
[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
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/
Oh wow, I've been away for a few days and really appreciate the amount of
discussion that's arrived :smile_cat: Thanks @mbs-octoml, @zxybazh, @tqchen,
@comaniac, @junrushao1994 and @manupa-arm!
Firstly let's address a few specifics which may help narrow the discussion
slightly:
[quote="junru
Inspired by the work of @mbs-octoml, I give you a new RFC for CompilationConfig!
# Summary
[summary]: #summary
This RFC supersedes [Migrating IRModules to
Attributes](https://github.com/apache/tvm-rfcs/blob/main/rfcs/0029-migrating-to-irmodule-attributes.md)
by replacing the various attribute
Just coming back to this thread, I believe there's a way to introduce the hooks
in a less intrusive way to the `LowerTEPass`, by placing it just above it in
`build_module.cc`. This should mean each Target can register a `relay_to_tir`
`Pass` which is ran there rather than having to wire it via
CC: @manupa-arm @grant-arm @areusch @stoa @MJKlaiber
---
[Visit Topic](https://discuss.tvm.apache.org/t/pre-rfc-c-device-api/10874/2) to
respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](https://discuss.tvm.apache.org/em
# Summary
[summary]: #summary
I want to write an RFC to provide an API which can be used by the C runtime to
abstract the variety of driver APIs for different platforms. This is
specifically catering towards RTOS abstractions for embedded device drivers.
# Motivation
[motivation]: #motivation
Just read through this and providing my own opinions. I'm a huge fan of L2 -
Tour Style here, and I appreciate that it blends topics such as TVM and
microTVM in the beginning rather than treating them as separate; it makes a lot
of sense to me to use this to ensure we make all of TVM approacha
This is great @areusch! I appreciate the ability to re-introduce
`c_backend_api.h` to leverage existing abstractions without having to
necessarily use `c_packed_func.h`. It'd be great if we only required the single
backend header file, I think the only thing that prevents is having to copy
`f
Glad to have your feedback @areusch :smiley_cat:
[quote="areusch, post:11, topic:9849"]
Adding `--no-typed-operators` makes sense to me, but would propose to change
the name. `--no-typed-operators` reads pretty generically to me and could imply
something like “operator + is aware of the types
Hi @stoa, thanks for your observations and apologies for not replying sooner.
I'm glad you agree with the initial direction taken and I appreciate that there
may be a need to provide similar data to the user to that which is seen in
DLTensor, at this stage we'll get that by providing the opti
# Summary
This RFC outlines a set of additional APIs for the C Runtime to enable direct
calling of an AOT micro entrypoint
(https://discuss.tvm.apache.org/t/rfc-utvm-aot-optimisations-for-embedded-targets/9849)
from a model descriptor which includes some model metadata, this is an
alternativ
cc: @areusch @giuseros @stoa @manupa-arm @grant-arm
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-utvm-embedded-c-runtime-interface/9951/2)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](https://discuss.t
16 matches
Mail list logo
