Adding overview and glossary doc for OpenExec

(Internal change: 2374505)

Author: pixar-oss

docs/glossary.rst

@@ -702,6 +702,59 @@ list: :usda:`[ @file1.usd@, @file3.usd@ ]`
    {
    }
 
+.. _usdglossary-inputparameters:
+
+Computation Input Parameters
+****************************
+
+An :ref:`OpenExec <usdglossary-openexec>` *computation input parameter* is a 
+specification of an input data source for a 
+:ref:`computation <usdglossary-computation>`. Input parameters are 
+used by computations to ingest source data from resolved attribute values or 
+output values from other computations. 
+
+Input parameters can source values from the outputs of other computations, and 
+sourced computations need not be published on the same scene object as the 
+consuming computation. OpenExec may need to, for example, traverse a 
+relationship, or look up or down the namespace hierarchy, to properly resolve 
+the source for the input parameter. Input parameters encode information used to 
+resolve input sources, such as a computation name, the scene object used to look 
+up the computation by name, and the input value data type, which must match the 
+data type of the output value returned from the source computation or resolved 
+attribute value.
+
+Every input parameter provides zero or more input values to the computation 
+callback. A relationship-targeted input may not resolve to any source 
+computations if the specified relationship does not have authored targets, or if 
+the targeted objects do not publish a computation with the specified name or 
+result type. Conversely, the input parameter can resolve to more than one source 
+computation if there are multiple authored targets.
+
+See :ref:`openexec_computation_input_parameters` for more information on 
+computation input parameters.
+
+.. _usdglossary-computation:
+
+Computation
+***********
+
+An :ref:`OpenExec <usdglossary-openexec>` *computation* is a function, 
+provided by a scene object, that computes one or more output values from a set 
+of input values.
+
+A computation will take zero or more 
+:ref:`input parameters <usdglossary-inputparameters>` (typically 
+at least one), and a C++ computation callback responsible for reading input 
+values, performing the computational work, and outputting the result values 
+(typically one). A computation instance is also associated with a computation 
+provider, a scene object used as an anchor for sourcing input values. 
+
+Computations can be **Built-in computations** (provided by USD schemas) or 
+**Plugin computations** (custom computations registered as part of the schema
+registration process)
+
+See :ref:`openexec_computations` for more information on computations.
+
 .. _usdglossary-connection:
 
 Connection
@@ -1957,6 +2010,27 @@ namespace of prims, each Stage possesses a `PseudoRoot
 <#usdglossary-pseudoroot>`_ prim that is the parent of all authored root prims,
 represented by the path :sdfpath:`/`.
 
+.. _usdglossary-openexec:
+
+OpenExec
+********
+
+*OpenExec* is a general-purpose framework for expressing and evaluating 
+computational behaviors in a USD scene. This framework is built on top of USD 
+and includes a fast, multi-threaded evaluation engine, and data management 
+features for automatically caching and invalidating computed values. 
+
+OpenExec introduces new features, such as
+:ref:`named computations <usdglossary-computation>` and
+:ref:`input parameters <usdglossary-inputparameters>`, that can be associated 
+with USD scene objects.
+
+Behind the scenes, OpenExec builds and maintains a dataflow network with 
+computational tasks encoded as nodes within this network, and data traveling 
+between computations encoded as edges. 
+
+See :ref:`intro_to_openexec` for more details.
+
 .. _usdglossary-opinions:
 
 Opinions

docs/intro.rst

@@ -324,7 +324,10 @@ following plugin-points:
       your pipeline or package, with which you will be able to interact in your
       application-level plugins just as if they were native USD schemas. For
       typed schemas that are conceptually imageable, you can also teach Hydra
-      how to image them.
+      how to image them. You can additionally use 
+      :ref:`OpenExec <intro_to_openexec>` to register computations for schemas 
+      for better performance characteristics in addition to data invalidation 
+      and caching management.
 
 What can't USD do?
 ==================
@@ -347,16 +350,19 @@ operations run over a collection of assets is worth paying for the ease of asset
 construction and aggregation, and readable text asset representations that we
 get from namespace-paths as identifiers.
 
-Not an execution or rigging system
-**********************************
+Not a rigging system
+********************
 
 USD provides a lightweight, optimized scenegraph to facilitate authoring and
-efficient extraction of composed scene description. However, it provides no
-other behaviors than composition of a namespace hierarchy and property
-:ref:`glossary:Value Resolution`, and in the tradeoff space between "low-memory
-footprint, higher-latency data access" and "high-memory footprint, low-latency
-access to data", USD's scenegraph leans more towards the former, whereas a
-high-performance execution engine requires the latter.
+efficient extraction of composed scene description. However, USD's scenegraph
+leans towards a "low-memory footprint, higher-latency data access" tradeoff, 
+whereas a high-performance rigging system requires more of a "high-memory
+footprint, low-latency access to data" tradeoff.
+
+The :ref:`OpenExec <intro_to_openexec>` computation engine does provide a 
+general purpose computation framework that could be used to develop a rigging
+system, but OpenExec by itself is not a rigging system. See
+:ref:`openexec_is_not` for more details.
 
 Further, the more rigging behaviors and execution semantics we would add to USD,
 the more difficult it would become to interchange the data successfully between