Re: [apache/tvm] [Pre-RFC]FamilySeer: A new search method for Auto-scheduler (PR #10308)
Hi, would you please retrigger the CI by sending an empty commit? -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm/pull/10308#issuecomment-1049605201 You are receiving this because you are subscribed to this thread. Message ID:
[Apache TVM Discuss] [Announcement] TVM Community Meeting, November 18 2021
Hi Chris, is there a plan when the next TVM Community Meeting is going to take place? Especially the "Remove CODEOWNERS" discussion seems to be a good fit for a high-bandwidth discussion: https://discuss.tvm.apache.org/t/rfc-remove-codeowners/12095/8 Thanks, Michael CC: @hogepodge @aca88 @SebastianBoblestETAS @areusch --- [Visit Topic](https://discuss.tvm.apache.org/t/tvm-community-meeting-november-18-2021/11475/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/591cb1c96136e7a68ee624cf6fc2a5f425521de0ad85d01961ce18e63c8e56b3).
[Apache TVM Discuss] [Development/pre-RFC] [RFC] UMA: Universal Modular Accelerator Interface
Hi @MJKlaiber ,
Apologies to for not getting back to this in time.
Thanks for the proposal! and it broadly looks like wrapping the Target Hooks
RFC (by @Mousius ) :
https://github.com/apache/tvm-rfcs/blob/main/rfcs/0010-target-registered-compiler-flow-customisation.md,
and exposing a nice/structured interface to python. It is nice to see progress
on this :) .
I would like to suggest potential text changes for the formal RFC to those of
us who are familiar with the existing flow (specially around naming).
[quote="MJKlaiber, post:1, topic:12039"]
UMA Partitioning:
* Register relay passes
* Register patterns - supported sub-graph operations
* Order: pre-partitioning passes, Graph partitioning, post-partitioning passes
* UMAPartitioner baseclass (Python only) has to be inherited by
accelerator-specific Partitioners (e.g. Accelerator A Partitioner, etc)
[/quote]
Maybe it is worth mentioning these are current implemented as
partition_for_\<(backend\target)\> ?
https://github.com/apache/tvm/blob/f1ff61a7b9adb61eaa0db842bbf71c704d350154/python/tvm/relay/op/contrib/dnnl.py#L210
https://github.com/apache/tvm/blob/f1ff61a7b9adb61eaa0db842bbf71c704d350154/python/tvm/relay/op/contrib/tensorrt.py#L83
https://github.com/apache/tvm/blob/f1ff61a7b9adb61eaa0db842bbf71c704d350154/python/tvm/relay/op/contrib/ethosu.py#L1660
I am a bit curious, why this interface is specifically positioned as an
"accelerator" (as in UMA) partitioner though ?
i.e. Would it not be used to support optimized library support as we currently
have today with BYOC ?
[quote="MJKlaiber, post:1, topic:12039"]
```
class MyCustomAcceleratorPartitioner(UMAPartitioner):
@property
def target_name(self):
return "my_custom_accelerator"
def _register_patterns(self):
self._register_pattern("conv1d_relu", conv1d_relu_pattern())
def _register_relay_passes(self):
self._register_relay_pass(1, ConfigGenerator())
self._register_relay_pass(2, BufferScopeAnnotator())
```
[/quote]
Since the proposal suggests to use the properly registered targets, any reason
should we stick to target_name (str) as opposed to the actual TargetKind ?
Following up on the above question, what are your thoughts on moving the
UMAPartitioner inside relay.build(...) ?
Also this seemed to be proposed on using S-TIR (as opposed to "legacy" TE->TIR
pipeline), would you be able to share the motivation to the partitioning of
tir_schedules and tir_passes ? (Im asking mainly because they will all be S-TIR
--> S-TIR IRModule passes).
Following from the above question, is there an ambition to handover S-TIR back
to the core compiler ?
Following up on Mark's comments,
[quote="mbs-octoml, post:5, topic:12039"]
My group here at OctoML have been looking at bringing a backend placement
search capability to TVM, a la the ‘Collage’ paper
([https://arxiv.org/pdf/2111.00655.pdf
](https://arxiv.org/pdf/2111.00655.pdf)). Under that approach there’s no longer
a notion of a BYOC uniquely partitioning the graph according to its rules and
heuristics in ‘one shot’. Instead the BYOC must convey the rules (patterns,
predicates) for which operators could potentially be offloaded, and leave the
actual partitioning to the main Collage searcher.
[/quote]
Mark, we are quite looking forward for the RFC for this, especially related to
reference-level explanation to see where this work is headed -- which I believe
might be better to know in this mutual interest of structuring BYOC targets.
However, I think we all share the ambition to replace kCompiler strings to be
targets if can get more support from the community.
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-uma-universal-modular-accelerator-interface/12039/11)
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/70a91c3429ea525fc3b94a58d070b1b823d4e916f5277fe8ed3bfffa12c7b64b).
[Apache TVM Discuss] [Development/pre-RFC] [RFC] Remove CODEOWNERS
@driazati @areusch , This looks like a great suggestion!. I think the proposal is about adding a mechanism to use the cc tag to attach people as reviewers, which seems good step. I agree with @comaniac by helping the new authors finding people to tag for reviews rather than doing a mandatory review requests for many committers. Secondly, I think this is not really removing the CODEOWNERS but rather removing mandatory reviewer assignment from CODEOWNERS (maybe a text change ?). Otherwise, how would we populate the list to help new authors ? cc : @leandron @Mousius , PTAL when you have some time. --- [Visit Topic](https://discuss.tvm.apache.org/t/rfc-remove-codeowners/12095/9) 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/b7a5fcae1a054241c6a979c4ab1b12e2abd982f1c36a42948db992b1d15eccd9).
Re: [apache/tvm] [Pre-RFC]FamilySeer: A new search method for Auto-scheduler (PR #10308)
Sure. @zxybazh -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm/pull/10308#issuecomment-1049924550 You are receiving this because you are subscribed to this thread. Message ID:
[Apache TVM Discuss] [Announcement] TVM Community Meeting, November 18 2021
@MJKlaiber I'm going to take on hosting the community meetings from Chris shortly. I'm just checking on a few last things before posting up about it. --- [Visit Topic](https://discuss.tvm.apache.org/t/tvm-community-meeting-november-18-2021/11475/4) 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/c1b63d17a3fc3aa081fe53387c5eeea3a8db7e2ba6098377b9f1bb3f1ec87217).
[Apache TVM Discuss] [Development/pre-RFC] [RFC] Remove CODEOWNERS
I think that's what @driazati meant. "Removing" CODEOWNERS doesn't mean to remove but rename that file: https://github.com/apache/tvm/pull/10192 --- [Visit Topic](https://discuss.tvm.apache.org/t/rfc-remove-codeowners/12095/10) 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/87184ff9cebd3cf0fdbb5226f3bc6587cd466877ffd18d7fdd6bc0a7ca477ffd).
[Apache TVM Discuss] [Development/pre-RFC] [RFC] Remove CODEOWNERS
I see. All good then :D --- [Visit Topic](https://discuss.tvm.apache.org/t/rfc-remove-codeowners/12095/11) 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/e723fbd60a60591e91fae3ac1ea10e906730f85b135a4c96248b3e84f763615e).
[Apache TVM Discuss] [Development/pre-RFC] [RFC] Remove CODEOWNERS
Thanks for @driazati @areusch to bring this for discussion, I think it make sense to reduce the notification spam by rename the codeowner file, and definitely that can help contributor to focus on more related message from community. I agree with @comaniac @manupa-arm about helping the new authors to find people to tag for reviewer, and we may need some following up PR to address such concern. --- [Visit Topic](https://discuss.tvm.apache.org/t/rfc-remove-codeowners/12095/12) 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/403f61e66c73e01a0208183a1488845f1fcff92fe101317ebb4d97a0e7067ed1).
Re: [apache/tvm-rfcs] [RFC][BYOC] Marvell ML/AI Accelerator Integration (PR #48)
@areusch: Yes, using one or two zoom sessions to go over some questions of yours and some questions of ours will definitely be very, very helpful. This way we can sync up quicker. I am open tomorrow (2/25) as well as Monday (2/28) in the afternoons from 1:30 pm to 6 pm Pacific time zone. Will you be available? My company email address is: cch...@marvell.com. Please feel free to schedule a zoom meeting using my email. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/48#issuecomment-1050373729 You are receiving this because you are subscribed to this thread. Message ID:
[Apache TVM Discuss] [Development] Problem with FuseOps (and embedded constants in TIR)
Long story short, after https://github.com/apache/tvm/pull/8509 we see a lot of floating point models crash during compilation for Hexagon. On Hexagon (downstream) we use the mixed-precision pass to convert float32 data to float16. Float16 constants are not supported by constants in TIR and compilation aborts. Longer story... The relay pass `FuseOps` is the one that can extract constants out of expressions, and replace them with parameters. Constants that are not parameters cannot have type float16, because that type is not supported by current TIR code (for embedded constants). If this extraction doesn't happen, compilation will abort if a float16 constant is found in TIR. After commit b5f1dabce4 (PR8509), `FuseOps` will no longer extract constants if the build target has `link_params` set to true. This can be, at least in theory, overridden by pass context flag `relay.FuseOps.link_params`, but there is an issue. The problem is as follows: * The `FoldConstant` pass runs, and it creates a fresh `PassContext`, without any config flags in it. It also uses the "cpu" target instead of the actual one for `CompilationConfig`. * During execution, `FoldConstant` will invoke relay interpreter's function `Eval`, which initiates a series of relay passes, including `FuseOps`. * `FuseOps` gets `link_params` value from `IRModule`'s attribute `Executor`, which is still consistent with the actual target. If the original target has `link_params = 1`, it will take effect regardless of any flags added to PassContext at the `relay.Build` time. It seems like `FuseOps` should be getting settings consistent with the CPU target that `FoldConstants` created, instead of using `Executor` from `IRModule`. This difference may have further consequences if passes executed during `FoldConstants` consult the executor for more information. Any thoughts? --- [Visit Topic](https://discuss.tvm.apache.org/t/problem-with-fuseops-and-embedded-constants-in-tir/12165/1) 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/0b6ce7e6937a48ba45f2697ea4cb66f7a2310582dd0902276e7f45fc523f64be).
[Apache TVM Discuss] [Development] Problem with FuseOps (and embedded constants in TIR)
Agree with your last sentence -- FoldConstants should be CPU only and not carry forward any target-specific flags. (Ideally do all that more directly instead of piggy-backing on the interpreter, but that's a bigger issue.) --- [Visit Topic](https://discuss.tvm.apache.org/t/problem-with-fuseops-and-embedded-constants-in-tir/12165/2) 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/c9e0c7fa4a03237cfa320f41da3a598dc290705394bbdbe8b52ad253308b3298).
[Apache TVM Discuss] [Development] Problem with FuseOps (and embedded constants in TIR)
I wonder why TIR constants doesn't support fp16? Because of the need for c-codegen? @manupa-arm --- [Visit Topic](https://discuss.tvm.apache.org/t/problem-with-fuseops-and-embedded-constants-in-tir/12165/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/d68e59e59a3d2082a6277534f5c3a03950c7ae78e5609e179624f69d08dbfbc4).
[Apache TVM Discuss] [Development] Problem with FuseOps (and embedded constants in TIR)
I'm not sure. But I guess it is because C++ doesn't have a native fp16 type support? --- [Visit Topic](https://discuss.tvm.apache.org/t/problem-with-fuseops-and-embedded-constants-in-tir/12165/4) 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/3da513b72c48b74604e983a355e6ca1520e54f0596eed145aac7ca6b9f2e136d).
