This sounds good to me. AFAIK, PyTorch also leverages this approach so it might
not be that "non-standard" 😜
---
[Visit
Topic](https://discuss.tvm.apache.org/t/allow-merging-via-pr-comments/12220/2)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe
The way you use is for static link for the generated code why the error is for
dynamic link. As @masahi pointed out, you should link your .so to TVM, which
means you may need to add this library to the TVM building process.
---
[Visit
Topic](https://discuss.tvm.apache.org/t/byoc-how-to-li
I think that's what @driazati meant. "Removing" CODEOWNERS doesn't mean to
remove but rename that file: https://github.com/apache/tvm/pull/10192
---
[Visit Topic](https://discuss.tvm.apache.org/t/rfc-remove-codeowners/12095/10)
to respond.
You are receiving this because you enabled mailin
Supportive. It's tedious that Apache org creates many barriers for us to
leverage a more systematic way, but the proposed solutions with a number of
bots to assist the review process are definitely helpful.
Meanwhile, I recall that one important reason of adding code owners is to help
improv
It seems not impossible to me, since `ExternOp` doesn't even have a schedule
but simply calls an "extern" implementation such as CuBLAS.
---
[Visit
Topic](https://discuss.tvm.apache.org/t/autoscheduler-do-we-have-plan-to-support-auto-schedule-externop/10346/11)
to respond.
You are receiv
The RFC has been merged: rfcs/0046-Intel-LIBXSMM-integration.md
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-top-byoc-intel-libxsmm-integration/11688/16)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](ht
I like this proposal a lot. Here are my two cents in terms of use cases.
In the C++ side, PyTorch has two logging systems:
- `LOG(LEVEL)`: This is what we familiar with, including DEBUG, INFO, WARNING,
and FATAL.
- `VLOG(INT_LEVEL)`: This is only for debugging, `INT_LEVEL` could range from 0
t
I agree with @tqchen that improving composite targets could be more beneficial
and general. We (with @junrushao1994 and @zhiics) previously attempted to
improve the target system to allow more flexible attributes, such as a pass
sequence / runtime / etc specifically for the target, which is ve
Yeah I can see the difficulty you mentioned, and it might be possible that nvcc
is not available in runtime if the model is deployed to an edge device.
A combined approach would be leveraging the third BYOC option: custom
codegen/runtime. Specifically, we still generate the C/CUDA kernel and c
Your solution makes sense to me. This mechanism is used for the case that a
BYOC backend attempts to manage the constant values with certain processes,
such as layout transform. It works well for other codegens (e.g., JSON), but as
you pointed out, we never really solve this problem for C code
I also feel it might not be helpful to call `ReleaseAll` when encountering OOM.
`ReleaseAll` basically only address the fragmentation issue by recycling unused
unfit memory chunks and allocating a new fit chunk, so it cannot help if memory
is allocated and being held by a NDArray. The best mov
IMHO, the docs should serve for two major purposes:
1. For pure users who don't care how TVM is implemented but just want to
achieve high performance, we need to let them hands on as convenient as
possible.
2. For new developers who want to improve something with TVM, we need to let
them know
It's possible that those ops need a finer control to buffers and it is hard to
achieve in TE, but I didn't write those ops so I don't know the exact reason.
---
[Visit
Topic](https://discuss.tvm.apache.org/t/autoscheduler-do-we-have-plan-to-support-auto-schedule-externop/10346/5)
to respo
I guess the reason it needs a wrapper is because they are written in TIR
instead of TE? Since AutoScheduler can only tune TE compute, it cannot tune
such ops anyways. On the other hand, the AutoTIR that @junrushao1994 is working
on supports tuning for all levels so you may look forward it.
Me
Thanks for the efforts. I left some comments in the doc.
In addition, I'm wondering if we could add a text box to all "other" options so
that people can specify what they really have.
---
[Visit Topic](https://discuss.tvm.apache.org/t/tvm-community-survey/10305/3) to
respond.
You are rece
Here are my two cents before diving into the detail code review.
1. At the first glance most implementations, including the Relay passes, were
done in Python. It would be better to implement them in C++ for better
performance.
2. The term and namespace "subgraph" is improper and confusing.
3.
Vote for A0 +1 to make it more modulized.
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-rename-tvmcontext-to-tvmdevice/9090/24)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](https://discuss.tvm.apache.or
Agree on this change. Context is more like a region or environment for certain
processes. For example, "DispatchContext" and "PassContext" are reasonable
naming because they are usually used with `with`. On the other hand, TVMContext
includes just the device information, so it is more like jus
Sounds good to me for now. We could check whether it is too user unfriendly or
not in the PR and improve it if needed.
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-byoc-android-nnapi-integration/9072/7)
to respond.
You are receiving this because you enabled mailing list mode.
Thanks for the clarification, so the codegen has to generate and compile C++
code to be a shared library; while runtime needs to construct a model graph (or
engine). It seems clear to me, and we could discuss the implementation detail
about when and where to invoke `clang++` in the PR.
For te
Glad to see this is being planned! I could help on this as much as I can.
One question/suggestion is that if we are going to have such formal
benchmarking approach, maybe we can make it MLPref friendly so that everyone
can use this TVM utility to run these models on the target platform and sub
I got the same problem and filed a PR to workaround it.
https://github.com/apache/incubator-tvm/pull/6939
---
[Visit
Topic](https://discuss.tvm.apache.org/t/conflict-with-xgboost-when-thrust-is-enabled/6889/6)
to respond.
You are receiving this because you enabled mailing list mode.
To
Thanks all for the valuable feedback. Here is the summary of the finalized RFC:
### Interface
- When extracting auto_scheduler tasks, users simply call `extract_tasks`.
- `extract_tasks` now has an optional flag `include_simple_task` (default
`False`). When set, each Relay function, including t
So you meant the use case would be like the following?
```python
with auto_scheduler.ApplyHistoryBest(log_file):
with PassContext(opt_level=opt_level, config={use_topi_schedule: False}):
lib = relay.build(mod, target=target, params=params)
```
---
[Visit
Topic](https://discuss.
This is a good question. This is possible for the current implementation,
because we use Relay op strategy to define auto_scheduler tasks as well. In
other words, we use Relay FuseOps to define the task scope, and should be able
to choose to use TOPI (AutoTVM) or auto_scheduler schedule for ea
1. We haven't figured out the plan yet, but mixing them up is definitely a
trend.
2. In order to make task extraction and schedule application align, we follow
the same flow as building a model to extract tasks. Both AutoTVM and
auto_scheduler leverage this approach.
---
[Visit
Topic](h
We haven’t planned that far yet, as currently we lower a Relay function to a TE
compute, which relies on Relay op strategy to map Relay ops to TOPI computes.
I’m not familiar with custom Relay ops, but it would be great if you have any
suggestion that could make this RFC potentially work for c
Here are some more details about the interface change in this RFC. The new
added `use_topi_schedule` flag is propagated from the compile engine to
`relay._build`. As a result, this actually doesn't expose to users. The use
cases are the following:
1. Use TOPI schedule with fallback values (sa
Thanks for the comments.
> May I ask how the graph ends up with a `nn.conv2d + nn.relu + nn.conv2d +
> nn.relu` ? Is the graph going through a BYOC kind of partitioning (sorry if
> the question is naive)?
There is nothing to do with BYOC. My point is that Ansor opens the door to
subgraph-l
The current approach used by auto_scheduler to extract tuning tasks leverages
Relay op strategy. In short, auto_scheduler registers an implementation in
Relay op strategy as AutoTVM, but instead of using the TOPI schedule function,
auto_scheduler creates an empty schedule and extracts the lowe
Another requirement I have for the general TE translator is to support an
arbitrary Relay function, including the Relay function with more than one
reduce op (e.g., conv2d). The current compile engine doesn't allow this pattern
because it selects one schedule implementation per Relay function,
Thanks for clarification and now I feel we are on the same page. For the idea
of StrategySelector, I have no idea for now and would like to know opinions
from other as well.
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-refactor-the-compile-engine-to-expose-a-relay-te-translator/
Thanks for the RFC! I do agree that it would be great to create an additional
path to improve the flexibility, especially now we have auto_scheduler to
schedule a TE graph from scratch (cc @merrymercy).
Meanwhile, I think tightly-coupled the selection of schedule and compute is
intentional be
> @comaniac in my case it happened when I was logging the config at the top of
> a compute / schedule function, before all knobs were defined, which is
> sometimes useful given the dual collect / apply behavior of config.
Make sense. That's also the only case I can think of.
> True, but on su
It's an interesting finding. Could you elaborate a case that `__repr__` is
invoked before config collection?
On the other hand, your suggested change will make the caching useless, because
`ConfigSpace._collect` is always true. A more safer solution could be like:
```python
def _add_new_trans
This is flaky due to the slow CI machines. I noticed this issue as well in my
PR (https://github.com/apache/incubator-tvm/pull/6713) and have fixed it.
---
[Visit
Topic](https://discuss.tvm.apache.org/t/ci-is-still-failing-in-docs/8266/2) to
respond.
You are receiving this because you en
Congrats @junrushao1994!
---
[Visit
Topic](https://discuss.tvm.apache.org/t/community-junrushao1994-committer/8220/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/unsubscribe
>From your response to TQ I feel that the current limitation is mainly from the
>TOPI implementation, which fixed the granularity of conv2d schedule. This
>limitation, however, can potentially be resolved by auto-scheduler (Ansor). In
>fact, we AWS is attempting to use Ansor to perform more a
For the pending PRs, we could have TensorRT and Xilinx Vitis-AI as v0.8
experimental features.
---
[Visit Topic](https://discuss.tvm.apache.org/t/discuss-tvm-v0-8-roadmap/8139/2)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [
Thanks for the RFC!
While I'm not familiar with the current RISC-V applications, I'm carious about
the purpose of running Spike simulator and what would be the usual next step
after it.
I also have some questions/thoughts about the implementation. In general I'm
thinking if it would be better
@junrushao1994 do you have an idea for this error before diving into it?
---
[Visit
Topic](https://discuss.tvm.apache.org/t/append-a-custom-target-for-tvm-context/7925/5)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
h
Thanks for the clarification :) So this is more like a tool to facilitate the
development process. After the C++ code has been generated, we can continue
working on it as always.
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-tvm-object-schema-dsl/7930/4) to
respond.
You are re
Thanks for the RFC and it looks super useful! I have two questions from the RFC:
1. Are the generated .h and .cc files supposed to be tracked in the repo, or
they are more like the build files?
2. For the in-place modification, I am a bit confused about the example of
customized C++ code (the
You can first register a target using `TVM_REGISTER_TARGET_KIND` macro in
`https://github.com/apache/incubator-tvm/blob/master/src/target/target_kind.cc`.
Then register OpenCL codegen as your backend.
This doc can help you get familiar with the compilation flow, and you can add
corresponding
Thanks for clarification. Make sense to me.
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-tensorir-a-schedulable-ir-for-tvm/7872/19)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](https://discuss.tvm.apac
So the scenario is like you can choose to use TE or TIR to write a compute, but
if you choose TE, you have to first lower it to TIR and then add schedule
primitives?
IIUC, it seems to me that this is nontrivial, because TIR was not written by
human and you may need to first print it out to fi
Thanks for the proposal! This definitely opens more opportunities for
performance optimization. Two questions for clarification:
1. IIUC, based on the proposal and discussion, we will have both TE and TIR,
but TE is more like a frontend wrapper of TIR to serve some users that prefer
to write
I think that's indeed the must. We did it for C++ codes when enabling
clang-format.
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-introduce-automatic-formatting-of-python-code/7843/7)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from
I know very few about `Black` so I did a quick investigation. The biggest
difference is that `yapf` may have non-deterministic results in the same code;
while `Black` guarantees the deterministic results.
In addition, although `Black` has much fewer options than `yapf`, looks like we
can stil
I'm expecting this for a long while so thanks for bringing up! I used `yapf` is
just because I know this package. It's fine to use `Black` or `autopep8 ` after
a brief investigation.
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-introduce-automatic-formatting-of-python-code/7843/
50 matches
Mail list logo
