hey guys, thanks for the RFC! would you guys be up for doing a short
walkthrough of it at a Community Meeting?
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/72#issuecomment-1129417079
You are receiving this because you are subscribed to this threa
RFC for OneDNN Integration via BYOC.
You can view, comment on, or merge this pull request online at:
https://github.com/apache/tvm-rfcs/pull/73
-- Commit Summary --
* RFC-BYOC-DNNL-Integration
-- File Changes --
A rfcs/0069-byoc-onednn-integration.md (115)
A rfcs/assets/latest/late
> So a user would only write tvm.target.Target("ultra_trail -uma_attrs= custom attr string>") and in code you would access the target via
> target.attrs["uma_attrs"]["attr1"], target.attrs["uma_attrs"]["attr2"], ect.?
More or less yes -- maybe we could (re) use "mattr" instead of "uma_attrs"
loo
> This aligns with A2.2 -- directly registering each attribute.
@manupa-arm Then just for clarification a few questions because I might have
misunderstood your initial idea. For A2.1 you were thinking about registering
an attribute preprocessor to the target
`Target().add_attrs_preprocessor(Pre
```
They can be used during target creation similar to other sub_target strings
ut_target = tvm.target.Target("ultra_trail -ultra_trail_attr_1=attr1
-ultra_trail_attr_2=attr2")
```
```
This could probably be solved by adding type and/or default arguments to the
argument parser, e.g.:
self._re
Thanks @cgerum and @PaulPalomeroBernardo . I agree, this totally makes sense
like this.
@manupa-arm @areusch is this sufficiently detailed for you? I propose to
discuss outstanding topics in meeting to settle for UMA-v1. We could use the
Community Meeting on May 25th. Or if these discussions ar
