# \[RFC\] 'Cascade' Scheduling

**URL:** <https://discuss.tvm.apache.org/t/rfc-cascade-scheduling/8119>\
**Category:** RFC\
**Created:** [October 8, 2020, 2:16pm UTC](https://discuss.tvm.apache.org/t/rfc-cascade-scheduling/8119 "2020-10-08T14:16:26Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![aca88](https://discuss.tvm.apache.org/letter_avatar_proxy/v4/letter/a/ed8c4c/32.png) [@aca88](https://discuss.tvm.apache.org/u/aca88)\
**Post date:** [October 8, 2020, 5:42pm UTC](https://discuss.tvm.apache.org/t/rfc-cascade-scheduling/8119/4 "2020-10-08T17:42:23Z")

</div>

Glad to see a proposal with such functionality.

I have to admit that I had also done something similar to what you are proposing (at least at the TE level).

One problem I had was enlargment of the tensor iteration domains ([[TVM Scheduling] Split factors missmatch to original extent - #2 by aca88](https://discuss.tvm.apache.org/t/tvm-scheduling-split-factors-missmatch-to-original-extent/2982/2)). This had the problem of many inner loops being mostly “out of original domain” which was really not performant or a huge explotion of “program code” to statically solve all those ifs.

Another problem you would face are the limitations of FuseOps. Without any change here, I dont know how you would “automatically” get those composed stages you will need in order to schedule them.

Nonetheless, for specific configurations of layers, I think what you propose is a reasonable way of processing. Rolling buffers would make it even sweeter.

## side note

> [@mbaret](#):
>
> Determining whether continuing a cascade is profitable would be one of the jobs of the cascading algorithm.

This kind of reminds me of the “graph tunner” infrastructure.

Maybe there should be a more general infrastructure for doing “graph level tunning” (I think the current one only tunes w.r.t. different layout transformations).

---

_[View the full topic](https://discuss.tvm.apache.org/t/rfc-cascade-scheduling/8119)._