Thank you for the help. Here's what I've learned and found issues.
* This is what I tried inside the my custom tuner.
cfg = FallbackConfigEntity()
func_name = self.task.name // conv2d_nchw_winograd.cuda
ref_log = autotvm.tophub.load_referernce_log( target.target
@KireinaHoro Yes, OpenOCD is unfortunately very slow. The way I've sped things
up in my personal usage has been to run AutoTVM with 8 microcontrollers, but
I'd like to have a solution that doesn't require "brute forcing" it with
devices.
Do you have the `check_correctness` option set? If so
> Is *fallback_with_reference_log* the one I can use? I’m not sure since it
> does not return any configuration. (Seems like it applies directly to the
> kernel?)
Yes this is the one. It didn't return because it is a method of a config
entity. What it did was copying the config map from oth
Thanks for the advice. This seems like a good start.
I've been playing around with auto-tuner module and thinking that we may
utilize the performance of the default schedule during the tuning process.
2nd approach seems more relevant for my purpose. Rather than defining a default
configuratio
It depends on the schedule function. For example:
1. Directly define a default configuration.
https://github.com/apache/incubator-tvm/blob/master/topi/python/topi/x86/conv2d.py#L36
2. Load the best configurations of similar workloads and make a one.
https://github.com/apache/incubator-tvm/blo
Besides, I'm wondering if the AutoTVM implementation for uTVM in
https://github.com/apache/incubator-tvm/pull/4274 is complete: I can only find
some RPC server modification, but not how to bridge the micro build process
into `LocalBuilder`. As I'm on a deadline, I'm simply hacking into the
c
Spike accepts `remote-bitbang` protocol, which is exactly how OpenOCD itself
communicates with Spike. The protocol should not be too complex to implement,
since we only need `Read` `Write` and `Execute`.
I'm actually working on a second implementation for `LowLevelDevice` for Rocket
Chip (RI
we could also explore a possibly alternative approach to hook up spike
directly(not via openOCD), which might enable us to get around the problem of
data copy speed(via directly memory copy shortcuts into the simulator).
openOCD is only one way to implement
https://github.com/apache/incubat
Dear all,
What is the ONNX compatibility of the latest incubator-tvm version? (onnx
v1.5?)
Does incubator-tvm supports the classical ML operators described in onnx-ml
(svm, tree, linear classifier, etc)?
I also understand that the llvm cpu backend supports more than the opengl
or
I'm trying to do some autotuning with MicroTVM RISC-V Spike. It seems like the
current implementation will write input arrays to the device over OpenOCD,
which is prohibitively slow when the input gets bigger (e.g. 512x512 `int8`
arrays). To my understanding, we should be able to omit the da
I see! That's a very good question. I'm not sure to be honest. I wanted to look
into it myself for measuring a performance baseline for each kernel before
autotuning. I'll look into it the next days when I have spare time. Please let
me know if you have found something in the meanwhile..
With the [VTA's convolution optimization
tutorial](https://docs.tvm.ai/vta/tutorials/optimize/convolution_opt.html), I
can see the lowered IR as follow after virtual threading
```
// attr [data_buf] storage_scope = "global"
allocate data_buf[int8 * 65536]
// attr [kernel_buf] storage_scope = "
12 matches
Mail list logo
