Thanks for the comments.

> May I ask how the graph ends up with a  `nn.conv2d + nn.relu + nn.conv2d + 
> nn.relu`  ? Is the graph going through a BYOC kind of partitioning (sorry if 
> the question is naive)?

There is nothing to do with BYOC. My point is that Ansor opens the door to 
subgraph-level scheduling, but the current Relay fusion mechanism limits a task 
to a subgraph with a single reduce op. With this RFC, people can investigate 
fusion strategies without any limitations. For example, one of our talk in the 
upcoming TVM conference (title: Graph-Level Scheduling Optimization with 
Polyhedral Analysis for Tensor Programs) will introduce our initial efforts on 
investigating the opportunities of fusing reduce ops. This kind of researches 
will be hard to proceed without this RFC.

> As for S1 vs S2, could we do both? Use an heuristic like “ignore the task 
> without any call node” and then let the task scheduler judge if it needs to 
> spend time on the task?

Yes we could. This issue is actually about the flexibility vs. user experience. 
If we filter tasks during extraction process, users will see fewer tasks (and 
may feel more comfortable), but advance users may want to see all tasks to 
perform other things such as improving the task scheduler, etc.





---
[Visit 
Topic](https://discuss.tvm.apache.org/t/rfc-a-general-task-extraction-mechanism-for-auto-scheduler/8444/3)
 to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, [click 
here](https://discuss.tvm.apache.org/email/unsubscribe/dfb458c2c796a3e0936fdbb165c337772de6f2860f8a0402f23c113dce7ab993).

Reply via email to