CC: @jroesch @icemelon9 @kparzysz-quic @FrozenGene @jcf94
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/5#issuecomment-857460287
Hi all,
$python -m tvm.driver.tvmc
/usr/bin/python: No module named tvm.driver
Is that TVM bug?
--
Best Regards,
Yu Rong Tan
-
To unsubscribe, e-mail: dev-unsubscr...@tvm.apache.org
For additional commands, e-mail: dev-h...@tvm
Thanks for the RFC. I have two questions:
1. How to mark/set the color (i.e., attribute) of every operator?
2. It seems to me that if we register a casting checker instead of just a label
(color), then we can simplify the algorithm a lot. Taking the case `A(green) -
B(gray) - C(green)` as an exam
> Thanks for the RFC. I have two questions:
>
> 1. How to mark/set the color (i.e., attribute) of every operator?
> 2. It seems to me that if we register a casting checker instead of just a
> label (color), then we can simplify the algorithm a lot. Taking the case
> `A(green) - B(gray) - C(green
Thanks for the answers. I'll review the PR to get more implementation details.
One more question regarding the extensibility: can this be extended easily to
support bfloat16?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
h
> Thanks for the answers. I'll review the PR to get more implementation details.
> One more question regarding the extensibility: can this be extended easily to
> support bfloat16?
It should be trivial (hope I don't eat my words). I'm not 100% sure of the
support for bfloat16 in current relay op
I don't know Chris Sullivan's github handle so if someone could cc him too that
would be great.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/6#issuecomment-857931228
CCing @csullivan
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/6#issuecomment-857933603
> > Thanks for the answers. I'll review the PR to get more implementation
> > details.
> > One more question regarding the extensibility: can this be extended easily
> > to support bfloat16?
>
> It should be trivial (hope I don't eat my words). I'm not 100% sure of the
> support for bfloat16 in
hey sorry for the delayed reply- in terms of the timeline we are trying to
upstream and open source the work around Q3 this year, and in the mean time I'm
going to be starting upstreaming TVM improvements. Generally we still could use
a good amount of training operator coverage (gradients, los
##
This RFC is a case study on unifying the lower API, which had implementations
in both Python and C++. I'll call the duplication of APIs in Python and C++
"bifurcation" or "bifurcation of the API". I'll conclude by analyzing how this
bifurcation happened in the first place, and then presen
Option 2 would be easier to police since it is a single-stage solution. No need
to add the new API then remove the prototyping API which would be multiple PRs.
Option 1 would need a tracking ticket to track the removal of the python code
or the removal will be ignored and the problem will pers
Thanks @electriclilies for writing the summary. Would like to share some
thoughts along these lines. The particular discussion are related to two design
principles we followed so far.
### C0: Python as a First Class Citizen
One of the key design principles we have followed so far is to make p
13 matches
Mail list logo
