tvm-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <...@apache.org>
Subject [GitHub] [incubator-tvm] comaniac commented on a change in pull request #5078: [DOC] Add doc for Relay op strategy
Date Tue, 17 Mar 2020 17:33:40 GMT
comaniac commented on a change in pull request #5078: [DOC] Add doc for Relay op strategy
URL: https://github.com/apache/incubator-tvm/pull/5078#discussion_r393848565
 
 

 ##########
 File path: docs/dev/relay_op_strategy.rst
 ##########
 @@ -0,0 +1,270 @@
+..  Licensed to the Apache Software Foundation (ASF) under one
+    or more contributor license agreements.  See the NOTICE file
+    distributed with this work for additional information
+    regarding copyright ownership.  The ASF licenses this file
+    to you under the Apache License, Version 2.0 (the
+    "License"); you may not use this file except in compliance
+    with the License.  You may obtain a copy of the License at
+
+..    http://www.apache.org/licenses/LICENSE-2.0
+
+..  Unless required by applicable law or agreed to in writing,
+    software distributed under the License is distributed on an
+    "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+    KIND, either express or implied.  See the License for the
+    specific language governing permissions and limitations
+    under the License.
+
+.. _relay-op-strategy:
+
+Relay Operator Strategy
+=======================
+
+In order to lower Relay operators to the implementations defined in TOPI
+library, a compute and schedule function need to be registered to each Relay
+operator.  However, compute and schedule functions are usually specialized for
+each target, and further, even for the same target, we may have multiple
+algorithms and implementations available. To deal with the complexity, we
+introduce operator strategy to allow developers to define a flexible lowering
+strategy for each operator and target.
+
+
+Operator Strategy Design
+------------------------
+
+The basic element in operator strategy is an ``OpImplementation``. It includes
+the a pair of compute and schedule function, the name of the implementation,
+and a priority level (the use of priority level is explained in
+`Select Implementation from Op Strategy`_).
+
+The ``OpStrategy`` includes a list of ``OpSpecialization``. Each ``OpSpecialization``
+contains a list of ``OpImplementation`` associated with a ``SpecializedCondition``
+(see definition in ``include/tvm/te/schedule.h``).  The ``SpecializedCondition``
+can be null, indicating the implementations are generally applicable;
+otherwise, the implementations are only considered when the specialized
+condition is satisfied. ``SpecializedCondition`` consists of a list
+of clauses defined in Tensor Expression in conjunctive normal form (CNF) and
+only supports conditions on tensor shapes.
+
+Last, a ``FTVMStrategy`` function is registered to each Relay operator.
+``FTVMStrategy`` is a generic function (see ``include/tvm/target/generic_func.h``),
+that can be overwritten for each target. The function signature is
+
+.. code:: c
+
+    OpStrategy(const Attrs& attrs, const Array<Tensor>& inputs, const Type&
out_type, const Target& target)
+
+that the function returns an ``OpStrategy`` given the op attributes, input
+tensors, output types, and target to compile to.
+
+
+
+Register Strategy for An Operator
+---------------------------------
+
+There are three methods to register a strategy function for an operator,
 
 Review comment:
   Some thoughts to this section:
   - It's better to define "strategy function" first. Something like "a strategy function
is used to determine which pair of compute and schedule function should be used by given a
workload".
   
   - The third method described at the end of this section (`add_implement`) is not a method
of registering a strategy function to me. Instead, it is more like how to implement a strategy
function. It might be better to have a separate section called "Implement a Strategy for An
Operator", or just change this section title to "Implement and Register a Strategy for An
Operator".
   
   - My understanding is that the first approach is a simple one because we can reuse the
compute function for those patterns. In this case, it might be better to switch the order
of first and second methods. That is, we first introduce a method of implementing and registering
a strategy function for dense. After that, we mention if your operator fits certain patterns
you can simply your work.
   
   - In the description of strategy function implementation, I think it might be better to
mention `topk` only. As a result, in the beginning of the next section "Advanced Strategy
Function", you can say some operators like dense require a more complicate strategy so it
cannot be implemented like `topk`.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

Mime
View raw message