Commit cedbdfb5 by Marcus Shawcroft Committed by Jared Roesch

[DOC] minor grammatical improvements (#3341)

parent da1ea262
...@@ -33,9 +33,9 @@ At the root of the TVM repository, we have following subdirectories that togethe ...@@ -33,9 +33,9 @@ At the root of the TVM repository, we have following subdirectories that togethe
- ``topi`` - Compute definitions and backend schedules for standard neural network operators. - ``topi`` - Compute definitions and backend schedules for standard neural network operators.
- ``nnvm`` - C++ code and Python frontend for graph optimization and compilation. After the introduction of Relay, it remains in the codebase for backward compatibility. - ``nnvm`` - C++ code and Python frontend for graph optimization and compilation. After the introduction of Relay, it remains in the codebase for backward compatibility.
Using standard Deep Learning terminologies, ``src/relay`` is the component that manages a computational graph, and nodes in a graph are compiled and executed using infrastructures implemented in the rest of ``src``. ``python`` provides python bindings for the C++ API and driver code that users can use to execute compilation. Operators corresponding to each node are registered in ``src/relay/op``. Implementations for operators are in ``topi``, and they are coded in either C++ or Python. Using standard Deep Learning terminology, ``src/relay`` is the component that manages a computational graph, and nodes in a graph are compiled and executed using infrastructure implemented in the rest of ``src``. ``python`` provides python bindings for the C++ API and driver code that users can use to execute compilation. Operators corresponding to each node are registered in ``src/relay/op``. Implementations of operators are in ``topi``, and they are coded in either C++ or Python.
Relay is the new IR for deep networks that is intended to replace NNVM. If you have used NNVM, Relay provides equivalent or better functionalities. In fact, Relay goes beyond a traditional way of thinking deep networks in terms of computational graphs. But for the purpose of this document, we can think of Relay as a traditional computational graph framework. You can read more about Relay `here <https://docs.tvm.ai/dev/relay_intro.html>`_. Relay is the new IR for deep networks that is intended to replace NNVM. If you have used NNVM, Relay provides equivalent or better functionality. In fact, Relay goes beyond a traditional way of thinking deep networks in terms of computational graphs. But for the purpose of this document, we can think of Relay as a traditional computational graph framework. You can read more about Relay `here <https://docs.tvm.ai/dev/relay_intro.html>`_.
When a user invokes graph compilation by ``relay.build(...)`` (or ``nnvm.compiler.build(...)`` for the older API), the following sequence of actions happens for each node in the graph: When a user invokes graph compilation by ``relay.build(...)`` (or ``nnvm.compiler.build(...)`` for the older API), the following sequence of actions happens for each node in the graph:
...@@ -43,7 +43,7 @@ When a user invokes graph compilation by ``relay.build(...)`` (or ``nnvm.compile ...@@ -43,7 +43,7 @@ When a user invokes graph compilation by ``relay.build(...)`` (or ``nnvm.compile
- Generate a compute expression and a schedule for the operator - Generate a compute expression and a schedule for the operator
- Compile the operator into object code - Compile the operator into object code
One of the interesting aspects of TVM codebase is that interoperability between C++ and Python is not unidirectional. Typically, all code that does heavy lifting is implemented in C++, and Python bindings are provided for the user interface. This is also true in TVM, but in TVM codebase, C++ code can also call into functions defined in a Python module. For example, the convolution operator is implemented in Python, and its implementation is invoked from C++ code in Relay. One of the interesting aspects of the TVM codebase is that interoperability between C++ and Python is not unidirectional. Typically, all code that performs heavy lifting is implemented in C++, and Python bindings are provided for the user interface. This is also true in TVM, but in the TVM codebase, C++ code can also call into functions defined in a Python module. For example, the convolution operator is implemented in Python, and its implementation is invoked from C++ code in Relay.
******************************************* *******************************************
Vector Add Example Vector Add Example
......
...@@ -147,7 +147,7 @@ class Operation(NodeBase): ...@@ -147,7 +147,7 @@ class Operation(NodeBase):
@property @property
def num_outputs(self): def num_outputs(self):
"""Number of outputs of this op.""" """Number of outputs from this op."""
return _api_internal._OpNumOutputs(self) return _api_internal._OpNumOutputs(self)
@property @property
...@@ -166,7 +166,7 @@ class BaseComputeOp(Operation): ...@@ -166,7 +166,7 @@ class BaseComputeOp(Operation):
"""Compute operation.""" """Compute operation."""
@property @property
def axis(self): def axis(self):
"""Represent axis of IterVar, defined when it is a ComputeOp""" """Represent the IterVar axis, defined when it is a ComputeOp"""
return self.__getattr__("axis") return self.__getattr__("axis")
@property @property
...@@ -191,7 +191,7 @@ class ScanOp(Operation): ...@@ -191,7 +191,7 @@ class ScanOp(Operation):
"""Scan operation.""" """Scan operation."""
@property @property
def scan_axis(self): def scan_axis(self):
"""Represent axis of scan, only defined when it is a ScanOp""" """Represent the scan axis, only defined when it is a ScanOp"""
return self.__getattr__("scan_axis") return self.__getattr__("scan_axis")
...@@ -205,7 +205,7 @@ class HybridOp(Operation): ...@@ -205,7 +205,7 @@ class HybridOp(Operation):
"""Hybrid operation.""" """Hybrid operation."""
@property @property
def axis(self): def axis(self):
"""Represent axis of IterVar, also defined when it is a HybridOp""" """Represent the IterVar axis, also defined when it is a HybridOp"""
return self.__getattr__("axis") return self.__getattr__("axis")
......
...@@ -133,7 +133,7 @@ def matmul_v1(N, L, M, dtype): ...@@ -133,7 +133,7 @@ def matmul_v1(N, L, M, dtype):
# Here we make four modifications to the previous schedule code and get # Here we make four modifications to the previous schedule code and get
# a tunable "template". We can explain the modifications one by one. # a tunable "template". We can explain the modifications one by one.
# #
# 1. Use a decorator to mark this function as a simple template # 1. Use a decorator to mark this function as a simple template.
# 2. Get a config object: # 2. Get a config object:
# You can regard this :code:`cfg` as an argument of this function but # You can regard this :code:`cfg` as an argument of this function but
# we obtain it in a different way. With this argument, this function is no longer # we obtain it in a different way. With this argument, this function is no longer
......
...@@ -24,11 +24,11 @@ Cross Compilation and RPC ...@@ -24,11 +24,11 @@ Cross Compilation and RPC
This tutorial introduces cross compilation and remote device This tutorial introduces cross compilation and remote device
execution with RPC in TVM. execution with RPC in TVM.
With cross compilation and RPC, you can **compile program on your With cross compilation and RPC, you can **compile a program on your
local machine then run it on the remote device**. It is useful when local machine then run it on the remote device**. It is useful when
the resource of remote devices is limited, like Raspberry Pi and mobile the remote device resource are limited, like Raspberry Pi and mobile
platforms. In this tutorial, we will take Raspberry Pi for CPU example platforms. In this tutorial, we will use the Raspberry Pi for a CPU example
and Firefly-RK3399 for opencl example. and the Firefly-RK3399 for an OpenCL example.
""" """
###################################################################### ######################################################################
...@@ -39,9 +39,9 @@ and Firefly-RK3399 for opencl example. ...@@ -39,9 +39,9 @@ and Firefly-RK3399 for opencl example.
# #
# .. note:: # .. note::
# #
# All instructions in both this section and next section should be # All instructions in both this section and the next section should be
# executed on the target device, e.g. Raspberry Pi. And we assume it # executed on the target device, e.g. Raspberry Pi. We assume the target
# has Linux running. # is running Linux.
# #
# Since we do compilation on the local machine, the remote device is only used # Since we do compilation on the local machine, the remote device is only used
# for running the generated code. We only need to build the TVM runtime on # for running the generated code. We only need to build the TVM runtime on
...@@ -53,7 +53,7 @@ and Firefly-RK3399 for opencl example. ...@@ -53,7 +53,7 @@ and Firefly-RK3399 for opencl example.
# cd tvm # cd tvm
# make runtime -j2 # make runtime -j2
# #
# After building runtime successfully, we need to set environment variables # After building the runtime successfully, we need to set environment variables
# in :code:`~/.bashrc` file. We can edit :code:`~/.bashrc` # in :code:`~/.bashrc` file. We can edit :code:`~/.bashrc`
# using :code:`vi ~/.bashrc` and add the line below (Assuming your TVM # using :code:`vi ~/.bashrc` and add the line below (Assuming your TVM
# directory is in :code:`~/tvm`): # directory is in :code:`~/tvm`):
...@@ -88,7 +88,7 @@ and Firefly-RK3399 for opencl example. ...@@ -88,7 +88,7 @@ and Firefly-RK3399 for opencl example.
# #
# .. note:: # .. note::
# #
# Now we back to the local machine, which has a full TVM installed # Now we go back to the local machine, which has a full TVM installed
# (with LLVM). # (with LLVM).
# #
# Here we will declare a simple kernel on the local machine: # Here we will declare a simple kernel on the local machine:
...@@ -127,15 +127,15 @@ func.export_library(path) ...@@ -127,15 +127,15 @@ func.export_library(path)
# .. note:: # .. note::
# #
# To run this tutorial with a real remote device, change :code:`local_demo` # To run this tutorial with a real remote device, change :code:`local_demo`
# to False and replace :code:`target` in :code:`build` with the true # to False and replace :code:`target` in :code:`build` with the appropriate
# target triple of your device. The target triple which might be # target triple for your device. The target triple which might be
# different for different devices. For example, it is # different for different devices. For example, it is
# :code:`'llvm -target=armv7l-linux-gnueabihf'` for Raspberry Pi 3B and # :code:`'llvm -target=armv7l-linux-gnueabihf'` for Raspberry Pi 3B and
# :code:`'llvm -target=aarch64-linux-gnu'` for RK3399. # :code:`'llvm -target=aarch64-linux-gnu'` for RK3399.
# #
# Usually, you can query the target by execute :code:`gcc -v` on your # Usually, you can query the target by running :code:`gcc -v` on your
# device, and look for the line starting with :code:`Target:` # device, and looking for the line starting with :code:`Target:`
# (Though it may be still a loose configuration.) # (Though it may still be a loose configuration.)
# #
# Besides :code:`-target`, you can also set other compilation options # Besides :code:`-target`, you can also set other compilation options
# like: # like:
...@@ -160,7 +160,7 @@ func.export_library(path) ...@@ -160,7 +160,7 @@ func.export_library(path)
###################################################################### ######################################################################
# Run CPU Kernel Remotely by RPC # Run CPU Kernel Remotely by RPC
# ------------------------------ # ------------------------------
# We show how to run the generated cpu kernel on the remote device. # We show how to run the generated CPU kernel on the remote device.
# First we obtain an RPC session from remote device. # First we obtain an RPC session from remote device.
if local_demo: if local_demo:
...@@ -200,8 +200,8 @@ print('%g secs/op' % cost) ...@@ -200,8 +200,8 @@ print('%g secs/op' % cost)
######################################################################### #########################################################################
# Run OpenCL Kernel Remotely by RPC # Run OpenCL Kernel Remotely by RPC
# --------------------------------- # ---------------------------------
# As for remote OpenCL devices, the workflow is almost the same as above. # For remote OpenCL devices, the workflow is almost the same as above.
# You can define the kernel, upload files, and run by RPC. # You can define the kernel, upload files, and run via RPC.
# #
# .. note:: # .. note::
# #
...@@ -209,7 +209,7 @@ print('%g secs/op' % cost) ...@@ -209,7 +209,7 @@ print('%g secs/op' % cost)
# Firefly-RK3399. You may follow this `tutorial <https://gist.github.com/mli/585aed2cec0b5178b1a510f9f236afa2>`_ # Firefly-RK3399. You may follow this `tutorial <https://gist.github.com/mli/585aed2cec0b5178b1a510f9f236afa2>`_
# to setup the OS and OpenCL driver for RK3399. # to setup the OS and OpenCL driver for RK3399.
# #
# Also we need to build the runtime with OpenCL enabled on rk3399 board. In the tvm # Also we need to build the runtime with OpenCL enabled on rk3399 board. In the TVM
# root directory, execute # root directory, execute
# #
# .. code-block:: bash # .. code-block:: bash
...@@ -218,7 +218,7 @@ print('%g secs/op' % cost) ...@@ -218,7 +218,7 @@ print('%g secs/op' % cost)
# sed -i "s/USE_OPENCL OFF/USE_OPENCL ON/" config.cmake # sed -i "s/USE_OPENCL OFF/USE_OPENCL ON/" config.cmake
# make runtime -j4 # make runtime -j4
# #
# The following function shows how we run OpenCL kernel remotely # The following function shows how we run an OpenCL kernel remotely
def run_opencl(): def run_opencl():
# NOTE: This is the setting for my rk3399 board. You need to modify # NOTE: This is the setting for my rk3399 board. You need to modify
...@@ -256,7 +256,7 @@ def run_opencl(): ...@@ -256,7 +256,7 @@ def run_opencl():
# This tutorial provides a walk through of cross compilation and RPC # This tutorial provides a walk through of cross compilation and RPC
# features in TVM. # features in TVM.
# #
# - Set up RPC server on the remote device. # - Set up an RPC server on the remote device.
# - Set up target device configuration to cross compile kernel on the # - Set up the target device configuration to cross compile the kernels on the
# local machine. # local machine.
# - Upload and run the kernel remotely by RPC API. # - Upload and run the kernels remotely via the RPC API.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment