Thanks @areusch.
> (tvm's present FuseOps pass is greedy and always combines kernels, but
> MetaScheduler does not necessarily
Just a small clarrification: TVM's FuseOps is greedy but CollagePartitioner may
require measuring (and thus tuning) many more TVM partitions/kernels. For
autotvm this is
We discussed this RFC at the TVM Community meeting. Here are some notes beyond
the [presentation
content](https://docs.google.com/presentation/d/1sRz8hVy_619VmbSRwJPGmcMfgBzaqMOAVaVNxlSgGFM/edit#slide=id.p):
- @mbs-octoml notes that this RFC isn't particularly set in stone and it may
grow/change
Merged #62 into main.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/62#event-6354521621
You are receiving this because you are subscribed to this thread.
Message ID:
Thank you Mark for this excellent RFC, and thank you everyone for your
feedback. This RFC is now merged. I'm really excited to see the results of this
project.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/62#issuecomment-1086224966
You are receiv
@manupa-arm can you take a look at Mark's revisions and let us know if this RFC
now looks good to you?
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/62#issuecomment-1085238048
You are receiving this because you are subscribed to this thread.
Messa
PTAL. Barring more github incompetence on my part I think I covered your
comments @manupa-arm. Thanks again.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/62#issuecomment-1081128633
You are receiving this because you are subscribed to this thread.
> I think you may have missed the comments that is hidden by Github
D'oh!
Hidden resolved conversations != Hidden because, you know, looks ugly if the
page is too long, or something.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/62#issuecomment-10
Hi @mbs-octoml ,
I think you may have missed the comments that is hidden by Github (happens to
me all the time :) ).
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/62#issuecomment-1080393193
You are receiving this because you are subscribed to this
PTAl, bumped to 0.81, thank you @manupa-arm, @mbaret and @cgerum, you've been
a great help.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/62#issuecomment-1079516472
You are receiving this because you are subscribed to this thread.
Message ID:
Thanks @manupa-arm for slogging through.
> This might enable bring us to down to get the cost estimation but it will
> still explore the combinatorial partitioning possibilities of ops x backends,
> right ? (lmk, if I am wrong here).
Any sensible implementation of CostEstimator should cache by
> No. As far as Collage is concerned it just calls the abstract
> CostEstimator::Estimate interface for each candidate partition, and can
> remain ignorant as to where those costs come from. In the prototype it is
> hard coded to tune, build and run locally to help us get going. Here at
> OctoM
> Is there a model being developed to estimate latency of the chosen
> partitioning?
No. As far as Collage is concerned it just calls the abstract
CostEstimator::Estimate interface for each candidate partition, and can remain
ignorant as to where those costs come from. In the prototype it is h
> 1.) How can a user export the search done by collage ? i.e. similar to
> loading tuning logs where ApplyBestHistory is done.
Having thought about this more, If there can be a way to define a PartitionSpec
that is tied with DFS IndexSet that could be exported and imported, that might
work out.
PTAL all, thanks.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/62#issuecomment-1076832944
You are receiving this because you are subscribed to this thread.
Message ID:
Bumped version to 0.8 based on extensive reworking due to excellent comments
above -- thanks!.
I still need to expand the PartitionRule section, should be ready tomorrow.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/62#issuecomment-1076751653
You
Hey all, heads up I'm taking a close look at the 'pass ordering' problem hiding
in this RFC. That is, as written and prototyped, CollageFuseOps runs just
before the current FuseOps so that it can 'see' rewrites which guide TVM's
native fusion rules. However some of those rewrites are target spec
@manupa-arm would be great to get your view on this too
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/62#issuecomment-1069262209
You are receiving this because you are subscribed to this thread.
Message ID:
17 matches
Mail list logo
