+1 it will be super nice!
Personally when using vscode, I use the black integration with “format on save”
to make sure the code is formatted well. It will be great if we provide those
tooling instructions in the documentation page as well.
---
[Visit
Topic](https://discuss.tvm.apache.org
I believe @haichen and @tqchen are actively working on this.
---
[Visit
Topic](https://discuss.tvm.apache.org/t/make-binary-distributation/7867/3) to
respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](https://discuss.tvm
Finally! Thank you for the hard work!!
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-tlcpack-thirdparty-binary-packages/7903/2)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](https://discuss.tvm.apache.or
CC: @spectrometerHBH @Hzfengsy @were
---
[Visit Topic](https://discuss.tvm.apache.org/t/rfc-rename-hybrid-script/7915/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/email/unsubscri
I saw FunctionInfo in the unmangled symbol name, so it looks like there are
some missing pieces in the build. Seems like some linking issues or some
symbols are missing.
Is it working if you build on HEAD?
---
[Visit
Topic](https://discuss.tvm.apache.org/t/append-a-custom-target-for-tvm-
@xqdan Thank you for the valuable feedback! Fusion can be done automatically
with some analysis provided in Ansor.
Do you have any other kind of analysis in mind that might be potentially useful?
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-tensorir-a-schedulable-ir-for-tvm/7872
Hey @wrongtest,
Thank you for the RFC! Just wondering how it compares with the previous AD RFC
(https://discuss.tvm.apache.org/t/rfc-bring-in-tensor-expression-autodiff/5987)
?
Thanks!
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-differentiable-tensor-expression-create-and-veri
@xqdan In Ansor, Fusion analysis is handled in TE with some straightforward
heuristics, which I believe have covered our usecases. CC: @merrymercy @jcf94
Agree that ISL provides effective information about vectorization, and I
believe there might be other competitive heuristics too. Tensorizat
CC: @yzhliu the major contributor of this feature
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-differentiable-tensor-expression-create-and-verify-backward-op-automatically/7960/4)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from thes
@merrymercy I didn't get it about batched bound inference, doesn't Ansor use a
pool of threads for massive bound inference?
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-tensorir-a-schedulable-ir-for-tvm/7872/35)
to respond.
You are receiving this because you enabled mailing lis
For now, we can support linalg via TVM external functions:
https://tvm.apache.org/docs/tutorials/language/extern_op.html#sphx-glr-tutorials-language-extern-op-py.
---
[Visit
Topic](https://discuss.tvm.apache.org/t/linalg-support-for-matrix-determinant-and-inverse/7973/2)
to respond.
You
In this case, you may link the code into tvm_runtime, expose them with
TVM_REGISTER_GLOBAL (i.e. as a packed function), then they can be used as
tvm.extern. Example:
https://github.com/apache/incubator-tvm/blob/master/src/runtime/contrib/nnpack/fully_connected.cc#L36
---
[Visit
Topic](ht
BTW, @haichen shall we also release runtime-only version of tlcpack? It would
be helpful if people want to bake TVM-compiled operators in other frameworks
shallowly in python
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-tlcpack-thirdparty-binary-packages/7903/8)
to respond.
Yo
Using CXX is a good idea IMO. Would you love to send a PR? Thanks!
---
[Visit Topic](https://discuss.tvm.apache.org/t/running-tvm-on-freebsd/8009/2)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](https://discuss.tv
Would you love to send a quick PR on GitHub so that we can merge the patch in?
Thanks!
---
[Visit Topic](https://discuss.tvm.apache.org/t/running-tvm-on-freebsd/8009/5)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
her
I agree with @tqchen. CSE is not hard to implement, and CSE on both sides
provides different benefits. So we can potentially support both variants.
---
[Visit Topic](https://discuss.tvm.apache.org/t/rfc-cse-optimization/8130/6) to
respond.
You are receiving this because you enabled mailin
CC: @Hzfengsy @spectrometerHBH if you guys are interested
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-a-general-task-extraction-mechanism-for-auto-scheduler/8444/6)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [cli
Thanks for bringing this up!
Context is indeed a bad name when it is used to indicate a certain device,
because its meaning really varies depending on the “context”. In this case,
“device” is certainly an acceptable name and is a lot better than “context”.
Two thoughts:
1) when referring to a
Yeah this change sounds quite reasonable to me. BTW, the DLPack case might be a
bit intricate, because it needs consensus across different frameworks, but
let's leave the discussion to DLPack RFC :slight_smile:
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-rename-tvmcontext-to-tv
My take on dropping the TVM prefix: given DLTensor/DLContext is the de facto
standard, we do not really need to define their TVM alias (e.g. TVMContext) and
can just use them directly
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-rename-tvmcontext-to-tvmdevice/9090/11)
to respon
Hey @srush,
Thanks for asking!
We are actively developing a more straightforward scheduling language and a new
IR called TensorIR:
* imperative scheduling: each schedule primitive is like applying a compiler
pass that transforms the TensorIR to a new TensorIR - you can see and debug the
sch
Hey @srush,
Thanks for your valuable feedback! Please allow me to try to explain the design
rationale below:
> **Q1.** There are strings for get_block?
Yeah. One design principle we hold for TensorIR is that all needed for
scheduling is contained in the TensorIR python syntax, so that there
> I’m still stuck on reverse_compute_at which seems like a long name, and is
> still a bit too magical for me to understand
Yeah I once had some discussion with @tqchen and @spectrometerHBH that
reverse_compute_at is too long and tedious, and I agree it will be great to
find some better names
In TVM we can define our own ReprPrinter for different subclasses of ObjectRef.
Try `LOG(INFO) << some_object_ref`
---
[Visit Topic](https://discuss.tvm.apache.org/t/debugging-libtvm-so/9134/2) to
respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from
Thanks @srush! I totally agree!
Simplifying the scheduling language is definitely an important issue,
especially when we want to approach broader audience.
An idea to make it happen is to compose schedule "primitives" into more
high-level "composite rules". For example, making "tiling + cache
@jroesch Is there anything we can do in the CI to enforce type annotation for
new code?
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-setting-up-mypy-type-checking-for-tvm-codebase/9231/12)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe
I vote for A0 after careful consideration. DLDevice requires extra knowledge of
DLPack
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-rename-tvmcontext-to-tvmdevice/9090/25)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these email
Yeah, to fully replace IRBuilder, there are still some missing elements of TVM
script: meta programming and hygiene macros. Let's consider the support after
the upstreaming is done :-)
CC @tqchen
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-tensorir-a-schedulable-ir-for-tvm/787
@masahi Yeah. We should allow to embed IR fragments, functions that produce IR
fragments, or replace some tokens with caller specified IR fragments into the
script :-)
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-tensorir-a-schedulable-ir-for-tvm/7872/61)
to respond.
You are r
Yeah here is the example:
https://github.com/dmlc/dlpack/tree/main/apps/from_numpy. Note that we assume
the array is on CPU because numpy arrays are cpu-only.
---
[Visit
Topic](https://discuss.tvm.apache.org/t/ndarray-conversion-to-numpy-array-take-time-around-350ms-with-a-simple-data/605
Also CC @zhiics @zxybazh @vinx13
---
[Visit
Topic](https://discuss.tvm.apache.org/t/pass-instrument-framework-proposal/9874/3)
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/un
Right now we allow adding attributes of operators in python:
https://github.com/apache/tvm/blob/main/src/ir/op.cc#L105.
I suspect that we don't have a public API to add operators on the python side
right now, and I don't know the reason why not. If you wanted to, you may just
expose `OpRegEnt
Thanks Chris! It is much more convenient :-)
---
[Visit
Topic](https://discuss.tvm.apache.org/t/announce-new-tvm-community-calendar/10111/2)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](https://discuss.tvm.apach
# [RFC] Meta Schedule
* Feature Name: Meta Schedule
* Start Date: 2021-05-28
* RFC PR: TBD (apache/tvm-rfcs#)
* GitHub Issue: TBD (apache/tvm-rfcs#)
## 1. Summary
This proposal introduces Meta Schedule: a probabilistic scheduling DSL on TIR
that unifies the approaches of AutoTVM and A
Thanks for the proposal! It is definitely extremely important for us to have
better type hints and documents for TVM scripts.
One quick question I have been thinking of: is it possible to unify and prevent
divergence between `tir.XXX` in the script and `tvm.tir` namespace? If so,
there probab
@Wheest I am not super certain if there is a fully automated process given our
current docstring-based type annotation may be casual or inaccurate, but it is
definitely doable if we could call for community contribution :-)
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-setting-up
@kparzysz Thanks for asking! For example, there might be some rare TVM
intrinsics like `tir.erf` that may be lowered to some cuda intrinsic (using
`Lowering`), but those intrinsics aren't guaranteed to exist on other hardware
platforms, and in this case, we substitute the intrinsic with more c
Sorry I was posting on a wrong thread
@kparzysz Thanks for asking! For example, there might be some rare TVM
intrinsics like `tir.erf` that may be lowered to some cuda intrinsic (using
`Lowering`), but those intrinsics aren't guaranteed to exist on other hardware
platforms, and in this case,
CC @jroesch @tqchen @zhiics @ziheng @yzhliu @masahi @thierry @haichen @Laurawly
@merrymercy @comaniac @FrozenGene @jcf94
As we are pushing for major doc refactoring work, we would love to hear more
from the community on the desirable doc structure, which is vital for our
community in terms o
I would prefer L2 in terms of more precise section titles. Sometimes it is
really hard to distinguish "User Guide" and "Developer Guide", and L2 replaces
them with more explicit terms "Tutorials by example", "Architectural guide by
each component of TVM system". The only thing missing here is
Thanks @mbs-octoml!
`Target` is a compile-time concept, while `device` is a runtime concept. The
separation design is to make sure that a target can describe a device that
doesn't exist on the host, mainly for cross compilation.
And yes, in principle, every `TargetKind` corresponds to a `DLDe
In other words, in compile time, IIUC we should replace `DLDeviceType` with
`TargetKind`
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-tvm-target-specification/6844/60)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [
Thank you @Mousius for the RFC! It's great to read about potential user
experience issues of the current Target system, and happy to discuss about
potential ways to improve it.
## Proposeds API in the RFC
`CompilationConfig`, as proposed in this RFC, aims to improve UX by wrapping a
list of
@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
@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
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
using assert_stmt is a valid approach
---
[Visit
Topic](https://discuss.tvm.apache.org/t/discuss-embed-more-bound-information-into-var-or-expr/4079/31)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](https://discus
It's not supported yet in TensorIR, but will be a good thing to have in the
future :-)
---
[Visit
Topic](https://discuss.tvm.apache.org/t/discuss-embed-more-bound-information-into-var-or-expr/4079/33)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscri
Looks like it could be abstracted as calling a packed function...On the
low-level you may use `call_packed` as demonstrated
[here](https://github.com/apache/tvm/blob/main/tests/python/unittest/test_te_tensor.py#L187);
CC @yuchenj on the high-level IR
---
[Visit
Topic](https://discuss.tvm
This is definitely extremely important! I would love to further discuss with
you on the environment variables used here. Do you think it’s possible to unify
DMLC_ and TVM_ environment variables? Is it possible to minimize the number of
env variables to use? Is there any precedent we could refe
Another idea @zxybazh and I have been discussing is the possibility to unify
Python and CXX logging system via packed functions, i.e. the CXX logging system
could potentially call back to python's logging module
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-better-tvm-logger-in-c
Shall we conclude this pre-RFC and send a formal RFC to
https://github.com/apache/tvm-rfcs/?
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-top-byoc-intel-libxsmm-integration/11688/15)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from
I'm happy to shepherd this RFC
CC: @spectrometerHBH @tqchen @areusch
---
[Visit
Topic](https://discuss.tvm.apache.org/t/bring-packedfunc-into-tvm-object-system/11816/2)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
he
Yeah I was on vacation and didn't track closely. Sorry for the confusion!
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-top-byoc-intel-libxsmm-integration/11688/18)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
To summarize our offline discussion with @areusch @tqchen.
Clarification:
1. This RFC doesn't change any of the existing functionality, including C ABI
or PackedFunc's C++ API. Any modification to the C ABI is out of scope of this
RFC.
2. Calling a PackedFunc inside TVM codebase directly uses
Let's leave this pre-RFC open for a week, and then send a formal RFC with
clarifications to https://github.com/apache/tvm-rfcs/
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-runtime-bring-packedfunc-into-tvm-object-system/11816/8)
to respond.
You are receiving this because you e
@cxy would you like to update the pre-RFC according to our discussion? Thanks a
lot!
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-runtime-bring-packedfunc-into-tvm-object-system/11816/9)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe f
Thanks for the proposal! We are very interested in improving search algorithms
and cost model. I was very excited to read about FamilySeer a week ago.
In terms of the subgraph similarity, AFAIK @comaniac and @zxybazh have been
working independently on this topic to improve overall search time
[quote="wrongtest, post:1, topic:12118"]
But certain pragma annotations can not get lowerer to `T.attr`，only those of
expression typed values are allowed
[/quote]
Would you like to elaborate? Currently the type of `AttrStmtNode::value` is
`PrimExpr`, but which type cannot be supported by TVMSc
This is definitely interesting usecases which unifies "AttrStmt" with
definitions of Attr otherwhere in the codebase. Given `AttrStmt` is something
we wanted to move away from, I would love to confirm with @tqchen that the
change is acceptable
---
[Visit
Topic](https://discuss.tvm.apache
It definitely makes sense for us to reduce the traffic from the github emails.
Github teams is definitely a good idea. I'm supportive 👍
---
[Visit Topic](https://discuss.tvm.apache.org/t/rfc-remove-codeowners/12095/4)
to respond.
You are receiving this because you enabled mailing list mod
How about we consolidate our discussion to the RFC thread
(https://github.com/apache/tvm-rfcs/pull/79) so that people can see what's
happening in a centralized place?
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-tvmscript-metaprogramming/12969/4)
to respond.
You are receiving
It is worth pointing out that:
* Most of the existing tests are CPU-bound, including those uses GPU for
execution (end-to-end tests), which also relies heavily on CPU for code
generation
* All e2e tests can be decoupled as host-side compilation on CPU + execution on
device (e.g. GPUs)
* Brute
A full-featured Llama2 implementation in only 200 lines of code based on this
project: https://github.com/mlc-ai/mlc-llm/pull/631
---
[Visit
Topic](https://discuss.tvm.apache.org/t/design-torchy-productive-model-definition-in-tvm-unity/15404/2)
to respond.
You are receiving this because
64 matches
Mail list logo
