Couldn’t this be implemented as a custom IR pass (in Python or C++) instead of
as a new scheduling primitive? This is essentially taking the body `b` of a
`For` and replacing it with `Block(prologue, b, epilogue)` right?
---
[Visit
Topic](https://discuss.tvm.ai/t/add-support-for-extern-pr
This is really impressive work, congrats!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/dmlc/tvm/issues/4105#issuecomment-541259191
Thanks @nihui, @tqchen, @jwfromm.
I generalized this approach to handle devices that don't support the push
descriptor (see the Stream::LaunchDeferred APIs), and devices that don't
support dedicated allocation APIs, and removed the previous runtime
implementation as @tqchen suggested. I also a
@nihui would you be interested in taking a look at this PR and this approach?
Are there more useful things in NCNN’s Vulkan backend that TVM should learn
from?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github
cc @jwfromm, @tqchen
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/dmlc/tvm/pull/3849#issuecomment-525639619
In the Vulkan API, it is recommended to launch multiple command buffers per
kernel. See
http://on-demand.gputechconf.com/gtc/2016/events/vulkanday/High_Performance_Vulkan.pdf,
https://devblogs.nvidia.com/vulkan-dos-donts/, etc. The extant TVM Vulkan
runtime uses one command buffer per kernel, w
@tqchen sure, will do on the weekend.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/dmlc/tvm/pull/3567#issuecomment-517901933
Will do today @tqchen, my bad.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/dmlc/tvm/pull/3567#issuecomment-515897387
@weberlo eg CPU CNNs like mobilenet, resnet, etc. One thing not supported is eg
tvm.extern since we don’t support packed funcs.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/dmlc/tvm/pull/3567#issuecomm
@tqchen does this look good to you?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/dmlc/tvm/pull/3567#issuecomment-514055095
OK, so changes planned are:
- Move this to `src/runtime/micro/standalone`
- Rename flag from `MINIMAL_RUNTIME` to `MICRO_STANDALONE_RUNTIME`
- Fix CI
Will work on it right now, thank you folks.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or
> This looks great. As mentioned above it potentially fits well with uTVM. For
> use with uTVM it would be useful to have this runtime or a derivative built
> in C rather than C++ in order to be deployable to the various embedded
> environments out there that don't have C++ runtime / tooling sup
@tqchen yes absolutely - from talking to you yesterday I hadn't thought of the
uTVM application, but it certainly could be interesting. One possible
improvement in that direction could be to create a mmap'able representation of
the parsed graph_json, i.e. these fields of `MinimalGraphRuntime`:
## Summary
This is an alternative implementation of a subset of the TVM runtime API (and
graph runtime) that focuses entirely on reducing code size, at the expense of
functionality (no tvm.extern(..) calls via PackedFunc, CPU only, etc). It might
be worth incrementally expanding the surface area i
cc @hlu1 re: the leak from e.g. recursive functions taking a reference to
itself in the environment.
FWIW, can we solve these via adding the concept of weak references to the node
system? It seems like in these cases that closures could use weak references to
other closures, and have the higher
This looks like a great design, and should handle all the applications I'm
currently thinking of. @jroesch let us know if we can help.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/dmlc/tvm/issues/3042
@liangfu this looks quite interesting. Does MISRA compliance affect the
compiler or the generated code as well (i.e. how do we certify that the output
of e.g. LLVM is correct, doesn't segfault, etc?).
WRT to the minimal runtime I put together that `bundle_deploy.cc` list quite
quickly, I think
+1
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/dmlc/tvm/issues/2973#issuecomment-480743132
18 matches
Mail list logo
