Merged #107 into main.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/107#event-12166219733
You are receiving this because you are subscribed to this thread.
Message ID:
This has been approved a few days back, so merging it now so that we continue
the discussions in the context of the tracking issue and upcoming PRs.
Thank you for all the discussion everyone!
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/107#issue
I think it is helpful to add a discussion about how the flow would fit into the
DLight usecases. I don't think it would likely cause too much of an overhead :)
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/107#issuecomment-1991996163
You are recei
Thanks @tqchen, at the moment the Relax flow would be out of scope for our
current use-cases, although we'd want to make sure this RFC doesn't introduce
obstacles for porting to the Relax flow in the future. Do you foresee any
blockers with the current approach, or could we consider merging?
--
Thanks @lhutton1 , for relax and moving forward, one canonical example that can
be helpful is the
[https://github.com/apache/tvm/tree/main/python/tvm/dlight](dlight) package,
which defines pattern matching and apply of transforms, that can then be used
as part of pass.
Right now dlight starte
Thanks for the discussion so far @tqchen, I added a small example detailing how
we're registering schedules for the Relay flow. I believe this will have
minimal impact for how the schedule might be used in a Relax based flow, but it
would be good to hear your thoughts.
--
Reply to this email d
Got it, thanks @tqchen :) It sounds as though we're already doing something
similar by adding a tag in the compute definition to identify the block during
scheduling.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/107#issuecomment-1945716982
You ar
to clarify a bit, we do need have to ask for doing everything as form of
schedule, so it is OK for example to generate a compute definition that already
contains packing (you can view that as one special dispatch pass).
The main ask is that the TIR schedule pass should detect the already packed
Thanks for taking a look @tqchen! Since scheduling will be completed with
TensorIR, it will provide the building blocks for being plugged into an
IRModule=>IRModule transformation pass. For our current use-case, it's
important to be able to fallback to previous optimizations in the form of TE
s
I like how we can leverage tensorization and keep most things within the
existing infrastructure. Would love to see how we can align some of the
scheduling support towards IRModule=>IRModule transformation in dlight style
mechanisms, so we can get even better composability.
I take sometime to w
10 matches
Mail list logo
