Re: [dmlc/tvm] [Community] @antinucleon -> Reviewer (#3214)
Merged #3214 into master. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/dmlc/tvm/pull/3214#event-2355284663
[TVM Discuss] [Development] OpenCL AutoTVM questions
I'm trying to enable AutoTVM for OpenCL (`intel_graphics` target). So far I managed to have some success in that area, but values are multiple times worst than for generic scheduler. To begin with I am focusing only on conv2d operation (since this is also only one currently present in `intel_graphics` TOPI). I've used `conv2d_direct.py` file from CUDA to use it as a dummy test file (this scheduler seemed to be the easiest) and get some idea what is required to write my own one. There are few things I don't understand and I'd appreciate guidance on how such scheduler should be written/what values should I provide. Two most pressing questions for now are: 1. From where you have all of the splitting and other numerical values in `schedule_direct_cuda`? 1. How you decided about `tvm.thread_axis` threads? --- [Visit Topic](https://discuss.tvm.ai/t/opencl-autotvm-questions/2665/1) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.ai/email/unsubscribe/b527b1296934833ce41beda0c13583fae846f8fa9bbf7a803e07670fa3433d6b). Tianqi Chen, UW, Seattle, WA, 98105, United States http://tracking.discuss.tvm.ai/tracking/unsubscribe?msgid=FN0H3-unCsVvE4avJnv8jg2
[dmlc/tvm] [Community] Eddie -> PMC (#3220)
We are glad to welcome @eqy as a new PMC member of TVM. As a committer, Eddie has contributed heavily to Relay, AutoTVM, Quantization, TOPI, etc. Eddie is also very active in reviewing as well as answering questions on the discuss. Keeping the community active is the key to the project success. I believe bringing Eddie into PMC would help us drive the project even better. You can view, comment on, or merge this pull request online at: https://github.com/dmlc/tvm/pull/3220 -- Commit Summary -- * [Team] Eddie -> PMC -- File Changes -- M CONTRIBUTORS.md (2) -- Patch Links -- https://github.com/dmlc/tvm/pull/3220.patch https://github.com/dmlc/tvm/pull/3220.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/dmlc/tvm/pull/3220
[dmlc/tvm] [Relay][RFC] Implement type checking for Any (#3221)
Currently a draft PR, see related RFC #3042. This PR will only contain the type checking changes to Relay to support Any. @icemelon9 and I will follow up with the related code generation PRs. You can view, comment on, or merge this pull request online at: https://github.com/dmlc/tvm/pull/3221 -- Commit Summary -- * Implement type checking for Any -- File Changes -- M include/tvm/relay/attrs/transform.h (12) M include/tvm/relay/base.h (18) M include/tvm/relay/op_attr_types.h (11) M include/tvm/relay/type.h (5) M include/tvm/runtime/ndarray.h (2) M python/tvm/_ffi/base.py (2) M python/tvm/api.py (3) M python/tvm/relay/__init__.py (1) M python/tvm/relay/op/_transform.py (49) M python/tvm/relay/op/op.py (5) M python/tvm/relay/op/transform.py (6) M python/tvm/relay/ty.py (1) M src/codegen/llvm/codegen_llvm.cc (4) M src/lang/buffer.cc (19) M src/lang/tensor.cc (12) M src/pass/storage_rewrite.cc (1) M src/relay/backend/compile_engine.cc (30) M src/relay/backend/compile_engine.h (32) M src/relay/backend/graph_runtime_codegen.cc (11) M src/relay/backend/interpreter.cc (184) M src/relay/backend/vm/compiler.cc (3) M src/relay/ir/base.cc (6) M src/relay/ir/pretty_printer.cc (4) M src/relay/ir/type.cc (16) M src/relay/op/tensor/transform.cc (154) M src/relay/op/type_relations.cc (10) M src/relay/pass/type_infer.cc (80) M src/relay/pass/type_solver.cc (309) M src/relay/pass/type_solver.h (16) M src/runtime/ndarray.cc (4) A tests/python/relay/test_any.py (91) -- Patch Links -- https://github.com/dmlc/tvm/pull/3221.patch https://github.com/dmlc/tvm/pull/3221.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/dmlc/tvm/pull/3221
Re: [dmlc/tvm] [RFC][Relay] Dynamic Dimensions (#3042)
@ajtulloch @icemelon9 and I have been quietly hacking on a prototype the last
few months but have been busy with other things (such as VM 😄 ). We are going
to start pushing now, I opened a draft PR which will contain type checking
changes, and we will follow-up with code generation next.
One thing would to help validate, criticize the design from the standpoint of a
user who is deploying models day to day, and comment on the code generation
strategies.
One change that we have decided on is adding the ability to type hint when
generating IR.
When generating IR from frameworks we don't necessarily have all type
information up front.
That is you may know a static shape for a value, but the shape is not
necessarily a stable static property.
For example imagine a loop variable which starts as a (1, 1) matrix, but will
grow by one in the first dimension on every loop. Eventually the matrix will
have the shape (n, 1) where `n` is the number of loop iterations but we can't
know that statically.
Our current solution is to generate IR with unknown types, plus a type hint,
allowing inference to eventually solve the most general type.
For example if we were to generate IR for a loop we can do:
```
def my_loop(%x: ?T, %y: ?U) {
...
can_unify(%x, shape=(1, 1))
my_loop(concat([%x, %x], axis=0))
...
}
```
These could later be used to inform code generation, but ensure that we get the
correct typing.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/dmlc/tvm/issues/3042#issuecomment-494547366
[dmlc/tvm] [RFC] Node Construction Style: Use Constructor When Possible (#3223)
Node system lays the foundation to build TVM's AST structures. Each AST object
corresponds to a subclass of Node. Besides the Node itself, we also usually
defines a reference type which can be used to store a strong reference to the
node. The following code example shows how to define Node ```XYZNode``` and
reference type ```XYZ```.
```c++
class XYZ;
class XYZNode : public Node {
public:
static XYZ make(args);
};
class XYZ : public NodeRef {
public:
...
};
void MyFunction() {
XYZ ref = XYZNode::make(args);
}
```
Historically, we introduced a static factory function ```make``` to each Node
type which creates a new reference to the Node(as shown in the above code).
This is less natural compared to direct usage of a constructor or moves the
static factory function into the reference class. As shown in below.
```c++
class XYZNode : public Node {
public:
};
class XYZ : public NodeRef {
public:
XYZ(args);
...
};
void MyFunction() {
// use constructor.
XYZ ref = XYZ(args);
}
```
At the moment, not all the Node have a specific reference type -- this is also
the reason why we adopt make in the Node historically. However, we start to see
a trend of giving a specific reference type to each of the new Node
introduced(e.g. in relay). I would also like to mention that we have already
transitioned the python API to directly use the constructor-style code. Favor
constructors in c++ will make both sides of the code to be more consistent.
This RFC tries to see if we want to migrate to the new style, specifically:
- For Nodes that do not have a corresponding reference type, keep the make
function on Node.
- For Nodes that have a reference type
- Favor constructor over XYZNode::make
- Favor static factory functions in the reference type.
Most of the changes will be quite mechanical and we can do it incrementally.
Please share your thoughts.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/dmlc/tvm/issues/3223
Re: [dmlc/tvm] [RFC] Node Construction Style: Use Constructor When Possible (#3223)
I also created https://github.com/dmlc/tvm/pull/3224 as an example of changes to be made to fit the new style. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/dmlc/tvm/issues/3223#issuecomment-494573241
Re: [dmlc/tvm] [RFC] Node Construction Style: Use Constructor When Possible (#3223)
I was wondering what are the cons to have a static factory function -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/dmlc/tvm/issues/3223#issuecomment-494601614
Re: [dmlc/tvm] [Community] Eddie -> PMC (#3220)
Merged #3220 into master. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/dmlc/tvm/pull/3220#event-2358131918
