-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initial implementation for simple scheduler #589
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice. And just at the right moment :).
Is this related to 6AM moment? |
dependencies(scheduler.dependencies) {} | ||
|
||
llvm::SmallVector<mlir::Operation *> Scheduler::getScheduleableOps() { | ||
llvm::SmallVector<mlir::Operation *> scheduleableOps; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: You could also keep this as part of Scheduler state in order to avoid iterating over all unscheduled ops. Might be a premature optimization tho.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had that implementation for pybuda scheduler. I didn't like it it wasn't readable. If it proves that this is too slow we can change
Scheduler::Scheduler(func::FuncOp *func) { | ||
for (auto &op : func->getOps()) { | ||
if (isTTIROp(&op) && isDpsOp(&op)) { | ||
dependencies[&op] = {}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it possible to use op->getOperands() instead of having dependencies as part of scheduler state?
* Scheduler assumes that input is `FuncOp` which contains single `FuncOp` * Scheduler constructs dependency graph using TTIR ops. * This excludes ops like `ttnn.open_device`, `ttnn.close_device`, we need to find some way how to handle them i.e either scheduler puts them at the start/end of schedule or we handle them in some different way. * Snapshotting creates deep copy of scheduler members * Tested by creating pass which printed dependency graph of some more complex graph that was handcrafted (didn't include pass nor test code in PR but I can do if needed).
d300d4c
to
efca59d
Compare
ModuleOp
which contains singleFuncOp
ttnn.open_device
,ttnn.close_device
, we need to find some way how to handle them i.e either scheduler puts them at the start/end of schedule or we handle them in some different way.closes #571