Application programming interface to add graph node dependencies

[0001] At least one embodiment pertains to techniques for parallel computing. For example, at least one embodiment pertains to processors or computing systems used to perform an application programming interface (API) to indicate one or more graph node functions of one or more graph nodes to be added to a software graph based, at least in part, on a dependency type indicated by the API.

[0002] Parallel computing programs, when scheduling tasks, may cause one or more tasks of a software graph to depend from one or more other tasks. Tasks are performed according to a category of dependency between tasks.

[0067] In the following description, numerous specific details are set forth to provide a more thorough understanding of at least one embodiment. However, it will be apparent to one skilled in the art that the inventive concepts may be practiced without one or more of these specific details.

[0068] FIG. 1 illustrates graph creation and execution, in accordance with at least one embodiment. In at least one embodiment, a processor comprises circuitry to set a dependency between two or more nodes of a graph. In at least one embodiment, a dependency in a graph is obtained via an application programming interface (“API”) that is used to either explicitly define, or to capture information that defines, this graph. In at least one embodiment, an API is to indicate one or more node dependencies of a graph.

[0069] In at least one embodiment, an example process 100 for creating and using graphs comprises graph create 120 and graph execution 122, where said process 100 comprises generating and executing graph 102. In at least one embodiment, a graph represents operations to be performed by one or more graphics processing units (“GPUs”), or other parallel processing units (“PPUs”). In at least one embodiment, a graph represent one or more operations to be performed that include one or more of a kernel operation, a CPU function call, a memory copy operation, a memory set operation, an event operation, a semaphore operation, and/or an embedded child graph operation. In at least one embodiment, a graph comprises nodes that represent operations to be performed by one or more GPUs, and edges that represent dependencies between these operations. In at least one embodiment, a graph comprises nodes that represent instructions to be performed by one or more GPUs, and edges that represent dependencies between these instructions. In at least one embodiment, a graph comprises nodes that represent one or more of primitives, functions, user instructions, micro-operations, kernels, graph code, and/or any suitable actions. In at least one embodiment, these dependencies correspond to data flow between operations, such as output from one operation that is provided to another operation. In at least one embodiment, dependencies between nodes of a graph represent a manner in which operations corresponding to these nodes are to be performed. In at least one embodiment, a graph is stored in a computer memory as a data structure that comprises representations of its nodes and edges.

[0070] In at least one embodiment, creating a graph is created by at least one of explicit definition or stream capture. In at least one embodiment, explicit definition of a graph comprises use of one or more application programming interfaces (“APIs”) (e.g., as described below in relation to FIGS. 6-26) that defines said graph's nodes and edges, where said nodes represent operations to be performed by one or more GPUs or PPUs and said edges represent data flow and/or performance ordering between nodes. In at least one embodiment, stream capture comprises intercepting and recording operations directed to a GPU or PPU. For example, in at least one embodiment, a graph is constructed from stream capture by identifying kernel operations streamed to a GPU and constructing a graph that represents these operations and their dependencies. In at least one embodiment, a kernel represents a function, routine, or other unit of code to be performed by one or more GPUs or PPUs.

[0071] In at least one embodiment, nodes are added to a graph using one or more APIs (e.g., as described below in relation to FIGS. 6-26) that defines nodes and/or edges between nodes to be added to a graph. In at least one embodiment, an API is specific to one type of node. In at least one embodiment, for example, an API may be used to add a node to a graph that performs one or more of a kernel operation, a CPU function call, a memory copy operation, a memory set operation, an event operation, a semaphore operation, and/or an embedded child graph operation. In at least one embodiment, an API may generate a node to be added to a graph for any of a plurality of node types. In at least one embodiment, for example, a single API could be used to generate a kernel node, or alternatively generate a memory copy node. In at least one embodiment, an API adds a node to a graph having a particular type based, at least in part, on one or more parameters provided to as input. In at least one embodiment, for example, based on an API receiving parameters corresponding to a kernel node type, a kernel node will be added to a graph. In at least one embodiment, in another example, an API receiving parameters corresponding to an empty node type, an empty node will be added to a graph. In at least one embodiment, parameters provided to an API may be in any number of formats and/or arrangements. In at least one embodiment, an API will receive parameters arranged in one or more data structures. In at least one embodiment, a data structure may comprise a union data structure, such as a tagged union. In at least one embodiment, a data structure may occupy a fixed amount of memory independent of parameters that are to be stored. In at least one embodiment, for example, parameters required to add a kernel node to a graph may occupy more memory than parameters required to add an empty kernel node to a graph, but a data structure is associated with a fixed size allocation of memory. In at least one embodiment, memory allocated to parameters provided to an API comprises one or more memory addresses to be used as padding. In at least one embodiment, memory used as padding is initialized to a default value. In at least one embodiment, a portion of memory used as padding may be used to store additional API parameters, such as parameters added for additional functionality and/or expandability.

[0072] In at least one embodiment, memory allocated to node parameters provided to, and/or generated by, an API, comprises one or more memory addresses to be used as padding. In at least one embodiment, and API is to access a data structure having a variable number of null (or zero set) parameters to be used as padding. In at least one embodiment, for example, any memory addresses of a data structure used to store parameters that are unused are to be null or padding values. In at least one embodiment, memory used as padding is initialized to a default value. In at least one embodiment, a portion of memory used as padding may be used to store additional API node parameters, such as parameters added for additional functionality and/or expandability. In at least one embodiment, a data structure allows new parameters (e.g., data fields) to be added based on a node type. In at least one embodiment, new fields are given a default value such that enable background compatibility with instructions that do not use said new fields. In at least one embodiment, a size of padding used in a data structure is a size of a largest available node-type parameter structure. In at least one embodiment, for example, if a largest parameter in a data structure is 184 bytes, a portion of padding in said data structure is also 184 bytes. In at least one embodiment, a size of padding used in a data structure is larger than a size of a largest available node-type structure. In at least one embodiment, for example, if a largest parameter in a data structure is 184 bytes, a portion of padding in said data structure is greater than 184 bytes.

[0073] In at least one embodiment, a data structure including node parameters includes one or more flags. In at least one embodiment, for example, a data structure includes one or more flags that are specific to a node type. In at least one embodiment, for example, a child graph node is to have a flag facilitating a transfer of ownership, rather than a cloning, of a child graph. In at least one embodiment, an API (such as described below in relation to FIGS. 6-26) is to populate flags of a data structure so that it can be accessed by one or more other processes. In at least one embodiment, for example, an API is to query a node parameters of a child graph and set a flag associated with a transfer operation instead of a cloning operation.

[0074] In at least one embodiment, an example parameter data structure to be access by an API, is as follows:

• • [0075] typedef struct cudaGraphNodeParams_st {
    • [0076] cudaGraphNodeType type;
    • [0077] int32_t reserved0[3];
    • [0078] union {
      • [0079] int64_t; reserved1[30]
      • [0080] cudaKernelNodeParamsV2 kernel;
      • [0081] cudaMemcpyNodeParams memcpy;
      • [0082] cudaMemsetNodeParamsV2 memset;
      • [0083] cudaHostNodeParamsV2 host;
      • [0084] cudaMemAllocNodeParamsV2 alloc;
      • [0085] cudaMemFreeNodeParams free;
      • [0086] cudaChildGraphNodeParams childGraph;
      • [0087] cudaEventRecordNodeParams eventRecord;
      • [0088] cudaEventWaitNodeParams eventWait;
      • [0089] cudaExternalSemaphoreWaitNodeParamsV2 extSemWait;
      • [0090] cudaExternalSemaphoreSignalNodeParamsV2 extSemSignal;
      • [0091] };
  • [0092] }cudaGraphNodeParams;
    Where cudaGraphNodeParams_st is a data structure, cudaGraphNodeType indicates a type of node to add to a graph, and cudaGraphNodeParams is a union of parameters corresponding to kernel nodes, memory copy nodes, memory set nodes, host nodes, memory allocation nodes, memory free nodes, child graph nodes, event record nodes, event wait nodes, external semaphore wait nodes, external semaphore signal nodes, and/or padding. In at least one embodiment, based on a type of node indicated by cudaGraphNodeType, appropriate parameters will be accessed from union cudaGraphNodeParams. In at least one embodiment, for example, if a node type is indicated as a kernel node, kernel node parameters are accessed in a union of a data structure. In at least one embodiment, similarly, if a node type is indicated as a memory allocation node, memory allocation parameters are accessed from a union of a data structure.

[0093] In at least one embodiment, one or more GPUs or PPUs execute operations in a graph. For example, in at least one embodiment, a GPU or PPU executes kernel operations represented by a graph. In at least one embodiment, graph operations are performed using parallelism, where possible. Some nodes of a graph may, in at least one embodiment, be dependent on other operations, and accordingly operations in a graph may be executed in accordance with those dependencies.

[0094] In at least one embodiment, a graph is processed, after its definition, to prepare for execution by one or more GPUs or PPUs. In at least one embodiment, this may include compilation of said graph, applications of various optimizations, or other processing. In at least one embodiment, processing may include communication between a CPU and one or more GPUs or PPUs that are to execute a graph.

[0095] In at least one embodiment, a graph dependency refers to a relationship between nodes of a graph. In at least one embodiment, a graph dependency refers to a relationship in which at least one node relies on completion of at least one other node. In at least one embodiment, a graph dependency refers to a relationship in which at least one node relies on a launching order of at least one other node. In at least one embodiment, a graph dependency refers to a relationship in which at least one other dependency is prevented between a node and at least one other node. In at least one embodiment, a graph dependency causes one node of a graph to wait until at least one other node is launched before being launched. In at least one embodiment, an order of graph dependencies refers to a sequence in which these relationships were defined. In at least one embodiment, this sequence information is obtained from API calls made to define a graph, whether through an explicit API, stream capture, or other mechanism.

[0096] In at least one embodiment, a graph dependency is a full execution dependency. In at least one embodiment, an full execution dependency is a dependency between two nodes in which a first node of these two nodes is blocked by a second node until this second node finished executing (e.g., as described below in relation to full execution dependency 302 of FIG. 3). In at least one embodiment, an full execution dependency prevents a first node from being performed until a second node has completed being performed. In at least one embodiment, one or more nodes associated with a full execution dependency may correspond to a dependency definition and/or edge information indicating a full execution dependency.

[0097] In at least one embodiment, a graph dependency is an anti-deadlock dependency. In at least one embodiment, an anti-deadlock dependency is a dependency between two nodes in which a first node of these two nodes is not caused to be blocked (e.g., throttled) by a second node (e.g., as described below in relation to anti-deadlock dependency 332 of FIG. 3). In at least one embodiment, an anti-deadlock dependency prevents a first node from blocking a second node while permitting said second node to prevent said first node from being performed. In at least one embodiment, one or more nodes associated with an anti-deadlock dependency may correspond to an indication of an anti-deadlock dependency. In at least one embodiment, an API is performed to cause an anti-deadlock attribute to be stored to prevent one or more nodes of a graph from delaying a launch and/or performance of one or more other nodes. In at least one embodiment, an API is performed to cause to prevent one or more dependencies from being added to two or more threads. In at least one embodiment, for example, a first thread associated with a node of a graph is prevented from having another dependency imposed on it by one or more other threads associated with one or more other nodes of a graph. In at least one embodiment, one or more node with an asserted anti-deadlock attribute is to prevent one or more dependencies (e.g., launch order dependency, full execution dependency, etc.) from being generated an association to one or more other nodes. In at least one embodiment, an anti-deadlock attribute associated with a thread is set using a launch attribute. In at least one embodiment, an anti-deadlock attribute is automatically asserted based on detecting a potential deadlock of one or more operations. In at least one embodiment, an anti-deadlock attribute is automatically asserted based on a type of operation associated with a node. In at least one embodiment, for example, nodes associated with a memory operation may have an anti-deadlock attribute automatically asserted as a default value. In at least one embodiment, nodes with an anti-deadlock attribute asserted are not to be blocked by other nodes that also have an anti-deadlock attribute asserted. In at least one embodiment, nodes with anti-deadlock attribute asserted are not to be blocked by upstream tasks which also have an anti-deadlock attribute asserted. In at least one embodiment, for example for Nodes A, B, C, when B has an anti-deadlock dependency from A, and C has an anti-deadlock dependency from B, a dependency from B to A, C to B, and/or C to A are prohibited.

[0098] In at least one embodiment, a graph dependency is a launch order dependency. In at least one embodiment, a launch order dependency is a dependency between two nodes in which a first node of these two nodes is constrained from being launched, or otherwise performed, before a second node of these two nodes is launched (e.g., as described below in relation to launch order dependency 312 of FIG. 3 and in FIG. 4). In at least one embodiment, an API is to control ordering of performance of one or more independent instructions associated with one or more nodes. In at least one embodiment, for example, a node constrained by a second node by a launch order dependency will wait until this second node is launched, but not necessarily having completed execution, before itself is launched. In at least one embodiment, a user specifies an order in which one or more instructions are to be performed. In at least one embodiment, a user specifies an order in which two or more independent instructions are to be performed, where said independent instructions do not have a data dependency with other independent nodes. In at least one embodiment, a node with a launch order dependency has one or more parameters defining one or more events to occur before said node is launched (e.g., rasterized). In at least one embodiment, an instruction is launched when one or more commands and/or instructions cause it to be committed to one or more resources, such as one or more processors. In at least one embodiment, for example, a node waits on an event, a launching of another node, before itself is able to be launched. In at least one embodiment, a node is associated with a waiting identifier that indicates one or more other nodes that must launch, but not necessarily complete execution, before it may be launched. In at least one embodiment, a launch order dependency may be defined in a launch attribute of a node, and used at a time of launch to perform said node. In at least one embodiment, a launch order dependency may preempt an existing ordering of nodes to be performed. In at least one embodiment, for example, node F in graph 102 may be defined prior to node D, but a launch order dependency from D to F (e.g., indicating that D must launch before F) may preempt, or otherwise have priority over, an existing ordering. In at least one embodiment, a launch order dependency may be defined between two or more instructions. In at least one embodiment, a launch order dependency may be defined between two or more kernels. In at least one embodiment, for example, a launch order dependency may be generated between a kernel node and another kernel node, memory copy node, and/or memory set node. In at least one embodiment, a launch order dependency may be defined between a kernel and a non-kernel operation, such as a CPU synchronization.

[0099] In at least one embodiment, a graph dependency is a fast launch dependency. In at least one embodiment, a fast launch dependency is a dependency which constrains a node of graph 102 to allow it to launch before another node has completed execution, or otherwise finished being performed (e.g., as described below in relation to fast launch dependency 322 of FIG. 3). In at least one embodiment, a fast dependency between two or more nodes facilitates performance of one or more tasks that are not dependent on results, data, or operations of said nodes. In at least one embodiment, for example, tasks that are not dependent on results, data, or operations of other nodes, comprises tasks such as zeroing buffers or loading constant data values, which can be performed concurrently.

[0100] In at least one embodiment, a graph include edge information, such as edge information 110 and/or edge information 112, that corresponding to one or more dependencies between two or more nodes, as described below in relation to FIG. 4 and/or FIG. 5. In at least one embodiment, edge information includes information indicating an edge type. In at least one embodiment, an edge type may specify a type of edge and/or a type of dependency associated with a corresponding edge. In at least one embodiment, for example, edge information associated with an edge indicates a launch order dependency for two nodes at a source and destination of this edge. In at least one embodiment, for example, edge information associated with an edge indicates an anti-deadlock dependency for two nodes at a source and destination of this edge. In at least one embodiment, edge information may include one or more port definitions. In at least one embodiment, using an edge type and/or port definitions in an edge information, constraints between two nodes are identified when a graph is created and/or executed.

[0101] In at least one embodiment, information collected during graph creation is used to generate and execute graphs. In at least one embodiment, this information comprises edge information, such as edge information 110 and/or edge information 112.

[0102] FIG. 2 illustrates an example 200 of graph creation, in accordance with at least one embodiment. In at least one embodiment, a program uses stream capture or graph creation APIs to define a graph in a multi-threaded environment. Because threads may execute in non-determinate order, a graph whose nodes are created on multiple threads may have nodes whose order of definition is non-deterministic. For example, in at least one embodiment, a thread 202 executes code 204 that starts child threads 206, 210, and these threads 206, 210 execute code 208, 212 to create nodes a-c and d-f, respectively. Because threads 206, 210 execute in non-deterministic order, in at least one embodiment, nodes a-f may be defined in non-deterministic order. For example, possible orders of definition might be (a, b, c, d, e, f) if t2 206 completes execution prior to t3 210, or (a, d, b, e, c, f) in one of many possible examples of interleaved execution.

[0103] In at least one embodiment, however, dependencies for this graph are defined by executing code 208, 212. In at least one embodiment, nodes may be added to a graph using one or more APIs (e.g., as described below in relation to FIGS. 6-26). In at least one embodiment, this may be done as illustrated in FIG. 2, where code 208, 212 includes instructions to add nodes a-f to a graph and set dependencies for nodes a-c and d-f. In at least one embodiment, edge information for this graph are defined by executing code 208, 212. It will be appreciated that this example is intended to be illustrative rather than limiting, and should not be construed in a manner which would limit potential embodiments to only those that incorporate this specific example.

[0104] In at least one embodiment, a graph defined in accordance with example 200 may be generated and/or executed, using dependency definitions and/or edge information. In at least one embodiment, a processor comprises circuitry to execute a graph, at least in part, on dependencies among nodes within each of these graphs, as described above in conjunction with FIG. 1. In at least one embodiment, a processor comprises circuitry to execute a graph, at least in part, on edge information among nodes within each of these graphs, as described above in conjunction with FIG. 1.

[0105] FIG. 3 is an example diagram illustrating node dependencies 300, in accordance with at least one embodiment. In at least one embodiment, node dependencies 300 includes one or more dependencies that have a dependency type. In at least one embodiment, node dependencies 300 include one or more of a full execution dependency 302, launch order dependency 312, fast launch dependency 322, anti-deadlock dependency 332. In at least one embodiment, node dependencies 300 depict one or more temporal relationships between one or more nodes of a graph, as described above in conjunction with FIG. 1.

[0106] In at least one embodiment, full execution dependency 302 relates to a dependency between node 304 and node 306 of a graph. In at least one embodiment, a full execution dependency 302 is in accordance with dependencies described in connection with FIG. 1. In at least one embodiment, full execution dependency 302 is a constraint on node 304 and/or node 306 which prevents node 306 from being performed until a time that node 304 has finished execution, or otherwise being performed. In at least one embodiment, for example, node 306 is not launched for performance until node 304 has completed all associated operations.

[0107] In at least one embodiment, launch order dependency 312 relates to a dependency between node 314 and node 316 of a graph. In at least one embodiment, a launch order dependency 312 is in accordance with dependencies described in connection with FIG. 1. In at least one embodiment, launch order dependency 312 is a constraint on node 314 and/or node 316 which prevents one or more instructions associated with node 316 from being performed until a time that one or more instructions associated with node 314 has finished being launched, or otherwise begun to be performed. In at least one embodiment, for example, node 316 is not launched for performance until node 314 has been launched. In at least one embodiment, node 316 is launched to be performed at a time that precedes completed performance of node 314.

[0108] In at least one embodiment, fast launch dependency 322 relates to a dependency between node 324 and node 326 of a graph. In at least one embodiment, a fast launch dependency 322 is in accordance with dependencies described in connection with FIG. 1. In at least one embodiment, launch order dependency 322 is a constraint on node 324 and/or node 326 which allows node 326 to launch before node 324 has completed execution, or otherwise finished being performed. In at least one embodiment, node 326 performs one or more tasks that are not dependent on results, data, or operations of node 324 and portions of tasks associated with node 326 are performed concurrently with node 324. In at least one embodiment, for example, node 326 includes a preamble 328 comprising tasks such as zeroing buffers or loading constant data values, which does not depend on node 324 and can be performed concurrently. In at least one embodiment, performance of a portion of node 324 causes a trigger to cause node 326 to launch. In at least one embodiment, a trigger associated with node 324 indicates that node 326 is to be launched.

[0109] In at least one embodiment, anti-deadlock dependency 332 relates to a dependency between node 334 and node 336A of a graph. In at least one embodiment, an anti-deadlock dependency 332 is in accordance with dependencies described in connection with FIG. 1. In at least one embodiment, anti-deadlock dependency 332 is a constraint on node 334 and/or node 336A which prevents node 334 from being blocked (e.g., throttled) by node 336A. For example, node 334 constrains node 336B from being performed using a full execution dependency between node 334 and node 336B. In at least one embodiment, in that example, node 336B does not have an anti-deadlock dependency with node 334, such that another dependency (e.g., full execution dependency) can be formed between node 336B and node 334. In at least one embodiment, node 334 is launched to be performed at a time that is not constrained by a complete and/or partial launch and/or performance of node 336A.

[0110] FIG. 4 is an example diagram illustrating dependency edge information 400, in accordance with at least one embodiment. In at least one embodiment, dependency edge information 400 comprises edge information 402 and/or edge information 412. In at least one embodiment, edge information 402 may correspond to a fast dependent launch dependency type for an edge 408 between node 404 and node 406. In at least one embodiment, edge information 402 includes an edge dependency type. In at least one embodiment, edge dependency type is represented by a corresponding value (e.g., “2”) that indicates a particular dependency type for edge 408. In at least one embodiment, edge information 402 includes port definitions that include a source port definition and/or a destination port definition corresponding to edge 408. In at least one embodiment, source port definition is associated with a source node (e.g., node 404) of edge 408. In at least one embodiment, a destination port definition is associated with a destination node (e.g., node 406) of edge 408. In at least one embodiment, a source port definition and/or destination port definition is represented by a value indicating one or more constraints on operations of node 404 and/or node 406. In at least one embodiment, for example, a source port definition having a numerical value “2” and a destination port definition having a numerical value “0,” may indicate that, based on a dependency type of “2,” that there exists a fast launch dependency between node 404 and node 406.

[0111] In at least one embodiment, edge information 412 may correspond to a launch order dependency type for an edge 418 between node 414 and node 416. In at least one embodiment, edge information 412 includes an edge dependency type. In at least one embodiment, edge dependency type is represented by a corresponding value (e.g., “2”) that indicates a particular dependency type for edge 418. In at least one embodiment, edge information 412 includes port definitions that include a source port definition and/or a destination port definition corresponding to edge 418. In at least one embodiment, source port definition is associated with a source node (e.g., node 414) of edge 418. In at least one embodiment, a destination port definition is associated with a destination node (e.g., node 416) of edge 418. In at least one embodiment, a source port definition and/or destination port definition is represented by a value indicating one or more constraints on operations of node 414 and/or node 416. In at least one embodiment, for example, a source port definition having a numerical value “1” and a destination port definition having a numerical value “0,” may indicate that, based on a dependency type of “2,” that there exists a launch order dependency between node 414 and node 416. In at least one embodiment, based on a dependency type indicated by edge information 412, one or more instructions associated with node 416 will not begin performance until one or more instructions associated with node 414 have begun performance.

[0112] FIG. 5 is an example diagram illustrating edge information 500, in accordance with at least one embodiment. In at least one embodiment, dependency edge information 500 comprises edge information 502 and/or edge information 512. In at least one embodiment, edge information 502 may correspond to an anti-dependency type for an edge 508 between node 504 and node 506. In at least one embodiment, edge information 502 includes an edge dependency type. In at least one embodiment, edge dependency type is represented by a corresponding value (e.g., “1”) that indicates a particular dependency type for edge 508. In at least one embodiment, edge information 502 includes port definitions that include a source port definition and/or a destination port definition corresponding to edge 508. In at least one embodiment, source port definition is associated with a source node (e.g., node 504) of edge 508. In at least one embodiment, a destination port definition is associated with a destination node (e.g., node 506) of edge 508. In at least one embodiment, a source port definition and/or destination port definition is represented by a value indicating one or more constraints on operations of node 504 and/or node 506. In at least one embodiment, for example, a source port definition having a numerical value “0” and a destination port definition having a numerical value “0,” may indicate that, based on a dependency type of “1,” that there exists an anti-deadlock dependency between node 504 and node 506.

[0113] In at least one embodiment, edge information 512 may correspond to a fast dependent launch dependency type for an edge 518 between node 514 and node 516. In at least one embodiment, node 514 and/or node 516 corresponds to a memory copy operation. In at least one embodiment, edge information 512 includes an edge dependency type. In at least one embodiment, edge dependency type is represented by a corresponding value (e.g., “0”) that indicates a particular dependency type for edge 518. In at least one embodiment, edge information 512 includes port definitions that include a source port definition and/or a destination port definition corresponding to edge 518. In at least one embodiment, source port definition is associated with a source node (e.g., node 514) of edge 518. In at least one embodiment, a destination port definition is associated with a destination node (e.g., node 516) of edge 518. In at least one embodiment, a source port definition and/or destination port definition is represented by a value indicating one or more constraints on operations of node 514 and/or node 516. In at least one embodiment, for example, a source port definition having a numerical value “1” and a destination port definition having a numerical value “2,” may indicate that, based on a dependency type of “0,” that there exists a memory copy dependency between node 514 and node 516.

[0114] FIG. 6 is a block diagram illustrating a child graph node operation 600 (“operation 600”), in accordance with at least one embodiment. In at least one embodiment, an operation 600 is one or more computational operations that, if performed, cause a node to be generated and/or added to a graph, as described above in conjunction with FIG. 1. In at least one embodiment, operation 600 is to cause a child graph node to be added to a software graph based, at least in part, on a dependency type. In at least one embodiment, operation 600 is to cause a node, which includes an embedded graph (e.g., child graph), to be generated and/or added to a graph. In at least one embodiment, operation 600 is a set of instructions that, if performed, cause one or more processors to cause one or more APIs to be performed.

[0115] In at least one embodiment, a child graph node invocation 602 (“invocation 602”) is a function call to be performed by one or more software programs, such as kernels to be performed by one or more parallel processing units (PPUs), such as graphics processing units (GPUs). In at least one embodiment, invocation 602 is an invocation of an instruction to cause one or more processors to perform one or more computational operations 622, 624 of a child graph node response 620 (“response 620”). In at least one embodiment, invocation 602 is an invocation of an API to cause one or more processors to perform one or more computational operations 622, 624 of response 620.

[0116] In at least one embodiment, invocation 602 receives, when invoked, one or more parameters 604, 606, 608, 610, 612, 614, 616, to indicate information about computational operations to be performed. In at least one embodiment, invocation 602 receives, when invoked, one or more parameters 604, 606, 608, 610, 612, 614, 616 to indicate information about instructions to be performed.

[0117] In at least one embodiment, invocation 602 receives, as input, parameters 604, 606, 608, 610, 612, 614, 616 comprising a node pointer 604. In at least one embodiment, node pointer 604 is data comprising information indicating one or more nodes to be created by operation 600. In at least one embodiment, node pointer 604 is a pointer to an address corresponding to one or more nodes to be created by operation 600. In at least one embodiment, node pointer 604 is data to be input to a function call, if said function call is to perform invocation 602. In at least one embodiment, node pointer 604 is data to be input to an API, if said API is to cause invocation 602 to be performed.

[0118] In at least one embodiment, invocation 602 receives, as input, parameters 604, 606, 608, 610, 612, 614, 616 comprising a graph 606. In at least one embodiment, graph 606 is data comprising information indicating one or more attributes of a graph, such as nodes, edges, dependencies, and/or any other suitable attribute. In at least one embodiment, graph 606 is associated with an instantiated graph that is evaluated to be generated and/or executed, as described above in conjunction with FIG. 1, and/or FIG. 2. In at least one embodiment, graph 606 is data to be input to a function call, if said function call is to perform invocation 602. In at least one embodiment, graph 606 is data to be input to an API, if said API is to cause invocation 602 to be performed.

[0119] In at least one embodiment, invocation 602 receives, as input, parameters 604, 606, 608, 610, 612, 614, 616 comprising a dependency pointer 608. In at least one embodiment, dependency pointer 608 is data comprising information indicating one or more dependencies between two or more nodes of a graph. In at least one embodiment, dependency pointer 608 includes information corresponding to one or more dependencies between a node indicated by node pointer 604 and one or more other nodes of graph 606. In at least one embodiment, dependency pointer 608 is data to be input to a function call, if said function call is to perform invocation 602. In at least one embodiment, dependency pointer 608 is data to be input to an API, if said API is to cause invocation 602 to be performed.

[0120] In at least one embodiment, invocation 602 receives, as input, parameters 604, 606, 608, 610, 612, 614, 616 comprising edge information 610. In at least one embodiment, edge information 610 is data comprising information corresponding to one or more dependencies of graph 606. In at least one embodiment, edge information 610 includes information indicating one or more dependencies between a node associated with node pointer 604 and one or more nodes of graph 606. In at least one embodiment, edge information 610 includes an indication of one or more of a source port, a destination port, and/or a dependency type, as described above in conjunction with FIG. 1, FIG. 3, FIG. 4, and/or FIG. 5. In at least one embodiment, edge information 610 may be represented as an array, in which each element corresponds to an element of a parallel array associated with dependency pointer 608. In at least one embodiment, edge information 610 is data to be input to a function call, if said function call is to perform invocation 602. In at least one embodiment, edge information 610 is data to be input to an API, if said API is to cause invocation 602 to be performed.

[0121] In at least one embodiment, invocation 602 receives, as input, parameters 604, 606, 608, 610, 612, 614, 616 comprising a number of dependencies 612. In at least one embodiment, number of dependencies 612 is data indicating a number, or quantity, of dependencies associated with a node of graph 606 associated with node pointer 604. In at least one embodiment, number of dependencies 612 is data to be input to a function call, if said function call is to perform invocation 602. In at least one embodiment, number of dependencies 612 is data to be input to an API, if said API is to cause invocation 602 to be performed.

[0122] In at least one embodiment, invocation 602 receives, as input, parameters 604, 606, 608, 610, 612, 614, 616 comprising a child graph 614. In at least one embodiment, child graph 614 is data comprising information indicating one or more attributes of a graph to be replicated into a node of graph 606 associated with node pointer 604, such as nodes, edges, dependencies, and/or any other suitable attribute. In at least one embodiment, invocation 602 is to add a node (indicated by node pointer 604) to graph 606, which include a replication of child graph 614. In at least one embodiment, child graph 614 is associated with an instantiated graph that is evaluated to be generated and/or executed, as described above in conjunction with FIG. 1. In at least one embodiment, child graph 614 is data to be input to a function call, if said function call is to perform invocation 602. In at least one embodiment, child graph 614 is data to be input to an API, if said API is to cause invocation 602 to be performed.

[0123] In at least one embodiment, invocation 602 receives, as input, parameters 604, 606, 608, 610, 612, 614, 616 comprising other parameter(s) 616. In at least one embodiment, other parameter(s) 616 are data comprising any other information usable by operation 600. In at least one embodiment, other parameter(s) 616 are data to be input to a function call, if said function call is to perform invocation 602. In at least one embodiment, other parameter(s) 616 are data to be input to an API, if said API is to cause invocation 602 to be performed.

[0124] In at least one embodiment, an example instruction indicating operation 600 in a parallel computing environment, such as compute uniform device architecture (CUDA), is as follows:

[0125] cudaGraphAddChildGraphNode (pGraphNode, graph, pDependencies, pDependencyData, numDependencies, childGraph) where pGraphNode corresponds to node pointer 604, graph corresponds to graph 606, pDependencies corresponds to dependency pointer 608, pDependencyData corresponds to edge information 610, numDependencies corresponds to number of dependencies 612, and childGraph corresponds to child graph 614.

[0126] In at least one embodiment, response 620 generates, as output, parameters 622, 624 comprising a status 622. In at least one embodiment, status 622 is data comprising any other information presented by operation 600. In at least one embodiment, status 622 is data to be output in response to a function call, if said function call is to perform invocation 602. In at least one embodiment, status 622 is data to be output by an API, if said API is to cause invocation 602 to be performed. In at least one embodiment, status 622 indicates that operation 600 was performed successfully. In at least one embodiment, status 622 indicates that operation 600 was not performed successfully, or otherwise failed.

[0127] In at least one embodiment, response 620 generates, as output, parameters 622, 624 comprising node 624. In at least one embodiment, node 624 is data to one or more nodes generated by operation 600, using information associated with invocation 602, such as parameters 604, 606, 608, 610, 612, 614, 616. In at least one embodiment, node 624 will be output by response 620 to an address corresponding to node pointer 604, such that node 624 will be generated by storing data to an address indicated by node pointer 604. In at least one embodiment, node 624 is data to be output in response to a function call, if said function call is to perform invocation 602. In at least one embodiment, node 624 is data to be output by an API, if said API is to cause invocation 602 to be performed. In at least one embodiment, node 624 is provided to data structure, memory, and/or variable indicated by node pointer 604. In at least one embodiment, node 624 is presented in response to performance of one or more API and/or function calls.

[0128] FIG. 7 is a block diagram illustrating an empty graph node operation 700 (“operation 700”), in accordance with at least one embodiment. In at least one embodiment, operation 700 is one or more computational operations that, if performed, cause an empty node to be generated and/or added to a graph, as described above in conjunction with FIG. 1. In at least one embodiment, operation 700 is to cause a null-operation graph node to be added to a software graph based, at least in part, on a dependency type. In at least one embodiment, an empty node performs no operation during execution. In at least one embodiment, an empty node is used for transitive ordering. In at least one embodiment, for example, a phased execution graph with 2 groups of n nodes with a barrier between them can be represented using an empty node and 2*n dependency edges, rather than no empty node and n{circumflex over ( )}2 dependency edges. In at least one embodiment, operation 700 is to cause an empty node to be generated and/or added to a graph. In at least one embodiment, operation 700 is a set of instructions that, if performed, cause one or more processors to cause one or more APIs to be performed.

[0129] In at least one embodiment, an empty graph node invocation 702 (“invocation 702”) is a function call to be performed by one or more software programs, such as kernels to be performed by one or more parallel processing units (PPUs), such as graphics processing units (GPUs). In at least one embodiment, invocation 702 is an invocation of an instruction to cause one or more processors to perform one or more computational operations 722, 724 of an empty graph node response 720 (“response 720”). In at least one embodiment, invocation 702 is an invocation of an API to cause one or more processors to perform one or more computational operations 722, 724 of response 720.

[0130] In at least one embodiment, invocation 702 receives, when invoked, one or more parameters 704, 706, 708, 710, 712, 716, to indicate information about computational operations to be performed. In at least one embodiment, invocation 702 receives, when invoked, one or more parameters 704, 706, 708, 710, 712, 716 to indicate information about instructions to be performed.

[0131] In at least one embodiment, invocation 702 receives, as input, parameters 704, 706, 708, 710, 712, 716 comprising a node pointer 704. In at least one embodiment, node pointer 704 is data comprising information indicating one or more nodes to be created by operation 700. In at least one embodiment, node pointer 704 is a pointer to an address corresponding to one or more nodes to be created by operation 700. In at least one embodiment, node pointer 704 is data to be input to a function call, if said function call is to perform invocation 702. In at least one embodiment, node pointer 704 is data to be input to an API, if said API is to cause invocation 702 to be performed.

[0132] In at least one embodiment, invocation 702 receives, as input, parameters 704, 706, 708, 710, 712, 716 comprising a graph 706. In at least one embodiment, graph 706 is data comprising information indicating one or more attributes of a graph, such as nodes, edges, dependencies, and/or any other suitable attribute. In at least one embodiment, graph 706 is associated with an instantiated graph that is evaluated to be generated and/or executed, as described above in conjunction with FIG. 1, and/or FIG. 2. In at least one embodiment, graph 706 is data to be input to a function call, if said function call is to perform invocation 702. In at least one embodiment, graph 706 is data to be input to an API, if said API is to cause invocation 702 to be performed.

[0133] In at least one embodiment, invocation 702 receives, as input, parameters 704, 706, 708, 710, 712, 716 comprising a dependency pointer 708. In at least one embodiment, dependency pointer 708 is data comprising information indicating one or more dependencies between two or more nodes of a graph. In at least one embodiment, dependency pointer 708 includes information corresponding to one or more dependencies between a node indicated by node pointer 704 and one or more other nodes of graph 706. In at least one embodiment, dependency pointer 708 is data to be input to a function call, if said function call is to perform invocation 702. In at least one embodiment, dependency pointer 708 is data to be input to an API, if said API is to cause invocation 702 to be performed.

[0134] In at least one embodiment, invocation 702 receives, as input, parameters 704, 706, 708, 710, 712, 716 comprising edge information 710. In at least one embodiment, edge information 710 is data comprising information corresponding to one or more dependencies of graph 706. In at least one embodiment, edge information 710 includes information indicating one or more dependencies between a node associated with node pointer 704 and one or more nodes of graph 706. In at least one embodiment, edge information 710 includes an indication of one or more of a source port, a destination port, and/or a dependency type, as described above in conjunction with FIG. 1, FIG. 3, FIG. 4, and/or FIG. 5. In at least one embodiment, edge information 710 may be represented as an array, in which each element corresponds to an element of a parallel array associated with dependency pointer 708. In at least one embodiment, edge information 710 is data to be input to a function call, if said function call is to perform invocation 702. In at least one embodiment, edge information 710 is data to be input to an API, if said API is to cause invocation 702 to be performed.

[0135] In at least one embodiment, invocation 702 receives, as input, parameters 704, 706, 708, 710, 712, 716 comprising a number of dependencies 712. In at least one embodiment, number of dependencies 712 is data indicating a number, or quantity, of dependencies associated with a node of graph 706 associated with node pointer 704. In at least one embodiment, number of dependencies 712 is data to be input to a function call, if said function call is to perform invocation 702. In at least one embodiment, number of dependencies 712 is data to be input to an API, if said API is to cause invocation 702 to be performed.

[0136] In at least one embodiment, invocation 702 receives, as input, parameters 704, 706, 708, 710, 712, 716 comprising other parameter(s) 716. In at least one embodiment, other parameter(s) 716 are data comprising any other information usable by operation 700. In at least one embodiment, other parameter(s) 716 are data to be input to a function call, if said function call is to perform invocation 702. In at least one embodiment, other parameter(s) 716 are data to be input to an API, if said API is to cause invocation 702 to be performed.

[0137] In at least one embodiment, an example instruction indicating operation 700 in a parallel computing environment, such as compute uniform device architecture (CUDA), is as follows:

[0138] cudaGraphAddEmptyNode (pGraphNode, graph, pDependencies, pDependencyData, numDependencies) where pGraphNode corresponds to node pointer 704, graph corresponds to graph 706, pDependencies corresponds to dependency pointer 708, pDependencyData corresponds to edge information 710, and numDependencies corresponds to number of dependencies 712.

[0139] In at least one embodiment, response 720 generates, as output, parameters 722, 724 comprising a status 722. In at least one embodiment, status 722 is data comprising any other information presented by operation 700. In at least one embodiment, status 722 is data to be output in response to a function call, if said function call is to perform invocation 702. In at least one embodiment, status 722 is data to be output by an API, if said API is to cause invocation 702 to be performed. In at least one embodiment, status 722 indicates that operation 700 was performed successfully. In at least one embodiment, status 722 indicates that operation 700 was not performed successfully, or otherwise failed.

[0140] In at least one embodiment, response 720 generates, as output, parameters 722, 724 comprising node 724. In at least one embodiment, node 724 is data to one or more nodes generated by operation 700, using information associated with invocation 702, such as parameters 704, 706, 708, 710, 712, 716. In at least one embodiment, node 724 will be output by response 720 to an address corresponding to node pointer 704, such that node 724 will be generated by storing data to an address indicated by node pointer 704. In at least one embodiment, node 724 is data to be output in response to a function call, if said function call is to perform invocation 702. In at least one embodiment, node 724 is data to be output by an API, if said API is to cause invocation 702 to be performed. In at least one embodiment, node 724 is provided to data structure, memory, and/or variable indicated by node pointer 704. In at least one embodiment, node 724 is presented in response to performance of one or more API and/or function calls.

[0141] FIG. 8 is a block diagram illustrating an event record node operation 800 (“operation 800”), in accordance with at least one embodiment. In at least one embodiment, operation 800 is one or more computational operations that, if performed, cause a node to be generated and/or added to a graph, as described above in conjunction with FIG. 1. In at least one embodiment, operation 800 is to store an indication of whether a node within a software graph was performed based, at least in part, on a dependency type. In at least one embodiment, operation 800 is to cause an event record node to be generated and/or added to a graph. In at least one embodiment, an event record node, when executed, causes an event to be recorded, and/or continue to be recorded. In at least one embodiment, an event is to monitor progress of one or more operations, such as monitoring a launch or a software kernel. In at least one embodiment, an event record node is to monitor execution of one or more dependent nodes. In at least one embodiment, an event may be queried to determine whether a particular event (e.g., a launching of a kernel and/or other operation) has completed. In at least one embodiment, operation 800 is a set of instructions that, if performed, cause one or more processors to cause one or more APIs to be performed.

[0142] In at least one embodiment, an event record node invocation 802 (“invocation 802”) is a function call to be performed by one or more software programs, such as kernels to be performed by one or more parallel processing units (PPUs), such as graphics processing units (GPUs). In at least one embodiment, invocation 802 is an invocation of an instruction to cause one or more processors to perform one or more computational operations 822, 824 of an empty graph node response 820 (“response 820”). In at least one embodiment, invocation 802 is an invocation of an API to cause one or more processors to perform one or more computational operations 822, 824 of response 820.

[0143] In at least one embodiment, invocation 802 receives, when invoked, one or more parameters 804, 806, 808, 810, 812, 814, 816, to indicate information about computational operations to be performed. In at least one embodiment, invocation 802 receives, when invoked, one or more parameters 804, 806, 808, 810, 812, 814, 816 to indicate information about instructions to be performed.

[0144] In at least one embodiment, invocation 802 receives, as input, parameters 804, 806, 808, 810, 812, 814, 816 comprising a node pointer 804. In at least one embodiment, node pointer 804 is data comprising information indicating one or more nodes to be created by operation 800. In at least one embodiment, node pointer 804 is a pointer to an address corresponding to one or more nodes to be created by operation 800. In at least one embodiment, node pointer 804 is data to be input to a function call, if said function call is to perform invocation 802. In at least one embodiment, node pointer 804 is data to be input to an API, if said API is to cause invocation 802 to be performed.

[0145] In at least one embodiment, invocation 802 receives, as input, parameters 804, 806, 808, 810, 812, 814, 816 comprising a graph 806. In at least one embodiment, graph 806 is data comprising information indicating one or more attributes of a graph, such as nodes, edges, dependencies, and/or any other suitable attribute. In at least one embodiment, graph 806 is associated with an instantiated graph that is evaluated to be generated and/or executed, as described above in conjunction with FIG. 1 and/or FIG. 2. In at least one embodiment, graph 806 is data to be input to a function call, if said function call is to perform invocation 802. In at least one embodiment, graph 806 is data to be input to an API, if said API is to cause invocation 802 to be performed.

[0146] In at least one embodiment, invocation 802 receives, as input, parameters 804, 806, 808, 810, 812, 814, 816 comprising a dependency pointer 808. In at least one embodiment, dependency pointer 808 is data comprising information indicating one or more dependencies between two or more nodes of a graph. In at least one embodiment, dependency pointer 808 includes information corresponding to one or more dependencies between a node indicated by node pointer 804 and one or more other nodes of graph 806. In at least one embodiment, dependency pointer 808 is data to be input to a function call, if said function call is to perform invocation 802. In at least one embodiment, dependency pointer 808 is data to be input to an API, if said API is to cause invocation 802 to be performed.

[0147] In at least one embodiment, invocation 802 receives, as input, parameters 804, 806, 808, 810, 812, 814, 816 comprising edge information 810. In at least one embodiment, edge information 810 is data comprising information corresponding to one or more dependencies of graph 806. In at least one embodiment, edge information 810 includes information indicating one or more dependencies between a node associated with node pointer 804 and one or more nodes of graph 806. In at least one embodiment, edge information 810 includes an indication of one or more of a source port, a destination port, and/or a dependency type, as described above in conjunction with FIG. 1, FIG. 3, FIG. 4, and/or FIG. 5. In at least one embodiment, edge information 810 may be represented as an array, in which each element corresponds to an element of a parallel array associated with dependency pointer 808. In at least one embodiment, edge information 810 is data to be input to a function call, if said function call is to perform invocation 802. In at least one embodiment, edge information 810 is data to be input to an API, if said API is to cause invocation 802 to be performed.

[0148] In at least one embodiment, invocation 802 receives, as input, parameters 804, 806, 808, 810, 812, 814, 816 comprising a number of dependencies 812. In at least one embodiment, number of dependencies 812 is data indicating a number, or quantity, of dependencies associated with a node of graph 806 associated with node pointer 804. In at least one embodiment, number of dependencies 812 is data to be input to a function call, if said function call is to perform invocation 802. In at least one embodiment, number of dependencies 812 is data to be input to an API, if said API is to cause invocation 802 to be performed.

[0149] In at least one embodiment, invocation 802 receives, as input, parameters 804, 806, 808, 810, 812, 814, 816 comprising an event 814. In at least one embodiment, event 814 is data indicating a type of event to be recorded when executing a node of graph 806 associated with node pointer 804. In at least one embodiment, event 814 is data to be input to a function call, if said function call is to perform invocation 802. In at least one embodiment, event 814 is data to be input to an API, if said API is to cause invocation 802 to be performed.

[0150] In at least one embodiment, invocation 802 receives, as input, parameters 804, 806, 808, 810, 812, 814, 816 comprising other parameter(s) 816. In at least one embodiment, other parameter(s) 816 are data comprising any other information usable by operation 800. In at least one embodiment, other parameter(s) 816 are data to be input to a function call, if said function call is to perform invocation 802. In at least one embodiment, other parameter(s) 816 are data to be input to an API, if said API is to cause invocation 802 to be performed.

[0151] In at least one embodiment, an example instruction indicating operation 800 in a parallel computing environment, such as compute uniform device architecture (CUDA), is as follows:

[0152] cudaGraphAddEventRecordNode (pGraphNode, graph, pDependencies, pDependencyData, numDependencies, event) where pGraphNode corresponds to node pointer 804, graph corresponds to graph 806, pDependencies corresponds to dependency pointer 808, pDependencyData corresponds to edge information 810, and numDependencies corresponds to number of dependencies 812, and event corresponds to event 814.

[0153] In at least one embodiment, response 820 generates, as output, parameters 822, 824 comprising a status 822. In at least one embodiment, status 822 is data comprising any other information presented by operation 800. In at least one embodiment, status 822 is data to be output in response to a function call, if said function call is to perform invocation 802. In at least one embodiment, status 822 is data to be output by an API, if said API is to cause invocation 802 to be performed. In at least one embodiment, status 822 indicates that operation 800 was performed successfully. In at least one embodiment, status 822 indicates that operation 800 was not performed successfully, or otherwise failed.

[0154] In at least one embodiment, response 820 generates, as output, parameters 822, 824 comprising node 824. In at least one embodiment, node 824 is data to one or more nodes generated by operation 800, using information associated with invocation 802, such as parameters 804, 806, 808, 810, 812, 814, 816. In at least one embodiment, node 824 will be output by response 820 to an address corresponding to node pointer 804, such that node 824 will be generated by storing data to an address indicated by node pointer 804. In at least one embodiment, node 824 is data to be output in response to a function call, if said function call is to perform invocation 802. In at least one embodiment, node 824 is data to be output by an API, if said API is to cause invocation 802 to be performed. In at least one embodiment, node 824 is provided to data structure, memory, and/or variable indicated by node pointer 804. In at least one embodiment, node 824 is presented in response to performance of one or more API and/or function calls.

[0155] FIG. 9 is a block diagram illustrating an event wait node operation 900 (“operation 900”), in accordance with at least one embodiment. In at least one embodiment, operation 900 is one or more computational operations that, if performed, cause a node to be generated and/or added to a graph, as described above in conjunction with FIG. 1. In at least one embodiment, operation 900 is to cause an event wait node to be added to a software graph based, at least in part, on a dependency type. In at least one embodiment, operation 900 is to cause an event wait node to be generated and/or added to a graph. In at least one embodiment, an event wait node, when executed, causes a node to wait for work associated with an event to be performed. In at least one embodiment, an event wait node will wait on one or more events associated with a context and/or device distinct from a launch stream of said event wait node. In at least one embodiment, an event is to monitor progress of one or more operations, such as monitoring a launch or a software kernel. In at least one embodiment, an event wait node is to monitor execution of one or more dependent nodes. In at least one embodiment, an event may be queried to determine whether a particular event (e.g., a launching of a kernel and/or other operation) has completed. In at least one embodiment, operation 900 is a set of instructions that, if performed, cause one or more processors to cause one or more APIs to be performed.

[0156] In at least one embodiment, an event wait node invocation 902 (“invocation 902”) is a function call to be performed by one or more software programs, such as kernels to be performed by one or more parallel processing units (PPUs), such as graphics processing units (GPUs). In at least one embodiment, invocation 902 is an invocation of an instruction to cause one or more processors to perform one or more computational operations 922, 924 of an empty graph node response 920 (“response 920”). In at least one embodiment, invocation 902 is an invocation of an API to cause one or more processors to perform one or more computational operations 922, 924 of response 920.

[0157] In at least one embodiment, invocation 902 receives, when invoked, one or more parameters 904, 906, 908, 910, 912, 914, 916, to indicate information about computational operations to be performed. In at least one embodiment, invocation 902 receives, when invoked, one or more parameters 904, 906, 908, 910, 912, 914, 916 to indicate information about instructions to be performed.

[0158] In at least one embodiment, invocation 902 receives, as input, parameters 904, 906, 908, 910, 912, 914, 916 comprising a node pointer 904. In at least one embodiment, node pointer 904 is data comprising information indicating one or more nodes to be created by operation 900. In at least one embodiment, node pointer 904 is a pointer to an address corresponding to one or more nodes to be created by operation 900. In at least one embodiment, node pointer 904 is data to be input to a function call, if said function call is to perform invocation 902. In at least one embodiment, node pointer 904 is data to be input to an API, if said API is to cause invocation 902 to be performed.

[0159] In at least one embodiment, invocation 902 receives, as input, parameters 904, 906, 908, 910, 912, 914, 916 comprising a graph 906. In at least one embodiment, graph 906 is data comprising information indicating one or more attributes of a graph, such as nodes, edges, dependencies, and/or any other suitable attribute. In at least one embodiment, graph 906 is associated with an instantiated graph that is evaluated to be generated and/or executed, as described above in conjunction with FIG. 1, and/or FIG. 2. In at least one embodiment, graph 906 is data to be input to a function call, if said function call is to perform invocation 902. In at least one embodiment, graph 906 is data to be input to an API, if said API is to cause invocation 902 to be performed.

[0160] In at least one embodiment, invocation 902 receives, as input, parameters 904, 906, 908, 910, 912, 914, 916 comprising a dependency pointer 908. In at least one embodiment, dependency pointer 908 is data comprising information indicating one or more dependencies between two or more nodes of a graph. In at least one embodiment, dependency pointer 908 includes information corresponding to one or more dependencies between a node indicated by node pointer 904 and one or more other nodes of graph 906. In at least one embodiment, dependency pointer 908 is data to be input to a function call, if said function call is to perform invocation 902. In at least one embodiment, dependency pointer 908 is data to be input to an API, if said API is to cause invocation 902 to be performed.

[0161] In at least one embodiment, invocation 902 receives, as input, parameters 904, 906, 908, 910, 912, 914, 916 comprising edge information 910. In at least one embodiment, edge information 910 is data comprising information corresponding to one or more dependencies of graph 906. In at least one embodiment, edge information 910 includes information indicating one or more dependencies between a node associated with node pointer 904 and one or more nodes of graph 906. In at least one embodiment, edge information 910 includes an indication of one or more of a source port, a destination port, and/or a dependency type, as described above in conjunction with FIG. 1, FIG. 2, FIG. 5, and/or FIG. 6. In at least one embodiment, edge information 910 may be represented as an array, in which each element corresponds to an element of a parallel array associated with dependency pointer 908. In at least one embodiment, edge information 910 is data to be input to a function call, if said function call is to perform invocation 902. In at least one embodiment, edge information 910 is data to be input to an API, if said API is to cause invocation 902 to be performed.

[0162] In at least one embodiment, invocation 902 receives, as input, parameters 904, 906, 908, 910, 912, 914, 916 comprising a number of dependencies 912. In at least one embodiment, number of dependencies 912 is data indicating a number, or quantity, of dependencies associated with a node of graph 906 associated with node pointer 904. In at least one embodiment, number of dependencies 912 is data to be input to a function call, if said function call is to perform invocation 902. In at least one embodiment, number of dependencies 912 is data to be input to an API, if said API is to cause invocation 902 to be performed.

[0163] In at least one embodiment, invocation 902 receives, as input, parameters 904, 906, 908, 910, 912, 914, 916 comprising an event 914. In at least one embodiment, event 914 is data indicating a type of event to be recorded when executing a node of graph 906 associated with node pointer 904. In at least one embodiment, event 914 is data to be input to a function call, if said function call is to perform invocation 902. In at least one embodiment, event 914 is data to be input to an API, if said API is to cause invocation 902 to be performed.

[0164] In at least one embodiment, invocation 902 receives, as input, parameters 904, 906, 908, 910, 912, 914, 916 comprising other parameter(s) 916. In at least one embodiment, other parameter(s) 916 are data comprising any other information usable by operation 900. In at least one embodiment, other parameter(s) 916 are data to be input to a function call, if said function call is to perform invocation 902. In at least one embodiment, other parameter(s) 916 are data to be input to an API, if said API is to cause invocation 902 to be performed.

[0165] In at least one embodiment, an example instruction indicating operation 900 in a parallel computing environment, such as compute uniform device architecture (CUDA), is as follows:

[0166] cudaGraphAddEventWaitNode (pGraphNode, graph, pDependencies, pDependencyData, numDependencies, event) where pGraphNode corresponds to node pointer 904, graph corresponds to graph 906, pDependencies corresponds to dependency pointer 908, pDependencyData corresponds to edge information 910, and numDependencies corresponds to number of dependencies 912, and event corresponds to event 914.

[0167] In at least one embodiment, response 920 generates, as output, parameters 922, 924 comprising a status 922. In at least one embodiment, status 922 is data comprising any other information presented by operation 900. In at least one embodiment, status 922 is data to be output in response to a function call, if said function call is to perform invocation 902. In at least one embodiment, status 922 is data to be output by an API, if said API is to cause invocation 902 to be performed. In at least one embodiment, status 922 indicates that operation 900 was performed successfully. In at least one embodiment, status 922 indicates that operation 900 was not performed successfully, or otherwise failed.

[0168] In at least one embodiment, response 920 generates, as output, parameters 922, 924 comprising node 924. In at least one embodiment, node 924 is data to one or more nodes generated by operation 900, using information associated with invocation 902, such as parameters 904, 906, 908, 910, 912, 914, 916. In at least one embodiment, node 924 will be output by response 920 to an address corresponding to node pointer 904, such that node 924 will be generated by storing data to an address indicated by node pointer 904. In at least one embodiment, node 924 is data to be output in response to a function call, if said function call is to perform invocation 902. In at least one embodiment, node 924 is data to be output by an API, if said API is to cause invocation 902 to be performed. In at least one embodiment, node 924 is provided to data structure, memory, and/or variable indicated by node pointer 904. In at least one embodiment, node 924 is presented in response to performance of one or more API and/or function calls.

[0169] FIG. 10 is a block diagram illustrating an external semaphore signal node operation 1000 (“operation 1000”), in accordance with at least one embodiment. In at least one embodiment, operation 1000 is one or more computational operations that, if performed, cause a node to be generated and/or added to a graph, as described above in conjunction with FIG. 1. In at least one embodiment, operation 1000 is to cause a semaphore update node to be added to a software graph based, at least in part, on a dependency type. In at least one embodiment, operation 1000 is to cause an external semaphore signal node to be generated and/or added to a graph. In at least one embodiment, an external semaphore signal node, when executed, causes a signal operation on a set of externally allocated semaphore objects to be performed. In at least one embodiment, a signal operation on a set of externally allocated semaphore objects facilitate a synchronization of one or more internal and/or external objects. In at least one embodiment, operation 1000 is a set of instructions that, if performed, cause one or more processors to cause one or more APIs to be performed.

[0170] In at least one embodiment, an external semaphore signal node invocation 1002 (“invocation 1002”) is a function call to be performed by one or more software programs, such as kernels to be performed by one or more parallel processing units (PPUs), such as graphics processing units (GPUs). In at least one embodiment, invocation 1002 is an invocation of an instruction to cause one or more processors to perform one or more computational operations 1022, 1024 of an external semaphore signal node response 1020 (“response 1020”). In at least one embodiment, invocation 1002 is an invocation of an API to cause one or more processors to perform one or more computational operations 1022, 1024 of response 1020.

[0171] In at least one embodiment, invocation 1002 receives, when invoked, one or more parameters 1004, 1006, 1008, 1010, 1012, 1014, 1016, to indicate information about computational operations to be performed. In at least one embodiment, invocation 1002 receives, when invoked, one or more parameters 1004, 1006, 1008, 1010, 1012, 1014, 1016 to indicate information about instructions to be performed.

[0172] In at least one embodiment, invocation 1002 receives, as input, parameters 1004, 1006, 1008, 1010, 1012, 1014, 1016 comprising a node pointer 1004. In at least one embodiment, node pointer 1004 is data comprising information indicating one or more nodes to be created by operation 1000. In at least one embodiment, node pointer 1004 is a pointer to an address corresponding to one or more nodes to be created by operation 1000. In at least one embodiment, node pointer 1004 is data to be input to a function call, if said function call is to perform invocation 1002. In at least one embodiment, node pointer 1004 is data to be input to an API, if said API is to cause invocation 1002 to be performed.

[0173] In at least one embodiment, invocation 1002 receives, as input, parameters 1004, 1006, 1008, 1010, 1012, 1014, 1016 comprising a graph 1006. In at least one embodiment, graph 1006 is data comprising information indicating one or more attributes of a graph, such as nodes, edges, dependencies, and/or any other suitable attribute. In at least one embodiment, graph 1006 is associated with an instantiated graph that is evaluated to be generated and/or executed, as described above in conjunction FIG. 1, and/or FIG. 2. In at least one embodiment, graph 1006 is data to be input to a function call, if said function call is to perform invocation 1002. In at least one embodiment, graph 1006 is data to be input to an API, if said API is to cause invocation 1002 to be performed.

[0174] In at least one embodiment, invocation 1002 receives, as input, parameters 1004, 1006, 1008, 1010, 1012, 1014, 1016 comprising a dependency pointer 1008. In at least one embodiment, dependency pointer 1008 is data comprising information indicating one or more dependencies between two or more nodes of a graph. In at least one embodiment, dependency pointer 1008 includes information corresponding to one or more dependencies between a node indicated by node pointer 1004 and one or more other nodes of graph 1006. In at least one embodiment, dependency pointer 1008 is data to be input to a function call, if said function call is to perform invocation 1002. In at least one embodiment, dependency pointer 1008 is data to be input to an API, if said API is to cause invocation 1002 to be performed.

[0175] In at least one embodiment, invocation 1002 receives, as input, parameters 1004, 1006, 1008, 1010, 1012, 1014, 1016 comprising edge information 1010. In at least one embodiment, edge information 1010 is data comprising information corresponding to one or more dependencies of graph 1006. In at least one embodiment, edge information 1010 includes information indicating one or more dependencies between a node associated with node pointer 1004 and one or more nodes of graph 1006. In at least one embodiment, edge information 1010 includes an indication of one or more of a source port, a destination port, and/or a dependency type, as described above in conjunction with FIG. 1, FIG. 3, FIG. 4, and/or FIG. 5. In at least one embodiment, edge information 1010 may be represented as an array, in which each element corresponds to an element of a parallel array associated with dependency pointer 1008. In at least one embodiment, edge information 1010 is data to be input to a function call, if said function call is to perform invocation 1002. In at least one embodiment, edge information 1010 is data to be input to an API, if said API is to cause invocation 1002 to be performed.

[0176] In at least one embodiment, invocation 1002 receives, as input, parameters 1004, 1006, 1008, 1010, 1012, 1014, 1016 comprising a number of dependencies 1012. In at least one embodiment, number of dependencies 1012 is data indicating a number, or quantity, of dependencies associated with a node of graph 1006 associated with node pointer 1004. In at least one embodiment, number of dependencies 1012 is data to be input to a function call, if said function call is to perform invocation 1002. In at least one embodiment, number of dependencies 1012 is data to be input to an API, if said API is to cause invocation 1002 to be performed.

[0177] In at least one embodiment, invocation 1002 receives, as input, parameters 1004, 1006, 1008, 1010, 1012, 1014, 1016 comprising one or more semaphore parameters 1014. In at least one embodiment, semaphore parameters 1014 is data associated with one or more external semaphore signal corresponding to a node of graph 1006 associated with node pointer 1004. In at least one embodiment, semaphore parameters 1014 include an array of semaphore identifiers and/or handles. In at least one embodiment, semaphore parameters 1014 include an indication of a number of associated handles and/or parameters. In at least one embodiment, semaphore parameters 1014 include an array of semaphore parameters. In at least one embodiment, semaphore parameters 1014 is data to be input to a function call, if said function call is to perform invocation 1002. In at least one embodiment, semaphore parameters 1014 is data to be input to an API, if said API is to cause invocation 1002 to be performed.

[0178] In at least one embodiment, invocation 1002 receives, as input, parameters 1004, 1006, 1008, 1010, 1012, 1014, 1016 comprising other parameter(s) 1016. In at least one embodiment, other parameter(s) 1016 are data comprising any other information usable by operation 1000. In at least one embodiment, other parameter(s) 1016 are data to be input to a function call, if said function call is to perform invocation 1002. In at least one embodiment, other parameter(s) 1016 are data to be input to an API, if said API is to cause invocation 1002 to be performed.

[0179] In at least one embodiment, an example instruction indicating operation 1000 in a parallel computing environment, such as compute uniform device architecture (CUDA), is as follows:

[0180] cudaGraphAddExternalSemaphoresSignalNode (pGraphNode, graph, pDependencies, pDependencyData, numDependencies, nodeParams) where pGraphNode corresponds to node pointer 1004, graph corresponds to graph 1006, pDependencies corresponds to dependency pointer 1008, pDependencyData corresponds to edge information 1010, and numDependencies corresponds to number of dependencies 1012, and nodeParams corresponds to semaphore parameters 1014.

[0181] In at least one embodiment, response 1020 generates, as output, parameters 1022, 1024 comprising a status 1022. In at least one embodiment, status 1022 is data comprising any other information presented by operation 1000. In at least one embodiment, status 1022 is data to be output in response to a function call, if said function call is to perform invocation 1002. In at least one embodiment, status 1022 is data to be output by an API, if said API is to cause invocation 1002 to be performed. In at least one embodiment, status 1022 indicates that operation 1000 was performed successfully. In at least one embodiment, status 1022 indicates that operation 1000 was not performed successfully, or otherwise failed.

[0182] In at least one embodiment, response 1020 generates, as output, parameters 1022, 1024 comprising node 1024. In at least one embodiment, node 1024 is data to one or more nodes generated by operation 1000, using information associated with invocation 1002, such as parameters 1004, 1006, 1008, 1010, 1012, 1014, 1016. In at least one embodiment, node 1024 will be output by response 1020 to an address corresponding to node pointer 1004, such that node 1024 will be generated by storing data to an address indicated by node pointer 1004. In at least one embodiment, node 1024 is data to be output in response to a function call, if said function call is to perform invocation 1002. In at least one embodiment, node 1024 is data to be output by an API, if said API is to cause invocation 1002 to be performed. In at least one embodiment, node 1024 is provided to data structure, memory, and/or variable indicated by node pointer 1004. In at least one embodiment, node 1024 is presented in response to performance of one or more API and/or function calls.

[0183] FIG. 11 is a block diagram illustrating an external semaphore wait node operation 1100 (“operation 1100”), in accordance with at least one embodiment. In at least one embodiment, operation 1100 is one or more computational operations that, if performed, cause a node to be generated and/or added to a graph, as described above in conjunction with FIG. 1. In at least one embodiment, operation 1100 is to cause a semaphore wait node to be added to a software graph based, at least in part, on a dependency type. In at least one embodiment, operation 1100 is to cause an external semaphore wait node to be generated and/or added to a graph. In at least one embodiment, an external semaphore wait node, when executed, performs a wait operation on a set of externally allocated semaphore objects. In at least one embodiment, an external semaphore wait node's dependencies will not be launched (e.g., performed) until one or more wait operations have completed. In at least one embodiment, a wait operation on a set of externally allocated semaphore objects facilitate a synchronization of one or more internal and/or external objects. In at least one embodiment, operation 1100 is a set of instructions that, if performed, cause one or more processors to cause one or more APIs to be performed.

[0184] In at least one embodiment, an event wait node invocation 1102 (“invocation 1102”) is a function call to be performed by one or more software programs, such as kernels to be performed by one or more parallel processing units (PPUs), such as graphics processing units (GPUs). In at least one embodiment, invocation 1102 is an invocation of an instruction to cause one or more processors to perform one or more computational operations 1122, 1124 of an empty graph node response 1120 (“response 1120”). In at least one embodiment, invocation 1102 is an invocation of an API to cause one or more processors to perform one or more computational operations 1122, 1124 of response 1120.

[0185] In at least one embodiment, invocation 1102 receives, when invoked, one or more parameters 1104, 1106, 1108, 1110, 1112, 1114, 1116, to indicate information about computational operations to be performed. In at least one embodiment, invocation 1102 receives, when invoked, one or more parameters 1104, 1106, 1108, 1110, 1112, 1114, 1116 to indicate information about instructions to be performed.

[0186] In at least one embodiment, invocation 1102 receives, as input, parameters 1104, 1106, 1108, 1110, 1112, 1114, 1116 comprising a node pointer 1104. In at least one embodiment, node pointer 1104 is data comprising information indicating one or more nodes to be created by operation 1100. In at least one embodiment, node pointer 1104 is a pointer to an address corresponding to one or more nodes to be created by operation 1100. In at least one embodiment, node pointer 1104 is data to be input to a function call, if said function call is to perform invocation 1102. In at least one embodiment, node pointer 1104 is data to be input to an API, if said API is to cause invocation 1102 to be performed.

[0187] In at least one embodiment, invocation 1102 receives, as input, parameters 1104, 1106, 1108, 1110, 1112, 1114, 1116 comprising a graph 1106. In at least one embodiment, graph 1106 is data comprising information indicating one or more attributes of a graph, such as nodes, edges, dependencies, and/or any other suitable attribute. In at least one embodiment, graph 1106 is associated with an instantiated graph that is evaluated to be generated and/or executed, as described above in conjunction with FIG. 1, and/or FIG. 2. In at least one embodiment, graph 1106 is data to be input to a function call, if said function call is to perform invocation 1102. In at least one embodiment, graph 1106 is data to be input to an API, if said API is to cause invocation 1102 to be performed.

[0188] In at least one embodiment, invocation 1102 receives, as input, parameters 1104, 1106, 1108, 1110, 1112, 1114, 1116 comprising a dependency pointer 1108. In at least one embodiment, dependency pointer 1108 is data comprising information indicating one or more dependencies between two or more nodes of a graph. In at least one embodiment, dependency pointer 1108 includes information corresponding to one or more dependencies between a node indicated by node pointer 1104 and one or more other nodes of graph 1106. In at least one embodiment, dependency pointer 1108 is data to be input to a function call, if said function call is to perform invocation 1102. In at least one embodiment, dependency pointer 1108 is data to be input to an API, if said API is to cause invocation 1102 to be performed.

[0189] In at least one embodiment, invocation 1102 receives, as input, parameters 1104, 1106, 1108, 1110, 1112, 1114, 1116 comprising edge information 1110. In at least one embodiment, edge information 1110 is data comprising information corresponding to one or more dependencies of graph 1106. In at least one embodiment, edge information 1110 includes information indicating one or more dependencies between a node associated with node pointer 1104 and one or more nodes of graph 1106. In at least one embodiment, edge information 1110 includes an indication of one or more of a source port, a destination port, and/or a dependency type, as described above in conjunction with FIG. 1, FIG. 3, FIG. 4, and/or FIG. 5. In at least one embodiment, edge information 1110 may be represented as an array, in which each element corresponds to an element of a parallel array associated with dependency pointer 1108. In at least one embodiment, edge information 1110 is data to be input to a function call, if said function call is to perform invocation 1102. In at least one embodiment, edge information 1110 is data to be input to an API, if said API is to cause invocation 1102 to be performed.

[0190] In at least one embodiment, invocation 1102 receives, as input, parameters 1104, 1106, 1108, 1110, 1112, 1114, 1116 comprising a number of dependencies 1112. In at least one embodiment, number of dependencies 1112 is data indicating a number, or quantity, of dependencies associated with a node of graph 1106 associated with node pointer 1104. In at least one embodiment, number of dependencies 1112 is data to be input to a function call, if said function call is to perform invocation 1102. In at least one embodiment, number of dependencies 1112 is data to be input to an API, if said API is to cause invocation 1102 to be performed.

[0191] In at least one embodiment, invocation 1102 receives, as input, parameters 1104, 1106, 1108, 1110, 1112, 1114, 1116 comprising one or more semaphore parameters 1114. In at least one embodiment, semaphore parameters 1114 is data associated with one or more external semaphore signal corresponding to a node of graph 1106 associated with node pointer 1104. In at least one embodiment, semaphore parameters 1114 include an array of semaphore identifiers and/or handles. In at least one embodiment, semaphore parameters 1114 include an indication of a number of associated handles and/or parameters. In at least one embodiment, semaphore parameters 1114 include an array of semaphore parameters. In at least one embodiment, semaphore parameters 1114 is data to be input to a function call, if said function call is to perform invocation 1102. In at least one embodiment, semaphore parameters 1114 is data to be input to an API, if said API is to cause invocation 1102 to be performed.

[0192] In at least one embodiment, invocation 1102 receives, as input, parameters 1104, 1106, 1108, 1110, 1112, 1114, 1116 comprising other parameter(s) 1116. In at least one embodiment, other parameter(s) 1116 are data comprising any other information usable by operation 1100. In at least one embodiment, other parameter(s) 1116 are data to be input to a function call, if said function call is to perform invocation 1102. In at least one embodiment, other parameter(s) 1116 are data to be input to an API, if said API is to cause invocation 1102 to be performed.

[0193] In at least one embodiment, an example instruction indicating operation 1100 in a parallel computing environment, such as compute uniform device architecture (CUDA), is as follows:

[0194] cudaGraphAddExternalSemaphoresWaitNode (pGraphNode, graph, pDependencies, pDependencyData, numDependencies, nodeParams) where pGraphNode corresponds to node pointer 1104, graph corresponds to graph 1106, pDependencies corresponds to dependency pointer 1108, pDependencyData corresponds to edge information 1110, and numDependencies corresponds to number of dependencies 1112, and nodeParams corresponds to semaphore parameters 1114.

[0195] In at least one embodiment, response 1120 generates, as output, parameters 1122, 1124 comprising a status 1122. In at least one embodiment, status 1122 is data comprising any other information presented by operation 1100. In at least one embodiment, status 1122 is data to be output in response to a function call, if said function call is to perform invocation 1102. In at least one embodiment, status 1122 is data to be output by an API, if said API is to cause invocation 1102 to be performed. In at least one embodiment, status 1122 indicates that operation 1100 was performed successfully. In at least one embodiment, status 1122 indicates that operation 1100 was not performed successfully, or otherwise failed.

[0196] In at least one embodiment, response 1120 generates, as output, parameters 1122, 1124 comprising node 1124. In at least one embodiment, node 1124 is data to one or more nodes generated by operation 1100, using information associated with invocation 1102, such as parameters 1104, 1106, 1108, 1110, 1112, 1114, 1116. In at least one embodiment, node 1124 will be output by response 1120 to an address corresponding to node pointer 1104, such that node 1124 will be generated by storing data to an address indicated by node pointer 1104. In at least one embodiment, node 1124 is data to be output in response to a function call, if said function call is to perform invocation 1102. In at least one embodiment, node 1124 is data to be output by an API, if said API is to cause invocation 1102 to be performed. In at least one embodiment, node 1124 is provided to data structure, memory, and/or variable indicated by node pointer 1104. In at least one embodiment, node 1124 is presented in response to performance of one or more API and/or function calls.

[0197] FIG. 12 is a block diagram illustrating a host node operation 1200 (“operation 1200”), in accordance with at least one embodiment. In at least one embodiment, operation 1200 is one or more computational operations that, if performed, cause a node to be generated and/or added to a graph, as described above in conjunction with FIG. 1. In at least one embodiment, operation 1200 is to cause a host node to be added to a software graph based, at least in part, on a dependency type. In at least one embodiment, operation 1200 is to cause a host node to be generated and/or added to a graph. In at least one embodiment, a host node, when executed, invokes one or more processor functions, for example, using a CPU. In at least one embodiment, operation 1200 is a set of instructions that, if performed, cause one or more processors to cause one or more APIs to be performed.

[0198] In at least one embodiment, a host node invocation 1202 (“invocation 1202”) is a function call to be performed by one or more software programs, such as kernels to be performed by one or more parallel processing units (PPUs), such as graphics processing units (GPUs). In at least one embodiment, invocation 1202 is an invocation of an instruction to cause one or more processors to perform one or more computational operations 1222, 1224 of a host node response 1220 (“response 1220”). In at least one embodiment, invocation 1202 is an invocation of an API to cause one or more processors to perform one or more computational operations 1222, 1224 of response 1220.

[0199] In at least one embodiment, invocation 1202 receives, when invoked, one or more parameters 1204, 1206, 1208, 1210, 1212, 1214, 1216, to indicate information about computational operations to be performed. In at least one embodiment, invocation 1202 receives, when invoked, one or more parameters 1204, 1206, 1208, 1210, 1212, 1214, 1216 to indicate information about instructions to be performed.

[0200] In at least one embodiment, invocation 1202 receives, as input, parameters 1204, 1206, 1208, 1210, 1212, 1214, 1216 comprising a node pointer 1204. In at least one embodiment, node pointer 1204 is data comprising information indicating one or more nodes to be created by operation 1200. In at least one embodiment, node pointer 1204 is a pointer to an address corresponding to one or more nodes to be created by operation 1200. In at least one embodiment, node pointer 1204 is data to be input to a function call, if said function call is to perform invocation 1202. In at least one embodiment, node pointer 1204 is data to be input to an API, if said API is to cause invocation 1202 to be performed.

[0201] In at least one embodiment, invocation 1202 receives, as input, parameters 1204, 1206, 1208, 1210, 1212, 1214, 1216 comprising a graph 1206. In at least one embodiment, graph 1206 is data comprising information indicating one or more attributes of a graph, such as nodes, edges, dependencies, and/or any other suitable attribute. In at least one embodiment, graph 1206 is associated with an instantiated graph that is evaluated to be generated and/or executed, as described above in conjunction with FIG. 1, and/or FIG. 2. In at least one embodiment, graph 1206 is data to be input to a function call, if said function call is to perform invocation 1202. In at least one embodiment, graph 1206 is data to be input to an API, if said API is to cause invocation 1202 to be performed.

[0202] In at least one embodiment, invocation 1202 receives, as input, parameters 1204, 1206, 1208, 1210, 1212, 1214, 1216 comprising a dependency pointer 1208. In at least one embodiment, dependency pointer 1208 is data comprising information indicating one or more dependencies between two or more nodes of a graph. In at least one embodiment, dependency pointer 1208 includes information corresponding to one or more dependencies between a node indicated by node pointer 1204 and one or more other nodes of graph 1206. In at least one embodiment, dependency pointer 1208 is data to be input to a function call, if said function call is to perform invocation 1202. In at least one embodiment, dependency pointer 1208 is data to be input to an API, if said API is to cause invocation 1202 to be performed.

[0203] In at least one embodiment, invocation 1202 receives, as input, parameters 1204, 1206, 1208, 1210, 1212, 1214, 1216 comprising edge information 1210. In at least one embodiment, edge information 1210 is data comprising information corresponding to one or more dependencies of graph 1206. In at least one embodiment, edge information 1210 includes information indicating one or more dependencies between a node associated with node pointer 1204 and one or more nodes of graph 1206. In at least one embodiment, edge information 1210 includes an indication of one or more of a source port, a destination port, and/or a dependency type, as described above in conjunction with FIG. 1, FIG. 3, FIG. 4, and/or FIG. 5. In at least one embodiment, edge information 1210 may be represented as an array, in which each element corresponds to an element of a parallel array associated with dependency pointer 1208. In at least one embodiment, edge information 1210 is data to be input to a function call, if said function call is to perform invocation 1202. In at least one embodiment, edge information 1210 is data to be input to an API, if said API is to cause invocation 1202 to be performed.

[0204] In at least one embodiment, invocation 1202 receives, as input, parameters 1204, 1206, 1208, 1210, 1212, 1214, 1216 comprising a number of dependencies 1212. In at least one embodiment, number of dependencies 1212 is data indicating a number, or quantity, of dependencies associated with a node of graph 1206 associated with node pointer 1204. In at least one embodiment, number of dependencies 1212 is data to be input to a function call, if said function call is to perform invocation 1202. In at least one embodiment, number of dependencies 1212 is data to be input to an API, if said API is to cause invocation 1202 to be performed.

[0205] In at least one embodiment, invocation 1202 receives, as input, parameters 1204, 1206, 1208, 1210, 1212, 1214, 1216 comprising one or more host parameters 1214. In at least one embodiment, host parameters 1214 is data associated with one or more processors corresponding to a node of graph 1206 associated with node pointer 1204. In at least one embodiment, host parameters 1214 include one or more identifiers of one or more functions to be called when a node of graph 1206 associated with node pointer 1204 executes. In at least one embodiment, host parameters 1214 include one or more identifiers of one or more instructions to be performed when a node of graph 1206 associated with node pointer 1204 executes. In at least one embodiment, host parameters 1214 include one or more arguments, variable, and/or parameters to provide to one or more instructions and/or functions to be performed when a node of graph 1206 associated with node pointer 1204 executes. In at least one embodiment, host parameters 1214 is data to be input to a function call, if said function call is to perform invocation 1202. In at least one embodiment, host parameters 1214 is data to be input to an API, if said API is to cause invocation 1202 to be performed.

[0206] In at least one embodiment, invocation 1202 receives, as input, parameters 1204, 1206, 1208, 1210, 1212, 1214, 1216 comprising other parameter(s) 1216. In at least one embodiment, other parameter(s) 1216 are data comprising any other information usable by operation 1200. In at least one embodiment, other parameter(s) 1216 are data to be input to a function call, if said function call is to perform invocation 1202. In at least one embodiment, other parameter(s) 1216 are data to be input to an API, if said API is to cause invocation 1202 to be performed.

[0207] In at least one embodiment, an example instruction indicating operation 1200 in a parallel computing environment, such as compute uniform device architecture (CUDA), is as follows:

[0208] cudaGraphAddHostNode (pGraphNode, graph, pDependencies, pDependencyData, numDependencies, nodeParams) where pGraphNode corresponds to node pointer 1204, graph corresponds to graph 1206, pDependencies corresponds to dependency pointer 1208, pDependencyData corresponds to edge information 1210, and numDependencies corresponds to number of dependencies 1212, and nodeParams corresponds to host parameters 1214.

[0209] In at least one embodiment, response 1220 generates, as output, parameters 1222, 1224 comprising a status 1222. In at least one embodiment, status 1222 is data comprising any other information presented by operation 1200. In at least one embodiment, status 1222 is data to be output in response to a function call, if said function call is to perform invocation 1202. In at least one embodiment, status 1222 is data to be output by an API, if said API is to cause invocation 1202 to be performed. In at least one embodiment, status 1222 indicates that operation 1200 was performed successfully. In at least one embodiment, status 1222 indicates that operation 1200 was not performed successfully, or otherwise failed.

[0210] In at least one embodiment, response 1220 generates, as output, parameters 1222, 1224 comprising node 1224. In at least one embodiment, node 1224 is data to one or more nodes generated by operation 1200, using information associated with invocation 1202, such as parameters 1204, 1206, 1208, 1210, 1212, 1214, 1216. In at least one embodiment, node 1224 will be output by response 1220 to an address corresponding to node pointer 1204, such that node 1224 will be generated by storing data to an address indicated by node pointer 1204. In at least one embodiment, node 1224 is data to be output in response to a function call, if said function call is to perform invocation 1202. In at least one embodiment, node 1224 is data to be output by an API, if said API is to cause invocation 1202 to be performed. In at least one embodiment, node 1224 is provided to data structure, memory, and/or variable indicated by node pointer 1204. In at least one embodiment, node 1224 is presented in response to performance of one or more API and/or function calls.

[0211] FIG. 13 is a block diagram illustrating a graph node operation 1300 (“operation 1300”), in accordance with at least one embodiment. In at least one embodiment, an operation 1300 is one or more computational operations that, if performed, cause a node to be generated and/or added to a graph, as described above in conjunction with FIG. 1. In at least one embodiment, operation 1300 is to indicate one or more graph node functions of one or more graph nodes to be added to a software graph based, at least in part, on a dependency type indicated by the API. In at least one embodiment, a node type is determined based, at least in part, on node parameters 1314. In at least one embodiment, operation 1300 is to cause a node, to be generated and/or added to a graph. In at least one embodiment, operation 1300 is a set of instructions that, if performed, cause one or more processors to cause one or more APIs to be performed.

[0212] In at least one embodiment, a graph node invocation 1302 (“invocation 1302”) is a function call to be performed by one or more software programs, such as kernels to be performed by one or more parallel processing units (PPUs), such as graphics processing units (GPUs). In at least one embodiment, invocation 1302 is an invocation of an instruction to cause one or more processors to perform one or more computational operations 1322, 1324 of a graph node response 1320 (“response 1320”). In at least one embodiment, invocation 1302 is an invocation of an API to cause one or more processors to perform one or more computational operations 1322, 1324 of response 1320.

[0213] In at least one embodiment, invocation 1302 receives, when invoked, one or more parameters 1304, 1306, 1308, 1310, 1312, 1314, 1316, to indicate information about computational operations to be performed. In at least one embodiment, invocation 1302 receives, when invoked, one or more parameters 1304, 1306, 1308, 1310, 1312, 1314, 1316 to indicate information about instructions to be performed.

[0214] In at least one embodiment, invocation 1302 receives, as input, parameters 1304, 1306, 1308, 1310, 1312, 1314, 1316 comprising a node pointer 1304. In at least one embodiment, node pointer 1304 is data comprising information indicating one or more nodes to be created by operation 1300. In at least one embodiment, node pointer 1304 is a pointer to an address corresponding to one or more nodes to be created by operation 1300. In at least one embodiment, node pointer 1304 is data to be input to a function call, if said function call is to perform invocation 1302. In at least one embodiment, node pointer 1304 is data to be input to an API, if said API is to cause invocation 1302 to be performed.

[0215] In at least one embodiment, invocation 1302 receives, as input, parameters 1304, 1306, 1308, 1310, 1312, 1314, 1316 comprising a graph 1306. In at least one embodiment, graph 1306 is data comprising information indicating one or more attributes of a graph, such as nodes, edges, dependencies, and/or any other suitable attribute. In at least one embodiment, graph 1306 is associated with an instantiated graph that is evaluated to be generated and/or executed, as described above in conjunction with FIG. 1, and/or FIG. 2. In at least one embodiment, graph 1306 is data to be input to a function call, if said function call is to perform invocation 1302. In at least one embodiment, graph 1306 is data to be input to an API, if said API is to cause invocation 1302 to be performed.

[0216] In at least one embodiment, invocation 1302 receives, as input, parameters 1304, 1306, 1308, 1310, 1312, 1314, 1316 comprising a dependency pointer 1308. In at least one embodiment, dependency pointer 1308 is data comprising information indicating one or more dependencies between two or more nodes of a graph. In at least one embodiment, dependency pointer 1308 includes information corresponding to one or more dependencies between a node indicated by node pointer 1304 and one or more other nodes of graph 1304. In at least one embodiment, dependency pointer 1308 is data to be input to a function call, if said function call is to perform invocation 1302. In at least one embodiment, dependency pointer 1308 is data to be input to an API, if said API is to cause invocation 1302 to be performed.

[0217] In at least one embodiment, invocation 1302 receives, as input, parameters 1304, 1306, 1308, 1310, 1312, 1314, 1316 comprising edge information 1310. In at least one embodiment, edge information 1310 is data comprising information corresponding to one or more dependencies of graph 1306. In at least one embodiment, edge information 1310 includes information indicating one or more dependencies between a node associated with node pointer 1304 and one or more nodes of graph 1306. In at least one embodiment, edge information 1310 includes an indication of one or more of a source port, a destination port, and/or a dependency type, as described above in conjunction with FIG. 1. In at least one embodiment, edge information 1310 may be represented as an array, in which each element corresponds to an element of a parallel array associated with dependency pointer 1308. In at least one embodiment, edge information 1310 is data to be input to a function call, if said function call is to perform invocation 1302. In at least one embodiment, edge information 1310 is data to be input to an API, if said API is to cause invocation 1302 to be performed.

[0218] In at least one embodiment, invocation 1302 receives, as input, parameters 1304, 1306, 1308, 1310, 1312, 1314, 1316 comprising a number of dependencies 1312. In at least one embodiment, number of dependencies 1312 is data indicating a number, or quantity, of dependencies associated with a node of graph 1306 associated with node pointer 1304. In at least one embodiment, number of dependencies 1312 is data to be input to a function call, if said function call is to perform invocation 1302. In at least one embodiment, number of dependencies 1312 is data to be input to an API, if said API is to cause invocation 1302 to be performed.

[0219] In at least one embodiment, invocation 1302 receives, as input, parameters 1304, 1306, 1308, 1310, 1312, 1314, 1316 comprising one or more node parameters 1314. In at least one embodiment, node parameters 1314 includes a data structure comprising information indicating one or more attributes of a node to be added into graph 1306 associated with node pointer 1304, such as node type, dimensions, function name, arguments, memory instructions, memory addresses, and/or any other suitable attribute. In at least one embodiment, invocation 1302 is to add a node (indicated by node pointer 1304) to graph 1306, based on a node type indicated by node parameters 1314. In at least one embodiment, node parameters 1314 include data to be input to a function call, if said function call is to perform invocation 1302. In at least one embodiment, node parameters 1314 includes data to be input to an API, if said API is to cause invocation 1302 to be performed.

[0220] In at least one embodiment, invocation 1302 receives, as input, parameters 1304, 1306, 1308, 1310, 1312, 1314, 1316 comprising other parameter(s) 1316. In at least one embodiment, other parameter(s) 1316 are data comprising any other information usable by operation 1300. In at least one embodiment, other parameter(s) 1316 are data to be input to a function call, if said function call is to perform invocation 1302. In at least one embodiment, other parameter(s) 1316 are data to be input to an API, if said API is to cause invocation 1302 to be performed.

[0221] In at least one embodiment, an example instruction indicating operation 1300 in a parallel computing environment, such as compute uniform device architecture (CUDA), is as follows:

[0222] cudaGraphAddNode (pGraphNode, graph, pDependencies, pDependencyData, numDependencies, params) where pGraphNode corresponds to node pointer 1304, graph corresponds to graph 1306, pDependencies corresponds to dependency pointer 1308, pDependencyData corresponds to edge information 1310, numDependencies corresponds to number of dependencies 1312, and params corresponds to node parameters 1314.

[0223] In at least one embodiment, response 1320 generates, as output, parameters 1322, 1324 comprising a status 1322. In at least one embodiment, status 1322 is data comprising any other information presented by operation 1300. In at least one embodiment, status 1322 is data to be output in response to a function call, if said function call is to perform invocation 1302. In at least one embodiment, status 1322 is data to be output by an API, if said API is to cause invocation 1302 to be performed. In at least one embodiment, status 1322 indicates that operation 1300 was performed successfully. In at least one embodiment, status 1322 indicates that operation 1300 was not performed successfully, or otherwise failed.

[0224] In at least one embodiment, response 1320 generates, as output, parameters 1322, 1324 comprising node 1324. In at least one embodiment, node 1324 is data to one or more nodes generated by operation 1300, using information associated with invocation 1302, such as parameters 1304, 1306, 1308, 1310, 1312, 1314, 1316. In at least one embodiment, node 1324 will be output by response 1320 to an address corresponding to node pointer 1304, such that node 1324 will be generated by storing data to an address indicated by node pointer 1304. In at least one embodiment, node 1324 is data to be output in response to a function call, if said function call is to perform invocation 1302. In at least one embodiment, node 1324 is data to be output by an API, if said API is to cause invocation 1302 to be performed. In at least one embodiment, node 1324 is provided to data structure, memory, and/or variable indicated by node pointer 1304. In at least one embodiment, node 1324 is presented in response to performance of one or more API and/or function calls.

[0225] FIG. 14 is a block diagram illustrating a memory allocation operation 1400 (“operation 1400”), in accordance with at least one embodiment. In at least one embodiment, operation 1400 is one or more computational operations that, if performed, cause a node to be generated and/or added to a graph, as described above in conjunction with FIG. 1. In at least one embodiment, operation 1400 is to cause a memory allocation node to be added to a software graph based, at least in part, on a dependency type. In at least one embodiment, operation 1400 is to cause a memory allocation node to be generated and/or added to a graph. In at least one embodiment, a memory allocation node, when executed, causes one or more portions of memory to be allocated. In at least one embodiment, allocated memory may be freed or otherwise release by one or more operations of a graph. In at least one embodiment, operation 1400 is a set of instructions that, if performed, cause one or more processors to cause one or more APIs to be performed.

[0226] In at least one embodiment, memory allocation node invocation 1402 (“invocation 1402”) is a function call to be performed by one or more software programs, such as kernels to be performed by one or more parallel processing units (PPUs), such as graphics processing units (GPUs). In at least one embodiment, invocation 1402 is an invocation of an instruction to cause one or more processors to perform one or more computational operations 1422, 1424 of memory allocation node response 1420 (“response 1420”). In at least one embodiment, invocation 1402 is an invocation of an API to cause one or more processors to perform one or more computational operations 1422, 1424 of response 1420.

[0227] In at least one embodiment, invocation 1402 receives, when invoked, one or more parameters 1404, 1406, 1408, 1410, 1412, 1414, 1416, to indicate information about computational operations to be performed. In at least one embodiment, invocation 1402 receives, when invoked, one or more parameters 1404, 1406, 1408, 1410, 1412, 1414, 1416 to indicate information about instructions to be performed.

[0228] In at least one embodiment, invocation 1402 receives, as input, parameters 1404, 1406, 1408, 1410, 1412, 1414, 1416 comprising a node pointer 1404. In at least one embodiment, node pointer 1404 is data comprising information indicating one or more nodes to be created by operation 1400. In at least one embodiment, node pointer 1404 is a pointer to an address corresponding to one or more nodes to be created by operation 1400. In at least one embodiment, node pointer 1404 is data to be input to a function call, if said function call is to perform invocation 1402. In at least one embodiment, node pointer 1404 is data to be input to an API, if said API is to cause invocation 1402 to be performed.

[0229] In at least one embodiment, invocation 1402 receives, as input, parameters 1404, 1406, 1408, 1410, 1412, 1414, 1416 comprising a graph 1406. In at least one embodiment, graph 1406 is data comprising information indicating one or more attributes of a graph, such as nodes, edges, dependencies, and/or any other suitable attribute. In at least one embodiment, graph 1406 is associated with an instantiated graph that is evaluated to be generated and/or executed, as described above in conjunction with FIG. 1, and/or FIG. 2. In at least one embodiment, graph 1406 is data to be input to a function call, if said function call is to perform invocation 1402. In at least one embodiment, graph 1406 is data to be input to an API, if said API is to cause invocation 1402 to be performed.

[0230] In at least one embodiment, invocation 1402 receives, as input, parameters 1404, 1406, 1408, 1410, 1412, 1414, 1416 comprising a dependency pointer 1408. In at least one embodiment, dependency pointer 1408 is data comprising information indicating one or more dependencies between two or more nodes of a graph. In at least one embodiment, dependency pointer 1408 includes information corresponding to one or more dependencies between a node indicated by node pointer 1404 and one or more other nodes of graph 1406. In at least one embodiment, dependency pointer 1408 is data to be input to a function call, if said function call is to perform invocation 1402. In at least one embodiment, dependency pointer 1408 is data to be input to an API, if said API is to cause invocation 1402 to be performed.

[0231] In at least one embodiment, invocation 1402 receives, as input, parameters 1404, 1406, 1408, 1410, 1412, 1414, 1416 comprising edge information 1410. In at least one embodiment, edge information 1410 is data comprising information corresponding to one or more dependencies of graph 1406. In at least one embodiment, edge information 1410 includes information indicating one or more dependencies between a node associated with node pointer 1404 and one or more nodes of graph 1406. In at least one embodiment, edge information 1410 includes an indication of one or more of a source port, a destination port, and/or a dependency type, as described above in conjunction with FIG. 1, FIG. 3, FIG. 4, and/or FIG. 5. In at least one embodiment, edge information 1410 may be represented as an array, in which each element corresponds to an element of a parallel array associated with dependency pointer 1408. In at least one embodiment, edge information 1410 is data to be input to a function call, if said function call is to perform invocation 1402. In at least one embodiment, edge information 1410 is data to be input to an API, if said API is to cause invocation 1402 to be performed.

[0232] In at least one embodiment, invocation 1402 receives, as input, parameters 1404, 1406, 1408, 1410, 1412, 1414, 1416 comprising a number of dependencies 1412. In at least one embodiment, number of dependencies 1412 is data indicating a number, or quantity, of dependencies associated with a node of graph 1406 associated with node pointer 1404. In at least one embodiment, number of dependencies 1412 is data to be input to a function call, if said function call is to perform invocation 1402. In at least one embodiment, number of dependencies 1412 is data to be input to an API, if said API is to cause invocation 1402 to be performed.

[0233] In at least one embodiment, invocation 1402 receives, as input, parameters 1404, 1406, 1408, 1410, 1412, 1414, 1416 comprising one or more memory parameters 1414. In at least one embodiment, memory parameters 1414 is data associated with one or more memory allocation operations corresponding to a node of graph 1406 associated with node pointer 1404. In at least one embodiment, memory parameters 1414 include an indication of a number of memory access descriptors. In at least one embodiment, memory parameters 1414 include an indication of a size of a portion of requested memory to allocate. In at least one embodiment, memory parameters 1414 include an indication of a one or more memory addresses corresponding to one or more portions of memory being allocated. In at least one embodiment, memory parameters 1414 is data to be input to a function call, if said function call is to perform invocation 1402. In at least one embodiment, memory parameters 1414 is data to be input to an API, if said API is to cause invocation 1402 to be performed.

[0234] In at least one embodiment, invocation 1402 receives, as input, parameters 1404, 1406, 1408, 1410, 1412, 1414, 1416 comprising other parameter(s) 1416. In at least one embodiment, other parameter(s) 1416 are data comprising any other information usable by operation 1400. In at least one embodiment, other parameter(s) 1416 are data to be input to a function call, if said function call is to perform invocation 1402. In at least one embodiment, other parameter(s) 1416 are data to be input to an API, if said API is to cause invocation 1402 to be performed.

[0235] In at least one embodiment, an example instruction indicating operation 1400 in a parallel computing environment, such as compute uniform device architecture (CUDA), is as follows:

[0236] cudaGraphAddMemAllocNode (pGraphNode, graph, pDependencies, pDependencyData, numDependencies, nodeParams) where pGraphNode corresponds to node pointer 1404, graph corresponds to graph 1406, pDependencies corresponds to dependency pointer 1408, pDependencyData corresponds to edge information 1410, and numDependencies corresponds to number of dependencies 1412, and nodeParams corresponds to memory parameters 1414.

[0237] In at least one embodiment, response 1420 generates, as output, parameters 1422, 1424 comprising a status 1422. In at least one embodiment, status 1422 is data comprising any other information presented by operation 1400. In at least one embodiment, status 1422 is data to be output in response to a function call, if said function call is to perform invocation 1402. In at least one embodiment, status 1422 is data to be output by an API, if said API is to cause invocation 1402 to be performed. In at least one embodiment, status 1422 indicates that operation 1400 was performed successfully. In at least one embodiment, status 1422 indicates that operation 1400 was not performed successfully, or otherwise failed.

[0238] In at least one embodiment, response 1420 generates, as output, parameters 1422, 1424 comprising node 1424. In at least one embodiment, node 1424 is data to one or more nodes generated by operation 1400, using information associated with invocation 1402, such as parameters 1404, 1406, 1408, 1410, 1412, 1414, 1416. In at least one embodiment, node 1424 will be output by response 1420 to an address corresponding to node pointer 1404, such that node 1424 will be generated by storing data to an address indicated by node pointer 1404. In at least one embodiment, node 1424 is data to be output in response to a function call, if said function call is to perform invocation 1402. In at least one embodiment, node 1424 is data to be output by an API, if said API is to cause invocation 1402 to be performed. In at least one embodiment, node 1424 is provided to data structure, memory, and/or variable indicated by node pointer 1404. In at least one embodiment, node 1424 is presented in response to performance of one or more API and/or function calls.

[0239] FIG. 15 is a block diagram illustrating a memory free operation 1500 (“operation 1500”), in accordance with at least one embodiment. In at least one embodiment, operation 1500 is one or more computational operations that, if performed, cause a node to be generated and/or added to a graph, as described above in conjunction with FIG. 1. In at least one embodiment, operation 1500 is to cause a memory deallocation node to be added to a software graph based, at least in part, on a dependency type. In at least one embodiment, operation 1500 is to cause a memory free node to be generated and/or added to a graph. In at least one embodiment, a memory free node, when executed, causes one or more portions of memory to be freed, or otherwise released. In at least one embodiment, allocated memory may be freed or otherwise release by one or more operations of a graph. In at least one embodiment, operation 1500 is a set of instructions that, if performed, cause one or more processors to cause one or more APIs to be performed.

[0240] In at least one embodiment, memory free node invocation 1502 (“invocation 1502”) is a function call to be performed by one or more software programs, such as kernels to be performed by one or more parallel processing units (PPUs), such as graphics processing units (GPUs). In at least one embodiment, invocation 1502 is an invocation of an instruction to cause one or more processors to perform one or more computational operations 1522, 1524 of memory free node response 1520 (“response 1520”). In at least one embodiment, invocation 1502 is an invocation of an API to cause one or more processors to perform one or more computational operations 1522, 1524 of response 1520.

[0241] In at least one embodiment, invocation 1502 receives, when invoked, one or more parameters 1504, 1506, 1508, 1510, 1512, 1514, 1516, to indicate information about computational operations to be performed. In at least one embodiment, invocation 1502 receives, when invoked, one or more parameters 1504, 1506, 1508, 1510, 1512, 1514, 1516 to indicate information about instructions to be performed.

[0242] In at least one embodiment, invocation 1502 receives, as input, parameters 1504, 1506, 1508, 1510, 1512, 1514, 1516 comprising a node pointer 1504. In at least one embodiment, node pointer 1504 is data comprising information indicating one or more nodes to be created by operation 1500. In at least one embodiment, node pointer 1504 is a pointer to an address corresponding to one or more nodes to be created by operation 1500. In at least one embodiment, node pointer 1504 is data to be input to a function call, if said function call is to perform invocation 1502. In at least one embodiment, node pointer 1504 is data to be input to an API, if said API is to cause invocation 1502 to be performed.

[0243] In at least one embodiment, invocation 1502 receives, as input, parameters 1504, 1506, 1508, 1510, 1512, 1514, 1516 comprising a graph 1506. In at least one embodiment, graph 1506 is data comprising information indicating one or more attributes of a graph, such as nodes, edges, dependencies, and/or any other suitable attribute. In at least one embodiment, graph 1506 is associated with an instantiated graph that is evaluated to be generated and/or executed, as described above in conjunction with FIG. 1, and/or FIG. 2. In at least one embodiment, graph 1506 is data to be input to a function call, if said function call is to perform invocation 1502. In at least one embodiment, graph 1506 is data to be input to an API, if said API is to cause invocation 1502 to be performed.

[0244] In at least one embodiment, invocation 1502 receives, as input, parameters 1504, 1506, 1508, 1510, 1512, 1514, 1516 comprising a dependency pointer 1508. In at least one embodiment, dependency pointer 1508 is data comprising information indicating one or more dependencies between two or more nodes of a graph. In at least one embodiment, dependency pointer 1508 includes information corresponding to one or more dependencies between a node indicated by node pointer 1504 and one or more other nodes of graph 1506. In at least one embodiment, dependency pointer 1508 is data to be input to a function call, if said function call is to perform invocation 1502. In at least one embodiment, dependency pointer 1508 is data to be input to an API, if said API is to cause invocation 1502 to be performed.

[0245] In at least one embodiment, invocation 1502 receives, as input, parameters 1504, 1506, 1508, 1510, 1512, 1514, 1516 comprising edge information 1510. In at least one embodiment, edge information 1510 is data comprising information corresponding to one or more dependencies of graph 1506. In at least one embodiment, edge information 1510 includes information indicating one or more dependencies between a node associated with node pointer 1504 and one or more nodes of graph 1506. In at least one embodiment, edge information 1510 includes an indication of one or more of a source port, a destination port, and/or a dependency type, as described above in conjunction with FIG. 1, FIG. 3, FIG. 4, and/or FIG. 5. In at least one embodiment, edge information 1510 may be represented as an array, in which each element corresponds to an element of a parallel array associated with dependency pointer 1508. In at least one embodiment, edge information 1510 is data to be input to a function call, if said function call is to perform invocation 1502. In at least one embodiment, edge information 1510 is data to be input to an API, if said API is to cause invocation 1502 to be performed.

[0246] In at least one embodiment, invocation 1502 receives, as input, parameters 1504, 1506, 1508, 1510, 1512, 1514, 1516 comprising a number of dependencies 1512. In at least one embodiment, number of dependencies 1512 is data indicating a number, or quantity, of dependencies associated with a node of graph 1506 associated with node pointer 1504. In at least one embodiment, number of dependencies 1512 is data to be input to a function call, if said function call is to perform invocation 1502. In at least one embodiment, number of dependencies 1512 is data to be input to an API, if said API is to cause invocation 1502 to be performed.

[0247] In at least one embodiment, invocation 1502 receives, as input, parameters 1504, 1506, 1508, 1510, 1512, 1514, 1516 comprising one or more memory addresses 1514. In at least one embodiment, memory addresses 1514 is data associated with one or more memory free operations corresponding to a node of graph 1506 associated with node pointer 1504. In at least one embodiment, memory parameters 1514 include an indication of one or more memory addresses corresponding to one or more portions of memory to be freed. In at least one embodiment, memory parameters 1514 is data to be input to a function call, if said function call is to perform invocation 1502. In at least one embodiment, memory parameters 1514 is data to be input to an API, if said API is to cause invocation 1502 to be performed.

[0248] In at least one embodiment, invocation 1502 receives, as input, parameters 1504, 1506, 1508, 1510, 1512, 1514, 1516 comprising other parameter(s) 1516. In at least one embodiment, other parameter(s) 1516 are data comprising any other information usable by operation 1500. In at least one embodiment, other parameter(s) 1516 are data to be input to a function call, if said function call is to perform invocation 1502. In at least one embodiment, other parameter(s) 1516 are data to be input to an API, if said API is to cause invocation 1502 to be performed.

[0249] In at least one embodiment, an example instruction indicating operation 1500 in a parallel computing environment, such as compute uniform device architecture (CUDA), is as follows:

[0250] cudaGraphAddMemFreeNode (pGraphNode, graph, pDependencies, pDependencyData, numDependencies, address) where pGraphNode corresponds to node pointer 1504, graph corresponds to graph 1506, pDependencies corresponds to dependency pointer 1508, pDependencyData corresponds to edge information 1510, and numDependencies corresponds to number of dependencies 1512, and address corresponds to memory addresses 1514.

[0251] In at least one embodiment, response 1520 generates, as output, parameters 1522, 1524 comprising a status 1522. In at least one embodiment, status 1522 is data comprising any other information presented by operation 1500. In at least one embodiment, status 1522 is data to be output in response to a function call, if said function call is to perform invocation 1502. In at least one embodiment, status 1522 is data to be output by an API, if said API is to cause invocation 1502 to be performed. In at least one embodiment, status 1522 indicates that operation 1500 was performed successfully. In at least one embodiment, status 1522 indicates that operation 1500 was not performed successfully, or otherwise failed.

[0252] In at least one embodiment, response 1520 generates, as output, parameters 1522, 1524 comprising node 1524. In at least one embodiment, node 1524 is data to one or more nodes generated by operation 1500, using information associated with invocation 1502, such as parameters 1504, 1506, 1508, 1510, 1512, 1514, 1516. In at least one embodiment, node 1524 will be output by response 1520 to an address corresponding to node pointer 1504, such that node 1524 will be generated by storing data to an address indicated by node pointer 1504. In at least one embodiment, node 1524 is data to be output in response to a function call, if said function call is to perform invocation 1502. In at least one embodiment, node 1524 is data to be output by an API, if said API is to cause invocation 1502 to be performed. In at least one embodiment, node 1524 is provided to data structure, memory, and/or variable indicated by node pointer 1504. In at least one embodiment, node 1524 is presented in response to performance of one or more API and/or function calls.

[0253] FIG. 16 is a block diagram illustrating a memory copy operation 1600 (“operation 1600”), in accordance with at least one embodiment. In at least one embodiment, operation 1600 is one or more computational operations that, if performed, cause a node to be generated and/or added to a graph, as described above in conjunction with FIG. 1. In at least one embodiment, operation 1600 is to cause a memory copy node to be added to a software graph based, at least in part, on a dependency type. In at least one embodiment, operation 1600 is to cause a memory copy node to be generated and/or added to a graph. In at least one embodiment, a memory copy node, when executed, causes one or more portions of memory to be duplicated, at least in part, to one or more other portions of memory. In at least one embodiment, operation 1600 is a set of instructions that, if performed, cause one or more processors to cause one or more APIs to be performed.

[0254] In at least one embodiment, memory copy node invocation 1602 (“invocation 1602”) is a function call to be performed by one or more software programs, such as kernels to be performed by one or more parallel processing units (PPUs), such as graphics processing units (GPUs). In at least one embodiment, invocation 1602 is an invocation of an instruction to cause one or more processors to perform one or more computational operations 1622, 1624 of memory copy node response 1620 (“response 1620”). In at least one embodiment, invocation 1602 is an invocation of an API to cause one or more processors to perform one or more computational operations 1622, 1624 of response 1620.

[0255] In at least one embodiment, invocation 1602 receives, when invoked, one or more parameters 1604, 1606, 1608, 1610, 1612, 1614, 1616, to indicate information about computational operations to be performed. In at least one embodiment, invocation 1602 receives, when invoked, one or more parameters 1604, 1606, 1608, 1610, 1612, 1614, 1616 to indicate information about instructions to be performed.

[0256] In at least one embodiment, invocation 1602 receives, as input, parameters 1604, 1606, 1608, 1610, 1612, 1614, 1616 comprising a node pointer 1604. In at least one embodiment, node pointer 1604 is data comprising information indicating one or more nodes to be created by operation 1600. In at least one embodiment, node pointer 1604 is a pointer to an address corresponding to one or more nodes to be created by operation 1600. In at least one embodiment, node pointer 1604 is data to be input to a function call, if said function call is to perform invocation 1602. In at least one embodiment, node pointer 1604 is data to be input to an API, if said API is to cause invocation 1602 to be performed.

[0257] In at least one embodiment, invocation 1602 receives, as input, parameters 1604, 1606, 1608, 1610, 1612, 1614, 1616 comprising a graph 1606. In at least one embodiment, graph 1606 is data comprising information indicating one or more attributes of a graph, such as nodes, edges, dependencies, and/or any other suitable attribute. In at least one embodiment, graph 1606 is associated with an instantiated graph that is evaluated to be generated and/or executed, as described above in conjunction with FIG. 1, and/or FIG. 2. In at least one embodiment, graph 1606 is data to be input to a function call, if said function call is to perform invocation 1602. In at least one embodiment, graph 1606 is data to be input to an API, if said API is to cause invocation 1602 to be performed.

[0258] In at least one embodiment, invocation 1602 receives, as input, parameters 1604, 1606, 1608, 1610, 1612, 1614, 1616 comprising a dependency pointer 1608. In at least one embodiment, dependency pointer 1608 is data comprising information indicating one or more dependencies between two or more nodes of a graph. In at least one embodiment, dependency pointer 1608 includes information corresponding to one or more dependencies between a node indicated by node pointer 1604 and one or more other nodes of graph 1606. In at least one embodiment, dependency pointer 1608 is data to be input to a function call, if said function call is to perform invocation 1602. In at least one embodiment, dependency pointer 1608 is data to be input to an API, if said API is to cause invocation 1602 to be performed.

[0259] In at least one embodiment, invocation 1602 receives, as input, parameters 1604, 1606, 1608, 1610, 1612, 1614, 1616 comprising edge information 1610. In at least one embodiment, edge information 1610 is data comprising information corresponding to one or more dependencies of graph 1606. In at least one embodiment, edge information 1610 includes information indicating one or more dependencies between a node associated with node pointer 1604 and one or more nodes of graph 1606. In at least one embodiment, edge information 1610 includes an indication of one or more of a source port, a destination port, and/or a dependency type, as described above in conjunction with FIG. 1, FIG. 3, FIG. 4, and/or FIG. 5. In at least one embodiment, edge information 1610 may be represented as an array, in which each element corresponds to an element of a parallel array associated with dependency pointer 1608. In at least one embodiment, edge information 1610 is data to be input to a function call, if said function call is to perform invocation 1602. In at least one embodiment, edge information 1610 is data to be input to an API, if said API is to cause invocation 1602 to be performed.

[0260] In at least one embodiment, invocation 1602 receives, as input, parameters 1604, 1606, 1608, 1610, 1612, 1614, 1616 comprising a number of dependencies 1612. In at least one embodiment, number of dependencies 1612 is data indicating a number, or quantity, of dependencies associated with a node of graph 1606 associated with node pointer 1604. In at least one embodiment, number of dependencies 1612 is data to be input to a function call, if said function call is to perform invocation 1602. In at least one embodiment, number of dependencies 1612 is data to be input to an API, if said API is to cause invocation 1602 to be performed.

[0261] In at least one embodiment, invocation 1602 receives, as input, parameters 1604, 1606, 1608, 1610, 1612, 1614, 1616 comprising one or more memory parameters 1614. In at least one embodiment, memory parameters 1614 is data associated with one or more memory allocation operations corresponding to a node of graph 1606 associated with node pointer 1604. In at least one embodiment, memory parameters 1614 include an indication of a destination memory address that a portion of memory is to be copied to. In at least one embodiment, memory parameters 1614 include an indication of a destination memory address offset that is used to offset an address that a portion of memory is to be copied to. In at least one embodiment, memory parameters 1614 include an indication of a pitched destination memory address that a portion of memory is to be copied to. In at least one embodiment, memory parameters 1614 include an indication of a memory copy size indicating a size of memory to be copied. In at least one embodiment, memory parameters 1614 include an indication of a type of transfer used to copy data from one portion of memory to another. In at least one embodiment, memory parameters 1614 include an indication of a source memory address that content of a portion of memory is to be copied from. In at least one embodiment, memory parameters 1614 include an indication of a source memory address offset that is used to offset an address that a portion of memory is to be copied from. In at least one embodiment, memory parameters 1614 include an indication of a pitched source memory address that a portion of memory is to be copied from. In at least one embodiment, memory parameters 1614 is data to be input to a function call, if said function call is to perform invocation 1602. In at least one embodiment, memory parameters 1614 is data to be input to an API, if said API is to cause invocation 1602 to be performed.

[0262] In at least one embodiment, invocation 1602 receives, as input, parameters 1604, 1606, 1608, 1610, 1612, 1614, 1616 comprising other parameter(s) 1616. In at least one embodiment, other parameter(s) 1616 are data comprising any other information usable by operation 1600. In at least one embodiment, other parameter(s) 1616 are data to be input to a function call, if said function call is to perform invocation 1602. In at least one embodiment, other parameter(s) 1616 are data to be input to an API, if said API is to cause invocation 1602 to be performed.

[0263] In at least one embodiment, an example instruction indicating operation 1600 in a parallel computing environment, such as compute uniform device architecture (CUDA), is as follows:

[0264] cudaGraphAddMemcpyNode (pGraphNode, graph, pDependencies, pDependencyData, numDependencies, pCopyParams) where pGraphNode corresponds to node pointer 1604, graph corresponds to graph 1606, pDependencies corresponds to dependency pointer 1608, pDependencyData corresponds to edge information 1610, and numDependencies corresponds to number of dependencies 1612, and pCopyParams corresponds to memory parameters 1614.

[0265] In at least one embodiment, response 1620 generates, as output, parameters 1622, 1624 comprising a status 1622. In at least one embodiment, status 1622 is data comprising any other information presented by operation 1600. In at least one embodiment, status 1622 is data to be output in response to a function call, if said function call is to perform invocation 1602. In at least one embodiment, status 1622 is data to be output by an API, if said API is to cause invocation 1602 to be performed. In at least one embodiment, status 1622 indicates that operation 1600 was performed successfully. In at least one embodiment, status 1622 indicates that operation 1600 was not performed successfully, or otherwise failed.

[0266] In at least one embodiment, response 1620 generates, as output, parameters 1622, 1624 comprising node 1624. In at least one embodiment, node 1624 is data to one or more nodes generated by operation 1600, using information associated with invocation 1602, such as parameters 1604, 1606, 1608, 1610, 1612, 1614, 1616. In at least one embodiment, node 1624 will be output by response 1620 to an address corresponding to node pointer 1604, such that node 1624 will be generated by storing data to an address indicated by node pointer 1604. In at least one embodiment, node 1624 is data to be output in response to a function call, if said function call is to perform invocation 1602. In at least one embodiment, node 1624 is data to be output by an API, if said API is to cause invocation 1602 to be performed. In at least one embodiment, node 1624 is provided to data structure, memory, and/or variable indicated by node pointer 1604. In at least one embodiment, node 1624 is presented in response to performance of one or more API and/or function calls.

[0267] FIG. 17 is a block diagram illustrating a one dimensional (“1D”) memory copy operation 1700 (“operation 1700”), in accordance with at least one embodiment. In at least one embodiment, operation 1700 is one or more computational operations that, if performed, cause a node to be generated and/or added to a graph, as described above in conjunction with FIG. 1. In at least one embodiment, operation 1700 is to cause an array storage node to be added to a software graph based, at least in part, on a dependency type. In at least one embodiment, operation 1700 is to cause a one dimensional memory copy node to be generated and/or added to a graph. In at least one embodiment, a one dimensional memory copy node, when executed, causes one or more portions of memory to be copied. In at least one embodiment, allocated memory may be freed or otherwise release by one or more operations of a graph. In at least one embodiment, operation 1700 is a set of instructions that, if performed, cause one or more processors to cause one or more APIs to be performed.

[0268] In at least one embodiment, memory 1D copy node invocation 1702 (“invocation 1702”) is a function call to be performed by one or more software programs, such as kernels to be performed by one or more parallel processing units (PPUs), such as graphics processing units (GPUs). In at least one embodiment, invocation 1702 is an invocation of an instruction to cause one or more processors to perform one or more computational operations 1722, 1724 of memory 1D copy node response 1720 (“response 1720”). In at least one embodiment, invocation 1702 is an invocation of an API to cause one or more processors to perform one or more computational operations 1722, 1724 of response 1720.

[0269] In at least one embodiment, invocation 1702 receives, when invoked, one or more parameters 1704, 1706, 1708, 1710, 1712, 1714, 1716, to indicate information about computational operations to be performed. In at least one embodiment, invocation 1702 receives, when invoked, one or more parameters 1704, 1706, 1708, 1710, 1712, 1714, 1716 to indicate information about instructions to be performed.

[0270] In at least one embodiment, invocation 1702 receives, as input, parameters 1704, 1706, 1708, 1710, 1712, 1714, 1716 comprising a node pointer 1704. In at least one embodiment, node pointer 1704 is data comprising information indicating one or more nodes to be created by operation 1700. In at least one embodiment, node pointer 1704 is a pointer to an address corresponding to one or more nodes to be created by operation 1700. In at least one embodiment, node pointer 1704 is data to be input to a function call, if said function call is to perform invocation 1702. In at least one embodiment, node pointer 1704 is data to be input to an API, if said API is to cause invocation 1702 to be performed.

[0271] In at least one embodiment, invocation 1702 receives, as input, parameters 1704, 1706, 1708, 1710, 1712, 1714, 1716 comprising a graph 1706. In at least one embodiment, graph 1706 is data comprising information indicating one or more attributes of a graph, such as nodes, edges, dependencies, and/or any other suitable attribute. In at least one embodiment, graph 1706 is associated with an instantiated graph that is evaluated to be generated and/or executed, as described above in conjunction with FIG. 1, and/or FIG. 2. In at least one embodiment, graph 1706 is data to be input to a function call, if said function call is to perform invocation 1702. In at least one embodiment, graph 1706 is data to be input to an API, if said API is to cause invocation 1702 to be performed.

[0272] In at least one embodiment, invocation 1702 receives, as input, parameters 1704, 1706, 1708, 1710, 1712, 1714, 1716 comprising a dependency pointer 1708. In at least one embodiment, dependency pointer 1708 is data comprising information indicating one or more dependencies between two or more nodes of a graph. In at least one embodiment, dependency pointer 1708 includes information corresponding to one or more dependencies between a node indicated by node pointer 1704 and one or more other nodes of graph 1706. In at least one embodiment, dependency pointer 1708 is data to be input to a function call, if said function call is to perform invocation 1702. In at least one embodiment, dependency pointer 1708 is data to be input to an API, if said API is to cause invocation 1702 to be performed.

[0273] In at least one embodiment, invocation 1702 receives, as input, parameters 1704, 1706, 1708, 1710, 1712, 1714, 1716 comprising edge information 1710. In at least one embodiment, edge information 1710 is data comprising information corresponding to one or more dependencies of graph 1706. In at least one embodiment, edge information 1710 includes information indicating one or more dependencies between a node associated with node pointer 1704 and one or more nodes of graph 1706. In at least one embodiment, edge information 1710 includes an indication of one or more of a source port, a destination port, and/or a dependency type, as described above in conjunction with FIG. 1, FIG. 3, FIG. 4, and/or FIG. 5. In at least one embodiment, edge information 1710 may be represented as an array, in which each element corresponds to an element of a parallel array associated with dependency pointer 1708. In at least one embodiment, edge information 1710 is data to be input to a function call, if said function call is to perform invocation 1702. In at least one embodiment, edge information 1710 is data to be input to an API, if said API is to cause invocation 1702 to be performed.

[0274] In at least one embodiment, invocation 1702 receives, as input, parameters 1704, 1706, 1708, 1710, 1712, 1714, 1716 comprising a number of dependencies 1712. In at least one embodiment, number of dependencies 1712 is data indicating a number, or quantity, of dependencies associated with a node of graph 1706 associated with node pointer 1704. In at least one embodiment, number of dependencies 1712 is data to be input to a function call, if said function call is to perform invocation 1702. In at least one embodiment, number of dependencies 1712 is data to be input to an API, if said API is to cause invocation 1702 to be performed.

[0275] In at least one embodiment, invocation 1702 receives, as input, parameters 1704, 1706, 1708, 1710, 1712, 1714, 1716 comprising one or more memory parameters 1714. In at least one embodiment, memory parameters 1714 is data associated with one or more memory 1D copy operations corresponding to a node of graph 1706 associated with node pointer 1704. In at least one embodiment, memory parameters 1714 include an indication of a destination memory address that a portion of memory is to be copied to. In at least one embodiment, memory parameters 1714 include an indication of a memory copy size indicating a size of memory to be copied. In at least one embodiment, memory parameters 1714 include an indication of a type of transfer used to copy data from one portion of memory to another. In at least one embodiment, memory parameters 1714 include an indication of a source memory address that content of a portion of memory is to be copied from. In at least one embodiment, memory parameters 1714 is data to be input to a function call, if said function call is to perform invocation 1702. In at least one embodiment, memory parameters 1714 is data to be input to an API, if said API is to cause invocation 1702 to be performed.

[0276] In at least one embodiment, invocation 1702 receives, as input, parameters 1704, 1706, 1708, 1710, 1712, 1714, 1716 comprising other parameter(s) 1716. In at least one embodiment, other parameter(s) 1716 are data comprising any other information usable by operation 1700. In at least one embodiment, other parameter(s) 1716 are data to be input to a function call, if said function call is to perform invocation 1702. In at least one embodiment, other parameter(s) 1716 are data to be input to an API, if said API is to cause invocation 1702 to be performed.

[0277] In at least one embodiment, an example instruction indicating operation 1700 in a parallel computing environment, such as compute uniform device architecture (CUDA), is as follows:

[0278] cudaGraphAddMemcpyNodeID (pGraphNode, graph, pDependencies, pDependencyData, numDependencies, nodeParams) where pGraphNode corresponds to node pointer 1704, graph corresponds to graph 1706, pDependencies corresponds to dependency pointer 1708, pDependencyData corresponds to edge information 1710, and numDependencies corresponds to number of dependencies 1712, and nodeParams corresponds to memory parameters 1714.

[0279] In at least one embodiment, response 1720 generates, as output, parameters 1722, 1724 comprising a status 1722. In at least one embodiment, status 1722 is data comprising any other information presented by operation 1700. In at least one embodiment, status 1722 is data to be output in response to a function call, if said function call is to perform invocation 1702. In at least one embodiment, status 1722 is data to be output by an API, if said API is to cause invocation 1702 to be performed. In at least one embodiment, status 1722 indicates that operation 1700 was performed successfully. In at least one embodiment, status 1722 indicates that operation 1700 was not performed successfully, or otherwise failed.

[0280] In at least one embodiment, response 1720 generates, as output, parameters 1722, 1724 comprising node 1724. In at least one embodiment, node 1724 is data to one or more nodes generated by operation 1700, using information associated with invocation 1702, such as parameters 1704, 1706, 1708, 1710, 1712, 1714, 1716. In at least one embodiment, node 1724 will be output by response 1720 to an address corresponding to node pointer 1704, such that node 1724 will be generated by storing data to an address indicated by node pointer 1704. In at least one embodiment, node 1724 is data to be output in response to a function call, if said function call is to perform invocation 1702. In at least one embodiment, node 1724 is data to be output by an API, if said API is to cause invocation 1702 to be performed. In at least one embodiment, node 1724 is provided to data structure, memory, and/or variable indicated by node pointer 1704. In at least one embodiment, node 1724 is presented in response to performance of one or more API and/or function calls.

[0281] FIG. 18 is a block diagram illustrating a memory copy from symbol operation 1800 (“operation 1800”), in accordance with at least one embodiment. In at least one embodiment, operation 1800 is one or more computational operations that, if performed, cause a node to be generated and/or added to a graph, as described above in conjunction with FIG. 1. In at least one embodiment, operation 1800 is to cause a symbol storage node to be added to a software graph based, at least in part, on a dependency type. In at least one embodiment, operation 1800 is to cause a memory copy from symbol node to be generated and/or added to a graph. In at least one embodiment, a memory copy from symbol node, when executed, causes one or more portions of memory to be copied in association to one or more symbols and/or variables. In at least one embodiment, operation 1800 is a set of instructions that, if performed, cause one or more processors to cause one or more APIs to be performed.

[0282] In at least one embodiment, memory copy from symbol node invocation 1802 (“invocation 1802”) is a function call to be performed by one or more software programs, such as kernels to be performed by one or more parallel processing units (PPUs), such as graphics processing units (GPUs). In at least one embodiment, invocation 1802 is an invocation of an instruction to cause one or more processors to perform one or more computational operations 1822, 1824 of memory copy from symbol node response 1820 (“response 1820”). In at least one embodiment, invocation 1802 is an invocation of an API to cause one or more processors to perform one or more computational operations 1822, 1824 of response 1820.

[0283] In at least one embodiment, invocation 1802 receives, when invoked, one or more parameters 1804, 1806, 1808, 1810, 1812, 1814, 1816, to indicate information about computational operations to be performed. In at least one embodiment, invocation 1802 receives, when invoked, one or more parameters 1804, 1806, 1808, 1810, 1812, 1814, 1816 to indicate information about instructions to be performed.

[0284] In at least one embodiment, invocation 1802 receives, as input, parameters 1804, 1806, 1808, 1810, 1812, 1814, 1816 comprising a node pointer 1804. In at least one embodiment, node pointer 1804 is data comprising information indicating one or more nodes to be created by operation 1800. In at least one embodiment, node pointer 1804 is a pointer to an address corresponding to one or more nodes to be created by operation 1800. In at least one embodiment, node pointer 1804 is data to be input to a function call, if said function call is to perform invocation 1802. In at least one embodiment, node pointer 1804 is data to be input to an API, if said API is to cause invocation 1802 to be performed.

[0285] In at least one embodiment, invocation 1802 receives, as input, parameters 1804, 1806, 1808, 1810, 1812, 1814, 1816 comprising a graph 1806. In at least one embodiment, graph 1806 is data comprising information indicating one or more attributes of a graph, such as nodes, edges, dependencies, and/or any other suitable attribute. In at least one embodiment, graph 1806 is associated with an instantiated graph that is evaluated to be generated and/or executed, as described above in conjunction with FIG. 1, and/or FIG. 2. In at least one embodiment, graph 1806 is data to be input to a function call, if said function call is to perform invocation 1802. In at least one embodiment, graph 1806 is data to be input to an API, if said API is to cause invocation 1802 to be performed.

[0286] In at least one embodiment, invocation 1802 receives, as input, parameters 1804, 1806, 1808, 1810, 1812, 1814, 1816 comprising a dependency pointer 1808. In at least one embodiment, dependency pointer 1808 is data comprising information indicating one or more dependencies between two or more nodes of a graph. In at least one embodiment, dependency pointer 1808 includes information corresponding to one or more dependencies between a node indicated by node pointer 1804 and one or more other nodes of graph 1806. In at least one embodiment, dependency pointer 1808 is data to be input to a function call, if said function call is to perform invocation 1802. In at least one embodiment, dependency pointer 1808 is data to be input to an API, if said API is to cause invocation 1802 to be performed.

[0287] In at least one embodiment, invocation 1802 receives, as input, parameters 1804, 1806, 1808, 1810, 1812, 1814, 1816 comprising edge information 1810. In at least one embodiment, edge information 1810 is data comprising information corresponding to one or more dependencies of graph 1806. In at least one embodiment, edge information 1810 includes information indicating one or more dependencies between a node associated with node pointer 1804 and one or more nodes of graph 1806. In at least one embodiment, edge information 1810 includes an indication of one or more of a source port, a destination port, and/or a dependency type, as described above in conjunction with FIG. 1, FIG. 3, FIG. 4, and/or FIG. 5. In at least one embodiment, edge information 1810 may be represented as an array, in which each element corresponds to an element of a parallel array associated with dependency pointer 1808. In at least one embodiment, edge information 1810 is data to be input to a function call, if said function call is to perform invocation 1802. In at least one embodiment, edge information 1810 is data to be input to an API, if said API is to cause invocation 1802 to be performed.

[0288] In at least one embodiment, invocation 1802 receives, as input, parameters 1804, 1806, 1808, 1810, 1812, 1814, 1816 comprising a number of dependencies 1812. In at least one embodiment, number of dependencies 1812 is data indicating a number, or quantity, of dependencies associated with a node of graph 1806 associated with node pointer 1804. In at least one embodiment, number of dependencies 1812 is data to be input to a function call, if said function call is to perform invocation 1802. In at least one embodiment, number of dependencies 1812 is data to be input to an API, if said API is to cause invocation 1802 to be performed.

[0289] In at least one embodiment, invocation 1802 receives, as input, parameters 1804, 1806, 1808, 1810, 1812, 1814, 1816 comprising one or more memory parameters 1814. In at least one embodiment, memory parameters 1814 is data associated with one or more memory allocation operations corresponding to a node of graph 1806 associated with node pointer 1804. In at least one embodiment, memory parameters 1814 include an indication of a number of memory access descriptors. In at least one embodiment, memory parameters 1814 include an indication of a size of a portion of requested memory to allocate. In at least one embodiment, memory parameters 1814 include an indication of a symbol from which data is to be copied from corresponding one or more portions of memory. In at least one embodiment, memory parameters 1814 include an indication of a one or more memory addresses corresponding to one or more portions of memory being allocated. In at least one embodiment, memory parameters 1814 is data to be input to a function call, if said function call is to perform invocation 1802. In at least one embodiment, memory parameters 1814 is data to be input to an API, if said API is to cause invocation 1802 to be performed.

[0290] In at least one embodiment, invocation 1802 receives, as input, parameters 1804, 1806, 1808, 1810, 1812, 1814, 1816 comprising other parameter(s) 1816. In at least one embodiment, other parameter(s) 1816 are data comprising any other information usable by operation 1800. In at least one embodiment, other parameter(s) 1816 are data to be input to a function call, if said function call is to perform invocation 1802. In at least one embodiment, other parameter(s) 1816 are data to be input to an API, if said API is to cause invocation 1802 to be performed.

[0291] In at least one embodiment, an example instruction indicating operation 1800 in a parallel computing environment, such as compute uniform device architecture (CUDA), is as follows:

[0292] cudaGraphAddMemcpyNodeFromSymbol (pGraphNode, graph, pDependencies, pDependencyData, numDependencies, nodeParams) where pGraphNode corresponds to node pointer 1804, graph corresponds to graph 1806, pDependencies corresponds to dependency pointer 1808, pDependencyData corresponds to edge information 1810, and numDependencies corresponds to number of dependencies 1812, and nodeParams corresponds to memory parameters 1814.

[0293] In at least one embodiment, response 1820 generates, as output, parameters 1822, 1824 comprising a status 1822. In at least one embodiment, status 1822 is data comprising any other information presented by operation 1800. In at least one embodiment, status 18224722 is data to be output in response to a function call, if said function call is to perform invocation 1802. In at least one embodiment, status 1822 is data to be output by an API, if said API is to cause invocation 1802 to be performed. In at least one embodiment, status 1822 indicates that operation 1800 was performed successfully. In at least one embodiment, status 1822 indicates that operation 1800 was not performed successfully, or otherwise failed.

[0294] In at least one embodiment, response 1820 generates, as output, parameters 1822, 1824 comprising node 1824. In at least one embodiment, node 1824 is data to one or more nodes generated by operation 1800, using information associated with invocation 1802, such as parameters 1804, 1806, 1808, 1810, 1812, 1814, 1816. In at least one embodiment, node 1824 will be output by response 1820 to an address corresponding to node pointer 1804, such that node 1824 will be generated by storing data to an address indicated by node pointer 1804. In at least one embodiment, node 1824 is data to be output in response to a function call, if said function call is to perform invocation 1802. In at least one embodiment, node 1824 is data to be output by an API, if said API is to cause invocation 1802 to be performed. In at least one embodiment, node 1824 is provided to data structure, memory, and/or variable indicated by node pointer 1804. In at least one embodiment, node 1824 is presented in response to performance of one or more API and/or function calls.

[0295] FIG. 19 is a block diagram illustrating a memory copy to symbol operation 1900 (“operation 1900”), in accordance with at least one embodiment. In at least one embodiment, operation 1900 is one or more computational operations that, if performed, cause a node to be generated and/or added to a graph, as described above in conjunction with FIG. 1. In at least one embodiment, operation 1900 is to cause a symbol load node to be added to a software graph based, at least in part, on a dependency type. In at least one embodiment, operation 1900 is to cause a memory copy to symbol node to be generated and/or added to a graph. In at least one embodiment, a memory copy to symbol node, when executed, causes one or more portions of memory to be copied to one or more portions of memory associated with one or more symbols and/or variables. In at least one embodiment, operation 1900 is a set of instructions that, if performed, cause one or more processors to cause one or more APIs to be performed.

[0296] In at least one embodiment, memory copy to symbol node invocation 1902 (“invocation 1902”) is a function call to be performed by one or more software programs, such as kernels to be performed by one or more parallel processing units (PPUs), such as graphics processing units (GPUs). In at least one embodiment, invocation 1902 is an invocation of an instruction to cause one or more processors to perform one or more computational operations 1922, 1924 of memory copy to symbol node response 1920 (“response 1920”). In at least one embodiment, invocation 1902 is an invocation of an API to cause one or more processors to perform one or more computational operations 1922, 1924 of response 1920.

[0297] In at least one embodiment, invocation 1902 receives, when invoked, one or more parameters 1904, 1906, 1908, 1910, 1912, 1914, 1916, to indicate information about computational operations to be performed. In at least one embodiment, invocation 1902 receives, when invoked, one or more parameters 1904, 1906, 1908, 1910, 1912, 1914, 1916 to indicate information about instructions to be performed.

[0298] In at least one embodiment, invocation 1902 receives, as input, parameters 1904, 1906, 1908, 1910, 1912, 1914, 1916 comprising a node pointer 1904. In at least one embodiment, node pointer 1904 is data comprising information indicating one or more nodes to be created by operation 1900. In at least one embodiment, node pointer 1904 is a pointer to an address corresponding to one or more nodes to be created by operation 1900. In at least one embodiment, node pointer 1904 is data to be input to a function call, if said function call is to perform invocation 1902. In at least one embodiment, node pointer 1904 is data to be input to an API, if said API is to cause invocation 1902 to be performed.

[0299] In at least one embodiment, invocation 1902 receives, as input, parameters 1904, 1906, 1908, 1910, 1912, 1914, 1916 comprising a graph 1906. In at least one embodiment, graph 1906 is data comprising information indicating one or more attributes of a graph, such as nodes, edges, dependencies, and/or any other suitable attribute. In at least one embodiment, graph 1906 is associated with an instantiated graph that is evaluated to be generated and/or executed, as described above in conjunction with FIG. 1, and/or FIG. 2. In at least one embodiment, graph 1906 is data to be input to a function call, if said function call is to perform invocation 1902. In at least one embodiment, graph 1906 is data to be input to an API, if said API is to cause invocation 1902 to be performed.

[0300] In at least one embodiment, invocation 1902 receives, as input, parameters 1904, 1906, 1908, 1910, 1912, 1914, 1916 comprising a dependency pointer 1908. In at least one embodiment, dependency pointer 1908 is data comprising information indicating one or more dependencies between two or more nodes of a graph. In at least one embodiment, dependency pointer 1908 includes information corresponding to one or more dependencies between a node indicated by node pointer 1904 and one or more other nodes of graph 1906. In at least one embodiment, dependency pointer 1908 is data to be input to a function call, if said function call is to perform invocation 1902. In at least one embodiment, dependency pointer 1908 is data to be input to an API, if said API is to cause invocation 1902 to be performed.

[0301] In at least one embodiment, invocation 1902 receives, as input, parameters 1904, 1906, 1908, 1910, 1912, 1914, 1916 comprising edge information 1910. In at least one embodiment, edge information 1910 is data comprising information corresponding to one or more dependencies of graph 1906. In at least one embodiment, edge information 1910 includes information indicating one or more dependencies between a node associated with node pointer 1904 and one or more nodes of graph 1906. In at least one embodiment, edge information 1910 includes an indication of one or more of a source port, a destination port, and/or a dependency type, as described above in conjunction with FIG. 1, FIG. 3, FIG. 4, and/or FIG. 5. In at least one embodiment, edge information 1910 may be represented as an array, in which each element corresponds to an element of a parallel array associated with dependency pointer 1908. In at least one embodiment, edge information 1910 is data to be input to a function call, if said function call is to perform invocation 1902. In at least one embodiment, edge information 1910 is data to be input to an API, if said API is to cause invocation 1902 to be performed.

[0302] In at least one embodiment, invocation 1902 receives, as input, parameters 1904, 1906, 1908, 1910, 1912, 1914, 1916 comprising a number of dependencies 1912. In at least one embodiment, number of dependencies 1912 is data indicating a number, or quantity, of dependencies associated with a node of graph 1906 associated with node pointer 1904. In at least one embodiment, number of dependencies 1912 is data to be input to a function call, if said function call is to perform invocation 1902. In at least one embodiment, number of dependencies 1912 is data to be input to an API, if said API is to cause invocation 1902 to be performed.

[0303] In at least one embodiment, invocation 1902 receives, as input, parameters 1904, 1906, 1908, 1910, 1912, 1914, 1916 comprising one or more memory parameters 1914. In at least one embodiment, memory parameters 1914 is data associated with one or more memory allocation operations corresponding to a node of graph 1906 associated with node pointer 1904. In at least one embodiment, memory parameters 1914 include an indication of a destination memory address. In at least one embodiment, memory parameters 1914 include an indication of a symbol corresponding to one or more portions of memory that data is to be copied to. In at least one embodiment, memory parameters 1914 include an indication of a size (e.g., in bytes) of memory to copy. In at least one embodiment, memory parameters 1914 include an indication of a memory address offset used to identify one or more portions of memory to copy data to.

[0304] In at least one embodiment, memory parameters 1914 include an indication of a size of a portion of requested memory to allocate. In at least one embodiment, memory parameters 1914 include an indication of a symbol from which data is to be copied from corresponding one or more portions of memory. In at least one embodiment, memory parameters 1914 include an indication of a one or more memory addresses corresponding to one or more portions of memory being allocated. In at least one embodiment, memory parameters 1914 include an indication of a type of transfer used to copy data from one portion of memory to another. In at least one embodiment, memory parameters 1914 is data to be input to a function call, if said function call is to perform invocation 1902. In at least one embodiment, memory parameters 1914 is data to be input to an API, if said API is to cause invocation 1902 to be performed.

[0305] In at least one embodiment, invocation 1902 receives, as input, parameters 1904, 1906, 1908, 1910, 1912, 1914, 1916 comprising other parameter(s) 1916. In at least one embodiment, other parameter(s) 1916 are data comprising any other information usable by operation 1900. In at least one embodiment, other parameter(s) 1916 are data to be input to a function call, if said function call is to perform invocation 1902. In at least one embodiment, other parameter(s) 1916 are data to be input to an API, if said API is to cause invocation 1902 to be performed.

[0306] In at least one embodiment, an example instruction indicating operation 1900 in a parallel computing environment, such as compute uniform device architecture (CUDA), is as follows:

[0307] cudaGraphAddMemcpyNodeToSymbol (pGraphNode, graph, pDependencies, pDependencyData, numDependencies, nodeParams) where pGraphNode corresponds to node pointer 1904, graph corresponds to graph 1906, pDependencies corresponds to dependency pointer 1908, pDependencyData corresponds to edge information 1910, and numDependencies corresponds to number of dependencies 1912, and nodeParams corresponds to memory parameters 1914.

[0308] In at least one embodiment, response 1920 generates, as output, parameters 1922, 1924 comprising a status 1922. In at least one embodiment, status 1922 is data comprising any other information presented by operation 1900. In at least one embodiment, status 1922 is data to be output in response to a function call, if said function call is to perform invocation 1902. In at least one embodiment, status 1922 is data to be output by an API, if said API is to cause invocation 1902 to be performed. In at least one embodiment, status 1922 indicates that operation 1900 was performed successfully. In at least one embodiment, status 1922 indicates that operation 1900 was not performed successfully, or otherwise failed.

[0309] In at least one embodiment, response 1920 generates, as output, parameters 1922, 1924 comprising node 1924. In at least one embodiment, node 1924 is data to one or more nodes generated by operation 1900, using information associated with invocation 1902, such as parameters 1904, 1906, 1908, 1910, 1912, 1914, 1916. In at least one embodiment, node 1924 will be output by response 1920 to an address corresponding to node pointer 1904, such that node 1924 will be generated by storing data to an address indicated by node pointer 1904. In at least one embodiment, node 1924 is data to be output in response to a function call, if said function call is to perform invocation 1902. In at least one embodiment, node 1924 is data to be output by an API, if said API is to cause invocation 1902 to be performed. In at least one embodiment, node 1924 is provided to data structure, memory, and/or variable indicated by node pointer 1904. In at least one embodiment, node 1924 is presented in response to performance of one or more API and/or function calls.

[0310] FIG. 20 is a block diagram illustrating a memory set operation 2000 (“operation 2000”), in accordance with at least one embodiment. In at least one embodiment, operation 2000 is one or more computational operations that, if performed, cause a node to be generated and/or added to a graph, as described above in conjunction with FIG. 1. In at least one embodiment, operation 2000 is to cause a user-indicated value storage node to be added to a software graph based, at least in part, on a dependency type. In at least one embodiment, operation 2000 is to cause a memory set node to be generated and/or added to a graph. In at least one embodiment, a memory set node, when executed, causes one or more portions of memory to store one or more values. In at least one embodiment, a memory set node, when executed, stores a value to one or more portions of memory. In at least one embodiment, operation 2000 is a set of instructions that, if performed, cause one or more processors to cause one or more APIs to be performed.

[0311] In at least one embodiment, memory set node invocation 2002 (“invocation 2002”) is a function call to be performed by one or more software programs, such as kernels to be performed by one or more parallel processing units (PPUs), such as graphics processing units (GPUs). In at least one embodiment, invocation 2002 is an invocation of an instruction to cause one or more processors to perform one or more computational operations 2022, 2024 of memory set response 2020 (“response 2020”). In at least one embodiment, invocation 2002 is an invocation of an API to cause one or more processors to perform one or more computational operations 2022, 2024 of response 2020.

[0312] In at least one embodiment, invocation 2002 receives, when invoked, one or more parameters 2004, 2006, 2008, 2010, 2012, 2014, 2016, to indicate information about computational operations to be performed. In at least one embodiment, invocation 2002 receives, when invoked, one or more parameters 2004, 2006, 2008, 2010, 2012, 2014, 2016 to indicate information about instructions to be performed.

[0313] In at least one embodiment, invocation 2002 receives, as input, parameters 2004, 2006, 2008, 2010, 2012, 2014, 2016 comprising a node pointer 2004. In at least one embodiment, node pointer 2004 is data comprising information indicating one or more nodes to be created by operation 2000. In at least one embodiment, node pointer 2004 is a pointer to an address corresponding to one or more nodes to be created by operation 2000. In at least one embodiment, node pointer 2004 is data to be input to a function call, if said function call is to perform invocation 2002. In at least one embodiment, node pointer 2004 is data to be input to an API, if said API is to cause invocation 2002 to be performed.

[0314] In at least one embodiment, invocation 2002 receives, as input, parameters 2004, 2006, 2008, 2010, 2012, 2014, 2016 comprising a graph 2006. In at least one embodiment, graph 2006 is data comprising information indicating one or more attributes of a graph, such as nodes, edges, dependencies, and/or any other suitable attribute. In at least one embodiment, graph 2006 is associated with an instantiated graph that is evaluated to be generated and/or executed, as described above in conjunction with FIG. 1, and/or FIG. 2. In at least one embodiment, graph 2006 is data to be input to a function call, if said function call is to perform invocation 2002. In at least one embodiment, graph 2006 is data to be input to an API, if said API is to cause invocation 2002 to be performed.

[0315] In at least one embodiment, invocation 2002 receives, as input, parameters 2004, 2006, 2008, 2010, 2012, 2014, 2016 comprising a dependency pointer 2008. In at least one embodiment, dependency pointer 2008 is data comprising information indicating one or more dependencies between two or more nodes of a graph. In at least one embodiment, dependency pointer 2008 includes information corresponding to one or more dependencies between a node indicated by node pointer 2004 and one or more other nodes of graph 2006. In at least one embodiment, dependency pointer 2008 is data to be input to a function call, if said function call is to perform invocation 2002. In at least one embodiment, dependency pointer 2008 is data to be input to an API, if said API is to cause invocation 2002 to be performed.

[0316] In at least one embodiment, invocation 2002 receives, as input, parameters 2004, 2006, 2008, 2010, 2012, 2014, 2016 comprising edge information 2010. In at least one embodiment, edge information 2010 is data comprising information corresponding to one or more dependencies of graph 2006. In at least one embodiment, edge information 2010 includes information indicating one or more dependencies between a node associated with node pointer 2004 and one or more nodes of graph 2006. In at least one embodiment, edge information 2010 includes an indication of one or more of a source port, a destination port, and/or a dependency type, as described above in conjunction with FIG. 1, FIG. 3, FIG. 4, and/or FIG. 5. In at least one embodiment, edge information 2010 may be represented as an array, in which each element corresponds to an element of a parallel array associated with dependency pointer 2008. In at least one embodiment, edge information 2010 is data to be input to a function call, if said function call is to perform invocation 2002. In at least one embodiment, edge information 2010 is data to be input to an API, if said API is to cause invocation 2002 to be performed.

[0317] In at least one embodiment, invocation 2002 receives, as input, parameters 2004, 2006, 2008, 2010, 2012, 2014, 2016 comprising a number of dependencies 2012. In at least one embodiment, number of dependencies 2012 is data indicating a number, or quantity, of dependencies associated with a node of graph 2006 associated with node pointer 2004. In at least one embodiment, number of dependencies 2012 is data to be input to a function call, if said function call is to perform invocation 2002. In at least one embodiment, number of dependencies 2012 is data to be input to an API, if said API is to cause invocation 2002 to be performed.

[0318] In at least one embodiment, invocation 2002 receives, as input, parameters 2004, 2006, 2008, 2010, 2012, 2014, 2016 comprising other parameter(s) 2016. In at least one embodiment, other parameter(s) 2016 are data comprising any other information usable by operation 2000. In at least one embodiment, other parameter(s) 2016 are data to be input to a function call, if said function call is to perform invocation 2002. In at least one embodiment, other parameter(s) 2016 are data to be input to an API, if said API is to cause invocation 2002 to be performed.

[0319] In at least one embodiment, an example instruction indicating operation 2000 in a parallel computing environment, such as compute uniform device architecture (CUDA), is as follows:

[0320] cudaGraphAddMemsetNode (pGraphNode, graph, pDependencies, pDependencyData, numDependencies, pMemsetParams) where pGraphNode corresponds to node pointer 2004, graph corresponds to graph 2006, pDependencies corresponds to dependency pointer 2008, pDependencyData corresponds to edge information 2010, and numDependencies corresponds to number of dependencies 2012, and pMemsetParams corresponds to memory parameters 2014.

[0321] In at least one embodiment, response 2020 generates, as output, parameters 2022, 2024 comprising a status 2022. In at least one embodiment, status 2022 is data comprising any other information presented by operation 2000. In at least one embodiment, status 2022 is data to be output in response to a function call, if said function call is to perform invocation 2002. In at least one embodiment, status 2022 is data to be output by an API, if said API is to cause invocation 2002 to be performed. In at least one embodiment, status 2022 indicates that operation 2000 was performed successfully. In at least one embodiment, status 2022 indicates that operation 2000 was not performed successfully, or otherwise failed.

[0322] In at least one embodiment, response 2020 generates, as output, parameters comprising node 2024. In at least one embodiment, node 2024 is data to one or more nodes generated by operation 2000, using information associated with invocation 2002, such as parameters 2004, 2006, 2008, 2010, 2012, 2014, 2016. In at least one embodiment, node 2024 will be output by response 2020 to an address corresponding to node pointer 2004, such that node 2024 will be generated by storing data to an address indicated by node pointer 2004. In at least one embodiment, node 2024 is data to be output in response to a function call, if said function call is to perform invocation 2002. In at least one embodiment, node 2024 is data to be output by an API, if said API is to cause invocation 2002 to be performed. In at least one embodiment, node 2024 is provided to data structure, memory, and/or variable indicated by node pointer 2004. In at least one embodiment, node 2024 is presented in response to performance of one or more API and/or function calls.

[0323] FIG. 21 is a block diagram illustrating an add dependency operation 2100 (“operation 2100”), in accordance with at least one embodiment. In at least one embodiment, operation 2100 is one or more computational operations that, if performed, cause a dependency to be generated and/or added to a graph, as described above in conjunction with FIG. 1. In at least one embodiment, operation 2100 is to cause one or more dependencies between two or more graph nodes to be added to a software graph based, at least in part, on a dependency type. In at least one embodiment, operation 2100 is to cause a dependency between two or more nodes. In at least one embodiment, operation 2100 is a set of instructions that, if performed, cause one or more processors to cause one or more APIs to be performed.

[0324] In at least one embodiment, an add dependency invocation 2102 (“invocation 2102”) is a function call to be performed by one or more software programs, such as kernels to be performed by one or more parallel processing units (PPUs), such as graphics processing units (GPUs). In at least one embodiment, invocation 2102 is an invocation of an instruction to cause one or more processors to perform one or more computational operations 2122, 2124 of an add dependency response 2120 (“response 2120”). In at least one embodiment, invocation 2102 is an invocation of an API to cause one or more processors to perform one or more computational operations 2122, 2124 of response 2120.

[0325] In at least one embodiment, invocation 2102 receives, when invoked, one or more parameters 2104, 2106, 2108, 2110, 2112, 2116, to indicate information about computational operations to be performed. In at least one embodiment, invocation 2102 receives, when invoked, one or more parameters 2104, 2106, 2108, 2110, 2112, 2116 to indicate information about instructions to be performed.

[0326] In at least one embodiment, invocation 2102 receives, as input, parameters 2104, 2106, 2108, 2110, 2112, 2114, 2116 comprising a source node 2104. In at least one embodiment, source node 2104 is data comprising information indicating one or more nodes to from which a dependency is to be generated by operation 2100. In at least one embodiment, source node 2104 is an array indicating one or more nodes from which a dependency originates. In at least one embodiment, source node 2104 is a pointer to an address corresponding to one or more nodes. In at least one embodiment, source node 2104 is data to be input to a function call, if said function call is to perform invocation 2102. In at least one embodiment, source node 2104 is data to be input to an API, if said API is to cause invocation 2102 to be performed.

[0327] In at least one embodiment, invocation 2102 receives, as input, parameters 2104, 2106, 2108, 2110, 2112, 2114, 2116 comprising a graph 2106. In at least one embodiment, graph 2106 is data comprising information indicating one or more attributes of a graph, such as nodes, edges, dependencies, and/or any other suitable attribute. In at least one embodiment, graph 2106 is associated with an instantiated graph that is evaluated to be generated and/or executed, as described above in conjunction with FIG. 1, and/or FIG. 2. In at least one embodiment, graph 2106 is data to be input to a function call, if said function call is to perform invocation 2102. In at least one embodiment, graph 2106 is data to be input to an API, if said API is to cause invocation 2102 to be performed.

[0328] In at least one embodiment, invocation 2102 receives, as input, parameters 2104, 2106, 2108, 2110, 2112, 2114, 2116 comprising a destination node 2108. In at least one embodiment, destination node 2108 is data comprising information indicating one or more nodes to which a dependency is to be generated by operation 2100. In at least one embodiment, destination node 2108 includes an array indicating one or more nodes which depend on one or more other nodes, such as nodes indicated by source node 2104. In at least one embodiment, destination node 2108 is a pointer to an address corresponding to one or more nodes. In at least one embodiment, destination node 2108 is data to be input to a function call, if said function call is to perform invocation 2102. In at least one embodiment, destination node 2108 is data to be input to an API, if said API is to cause invocation 2102 to be performed.

[0329] In at least one embodiment, invocation 2102 receives, as input, parameters 2104, 2106, 2108, 2110, 2112, 2114, 2116 comprising edge information 2110. In at least one embodiment, edge information 2110 is data comprising information corresponding to one or more dependencies of graph 2106. In at least one embodiment, edge information 2110 includes information indicating one or more dependencies between a node associated with node source node 2104, destination node 2108, and/or one or more nodes of graph 2106. In at least one embodiment, edge information 2110 includes an indication of one or more of a source port, a destination port, and/or a dependency type, as described above in conjunction with FIG. 1, FIG. 3, FIG. 4, and/or FIG. 5. In at least one embodiment, edge information 2110 is data to be input to a function call, if said function call is to perform invocation 2102. In at least one embodiment, edge information 2110 is data to be input to an API, if said API is to cause invocation 2102 to be performed.

[0330] In at least one embodiment, invocation 2102 receives, as input, parameters 2104, 2106, 2108, 2110, 2112, 2114, 2116 comprising a number of dependencies 2112. In at least one embodiment, number of dependencies 2112 is data indicating a number, or quantity, of dependencies associated with a node of graph 2106 associated with source node 2104 and/or destination node 2108. In at least one embodiment, number of dependencies 2112 is data to be input to a function call, if said function call is to perform invocation 2102. In at least one embodiment, number of dependencies 2112 is data to be input to an API, if said API is to cause invocation 2102 to be performed.

[0331] In at least one embodiment, invocation 2102 receives, as input, parameters 2104, 2106, 2108, 2110, 2112, 2114, 2116 comprising one or more memory parameters 2114. In at least one embodiment, memory parameters 2114 is data associated with one or more memory allocation operations corresponding to a node of graph 2106 associated with node pointer 2104. In at least one embodiment, memory parameters 2114 include an indication of a number of memory access descriptors. In at least one embodiment, memory parameters 2114 include an indication of a size of a portion of requested memory to allocate. In at least one embodiment, memory parameters 2114 include an indication of a symbol from which data is to be copied from corresponding one or more portions of memory. In at least one embodiment, memory parameters 2114 include an indication of a one or more memory addresses corresponding to one or more portions of memory being allocated. In at least one embodiment, memory parameters 2114 is data to be input to a function call, if said function call is to perform invocation 2102. In at least one embodiment, memory parameters 2114 is data to be input to an API, if said API is to cause invocation 2102 to be performed.

[0332] In at least one embodiment, invocation 2102 receives, as input, parameters 2104, 2106, 2108, 2110, 2112, 2114, 2116 comprising other parameter(s) 2116. In at least one embodiment, other parameter(s) 2116 are data comprising any other information usable by operation 2100. In at least one embodiment, other parameter(s) 2116 are data to be input to a function call, if said function call is to perform invocation 2102. In at least one embodiment, other parameter(s) 2116 are data to be input to an API, if said API is to cause invocation 2102 to be performed.

[0333] In at least one embodiment, an example instruction indicating operation 2100 in a parallel computing environment, such as compute uniform device architecture (CUDA), is as follows:

[0334] cudaGraphAddDependencies (graph, from, to, pDependencyData, numDependencies) where from corresponds to source node 2104, graph corresponds to graph 2106, to corresponds to destination node 2108, pDependencyData corresponds to edge information 2110, and numDependencies corresponds to number of dependencies 2112.

[0335] In at least one embodiment, response 2120 generates, as output, parameters comprising a status 2122. In at least one embodiment, status 2122 is data comprising any other information presented by operation 2100. In at least one embodiment, status 2122 is data to be output in response to a function call, if said function call is to perform invocation 2102. In at least one embodiment, status 2122 is data to be output by an API, if said API is to cause invocation 2102 to be performed. In at least one embodiment, status 2122 indicates that operation 2100 was performed successfully. In at least one embodiment, status 2122 indicates that operation 2100 was not performed successfully, or otherwise failed.

[0336] FIG. 22 is a block diagram illustrating a remove dependency operation 2200 (“operation 2200”), in accordance with at least one embodiment. In at least one embodiment, operation 2200 is one or more computational operations that, if performed, cause a dependency to be removed from a graph, as described above in conjunction with FIG. 1. In at least one embodiment, operation 2200 is to cause one or more dependencies between two or more graph nodes to be removed from a software graph based, at least in part, on a dependency type. In at least one embodiment, operation 2200 is to cause a dependency to be removed from between two or more nodes. In at least one embodiment, operation 2200 is a set of instructions that, if performed, cause one or more processors to cause one or more APIs to be performed.

[0337] In at least one embodiment, a remove dependency invocation 2202 (“invocation 2202”) is a function call to be performed by one or more software programs, such as kernels to be performed by one or more parallel processing units (PPUs), such as graphics processing units (GPUs). In at least one embodiment, invocation 2202 is an invocation of an instruction to cause one or more processors to perform one or more computational operations 2222, 2224 of a remove dependency response 2220 (“response 2220”). In at least one embodiment, invocation 2202 is an invocation of an API to cause one or more processors to perform one or more computational operations 2222, 2224 of response 2220.

[0338] In at least one embodiment, invocation 2202 receives, when invoked, one or more parameters 2204, 2206, 2208, 2210, 2212, 2216, to indicate information about computational operations to be performed. In at least one embodiment, invocation 2202 receives, when invoked, one or more parameters 2204, 2206, 2208, 2210, 2212, 2216 to indicate information about instructions to be performed.

[0339] In at least one embodiment, invocation 2202 receives, as input, parameters 2204, 2206, 2208, 2210, 2212, 2216 comprising a source node 2204. In at least one embodiment, source node 2204 is data comprising information indicating one or more nodes to from which a dependency is to be removed by operation 2200. In at least one embodiment, source node 2204 is an array indicating one or more nodes from which a dependency originates. In at least one embodiment, source node 2204 is a pointer to an address corresponding to one or more nodes. In at least one embodiment, source node 2204 is data to be input to a function call, if said function call is to perform invocation 2202. In at least one embodiment, source node 2204 is data to be input to an API, if said API is to cause invocation 2202 to be performed.

[0340] In at least one embodiment, invocation 2202 receives, as input, parameters 2204, 2206, 2208, 2210, 2212, 2216 comprising a graph 2206. In at least one embodiment, graph 2206 is data comprising information indicating one or more attributes of a graph, such as nodes, edges, dependencies, and/or any other suitable attribute. In at least one embodiment, graph 2206 is associated with an instantiated graph that is evaluated to be generated and/or executed, as described above in conjunction with FIG. 1, and/or FIG. 2. In at least one embodiment, graph 2206 is data to be input to a function call, if said function call is to perform invocation 2202. In at least one embodiment, graph 2206 is data to be input to an API, if said API is to cause invocation 2202 to be performed.

[0341] In at least one embodiment, invocation 2202 receives, as input, parameters 2204, 2206, 2208, 2210, 2212, 2216 comprising a destination node 2208. In at least one embodiment, destination node 2208 is data comprising information indicating one or more nodes to which a dependency is to be removed by operation 2200. In at least one embodiment, destination node 2208 includes an array indicating one or more nodes which depend on one or more other nodes, such as nodes indicated by source node 2204. In at least one embodiment, destination node 2208 is a pointer to an address corresponding to one or more nodes. In at least one embodiment, destination node 2208 is data to be input to a function call, if said function call is to perform invocation 2202. In at least one embodiment, destination node 2208 is data to be input to an API, if said API is to cause invocation 2202 to be performed.

[0342] In at least one embodiment, invocation 2202 receives, as input, parameters 2204, 2206, 2208, 2210, 2212, 2216 comprising edge information 2210. In at least one embodiment, edge information 2210 is data comprising information corresponding to one or more dependencies of graph 2206. In at least one embodiment, edge information 2210 includes information indicating one or more dependencies between a node associated with node source node 2204, destination node 2208, and/or one or more nodes of graph 2206. In at least one embodiment, edge information 2210 includes an indication of one or more of a source port, a destination port, and/or a dependency type, as described above in conjunction with FIG. 1, FIG. 3, FIG. 4, and/or FIG. 5. In at least one embodiment, edge information 2210 is data to be input to a function call, if said function call is to perform invocation 2202. In at least one embodiment, edge information 2210 is data to be input to an API, if said API is to cause invocation 2202 to be performed.

[0343] In at least one embodiment, invocation 2202 receives, as input, parameters 2204, 2206, 2208, 2210, 2212, 2216 comprising a number of dependencies 2212. In at least one embodiment, number of dependencies 2212 is data indicating a number, or quantity, of dependencies associated with a node of graph 2206 associated with source node 2204 and/or destination node 2208. In at least one embodiment, number of dependencies 2212 is data to be input to a function call, if said function call is to perform invocation 2202. In at least one embodiment, number of dependencies 2212 is data to be input to an API, if said API is to cause invocation 2202 to be performed.

[0344] In at least one embodiment, invocation 2202 receives, as input, parameters 2204, 2206, 2208, 2210, 2212, 2216 comprising other parameter(s) 2216. In at least one embodiment, other parameter(s) 2216 are data comprising any other information usable by operation 2200. In at least one embodiment, other parameter(s) 2216 are data to be input to a function call, if said function call is to perform invocation 2202. In at least one embodiment, other parameter(s) 2216 are data to be input to an API, if said API is to cause invocation 2202 to be performed.

[0345] In at least one embodiment, an example instruction indicating operation 2200 in a parallel computing environment, such as compute uniform device architecture (CUDA), is as follows:

[0346] cudaGraphAddDependencies (graph, from, to, pDependencyData, numDependencies) where from corresponds to source node 2204, graph corresponds to graph 2206, to corresponds to destination node 2208, pDependencyData corresponds to edge information 2210, and numDependencies corresponds to number of dependencies 2212.

[0347] In at least one embodiment, response 2220 generates, as output, parameters 2222 comprising a status 2222. In at least one embodiment, status 2222 is data comprising any other information presented by operation 2200. In at least one embodiment, status 2222 is data to be output in response to a function call, if said function call is to perform invocation 2202. In at least one embodiment, status 2222 is data to be output by an API, if said API is to cause invocation 2202 to be performed. In at least one embodiment, status 2222 indicates that operation 2200 was performed successfully. In at least one embodiment, status 2222 indicates that operation 2200 was not performed successfully, or otherwise failed.

[0348] FIG. 23 is a block diagram illustrating a get node operation 2300 (“operation 2300”), in accordance with at least one embodiment. In at least one embodiment, operation 2300 is one or more computational operations that, if performed, cause a one or more nodes having dependencies with one or more other nodes to be identified, as described above in conjunction with FIG. 1. In at least one embodiment, operation 2300 is to cause dependency type information between two or more graph nodes of a software graph to be indicated. In at least one embodiment, operation 2300 is to cause return one or more dependent nodes and corresponding dependency information. In at least one embodiment, operation 2300 is a set of instructions that, if performed, cause one or more processors to cause one or more APIs to be performed.

[0349] In at least one embodiment, a get node invocation 2302 (“invocation 2302”) is a function call to be performed by one or more software programs, such as kernels to be performed by one or more parallel processing units (PPUs), such as graphics processing units (GPUs). In at least one embodiment, invocation 2302 is an invocation of an instruction to cause one or more processors to perform one or more computational operations 2322, 2324 of get node response 2320 (“response 2320”). In at least one embodiment, invocation 2302 is an invocation of an API to cause one or more processors to perform one or more computational operations 2322, 2324 of response 2320.

[0350] In at least one embodiment, invocation 2302 receives, when invoked, one or more parameters 2304,2308, 2316, to indicate information about computational operations to be performed. In at least one embodiment, invocation 2302 receives, when invoked, one or more parameters 2304,2308, 2316 to indicate information about instructions to be performed.

[0351] In at least one embodiment, invocation 2302 receives, as input, parameters 2304,2308, 2316 comprising a node pointer 2304. In at least one embodiment, node pointer 2304 is data comprising information indicating one or more nodes to be identified by operation 2300. In at least one embodiment, node pointer 2304 is a pointer to an address corresponding to one or more nodes to be identified by operation 2300. In at least one embodiment, node pointer 2304 is data to be input to a function call, if said function call is to perform invocation 2302. In at least one embodiment, node pointer 2304 is data to be input to an API, if said API is to cause invocation 2302 to be performed.

[0352] In at least one embodiment, invocation 2302 receives, as input, parameters 2304,2308, 2316 comprising a node 2308. In at least one embodiment, destination node 2308 is data comprising information indicating one or more nodes to which a dependency is to be identified by operation 2300. In at least one embodiment, node 2308 includes an array indicating one or more nodes for which dependent nodes are to be identified and returned by response 2320. In at least one embodiment, node 2308 is a pointer to an address corresponding to one or more nodes. In at least one embodiment, node 2308 is data to be input to a function call, if said function call is to perform invocation 2302. In at least one embodiment, node 2308 is data to be input to an API, if said API is to cause invocation 2302 to be performed.

[0353] In at least one embodiment, invocation 2302 receives, as input, parameters 2304,2308, 2316 comprising other parameter(s) 2316. In at least one embodiment, other parameter(s) 2316 are data comprising any other information usable by operation 2300. In at least one embodiment, other parameter(s) 2316 are data to be input to a function call, if said function call is to perform invocation 2302. In at least one embodiment, other parameter(s) 2316 are data to be input to an API, if said API is to cause invocation 2302 to be performed.

[0354] In at least one embodiment, an example instruction indicating operation 2300 in a parallel computing environment, such as compute uniform device architecture (CUDA), is as follows:

[0355] cudaGraphNodeGetDependentNodes (node, dependentNodes) where node corresponds to node 2308, dependentNodes corresponds to node pointer 2304.

[0356] In at least one embodiment, response 2320 generates, as output, parameters 2322, 2324, 2326 comprising a status 2322. In at least one embodiment, status 2322 is data comprising any other information presented by operation 2300. In at least one embodiment, status 2322 is data to be output in response to a function call, if said function call is to perform invocation 2302. In at least one embodiment, status 2322 is data to be output by an API, if said API is to cause invocation 2302 to be performed. In at least one embodiment, status 2322 indicates that operation 2300 was performed successfully. In at least one embodiment, status 2322 indicates that operation 2300 was not performed successfully, or otherwise failed.

[0357] In at least one embodiment, response 2320 generates, as output, parameters 2322, 2324, 2326, comprising node 2324. In at least one embodiment, node 2324 is data comprising information corresponding to one or more nodes which are dependent on one or more nodes indicated by node 2308. In at least one embodiment, node 2324 is output to a location indicated by node pointer 2304.

[0358] In at least one embodiment, response 2320 generates, as output, parameters 2322, 2324, 2326, comprising edge information 2326. In at least one embodiment, edge information 2326 is data comprising information corresponding to one or more dependencies of node 2308 and/or node 2324. In at least one embodiment, edge information 2326 includes information indicating one or more dependencies between a node associated with node 2308, and/or node 2324. In at least one embodiment, edge information 2326 includes an indication of one or more of a source port, a destination port, and/or a dependency type, as described above in conjunction with FIG. 1, FIG. 3, FIG. 4, and/or FIG. 5.

[0359] FIG. 24 is a block diagram illustrating a get edge operation 2400 (“operation 2400”), in accordance with at least one embodiment. In at least one embodiment, operation 2400 is one or more computational operations that, if performed, cause a one or more edges associated with one or more other nodes to be identified, as described above in conjunction with FIG. 1. In at least one embodiment, operation 2400 is to cause dependency type information between all graph nodes of a software graph to be indicated. In at least one embodiment, operation 2400 is to cause return one or more dependent edges and corresponding dependency information. In at least one embodiment, operation 2400 is a set of instructions that, if performed, cause one or more processors to cause one or more APIs to be performed.

[0360] In at least one embodiment, a get edge invocation 2402 (“invocation 2402”) is a function call to be performed by one or more software programs, such as kernels to be performed by one or more parallel processing units (PPUs), such as graphics processing units (GPUs). In at least one embodiment, invocation 2402 is an invocation of an instruction to cause one or more processors to perform one or more computational operations 2422, 2424 of get edge response 2420 (“response 2420”). In at least one embodiment, invocation 2402 is an invocation of an API to cause one or more processors to perform one or more computational operations 2422, 2424 of response 2420.

[0361] In at least one embodiment, invocation 2402 receives, when invoked, one or more parameters 2404, 2406, 2408, 2416, to indicate information about computational operations to be performed. In at least one embodiment, invocation 2402 receives, when invoked, one or more parameters 2404, 2406, 2408, 2416 to indicate information about instructions to be performed.

[0362] In at least one embodiment, invocation 2402 receives, as input, parameters 2404, 2406, 2408, 2416 comprising a source node 2404. In at least one embodiment, source node 2404 is data comprising information indicating one or more nodes for which one or more corresponding edges are to be identified by operation 2400. In at least one embodiment, source node 2404 is a pointer to an address corresponding to one or more nodes to be identified by operation 2400. In at least one embodiment, source node 2404 is data to be input to a function call, if said function call is to perform invocation 2402. In at least one embodiment, source node 2404 is data to be input to an API, if said API is to cause invocation 2402 to be performed.

[0363] In at least one embodiment, invocation 2402 receives, as input, parameters 2404, 2406, 2408, 2416 comprising a destination node 2408. In at least one embodiment, destination node 2408 is data comprising information indicating one or more nodes for which one or more corresponding edges are to be identified by operation 2400. In at least one embodiment, destination node 2408 is a pointer to an address corresponding to one or more nodes to be identified by operation 2400. In at least one embodiment, destination node 2408 is data to be input to a function call, if said function call is to perform invocation 2402. In at least one embodiment, destination node 2408 is data to be input to an API, if said API is to cause invocation 2402 to be performed.

[0364] In at least one embodiment, invocation 2002 receives, as input, parameters 2004, 2006, 2008, 2016 comprising a graph 2006. In at least one embodiment, graph 2006 is data comprising information indicating one or more attributes of a graph, such as nodes, edges, dependencies, and/or any other suitable attribute. In at least one embodiment, graph 2406 is used by operation 2400 to identify edges between source node 2404 and destination node 2408 within graph 2406. In at least one embodiment, graph 2006 is associated with an instantiated graph that is evaluated to be generated and/or executed, as described above in conjunction with FIG. 1, and/or FIG. 2. In at least one embodiment, graph 2006 is data to be input to a function call, if said function call is to perform invocation 2002. In at least one embodiment, graph 2006 is data to be input to an API, if said API is to cause invocation 2002 to be performed.

[0365] In at least one embodiment, invocation 2402 receives, as input, parameters 2404, 2406, 2408, 2416 comprising other parameter(s) 2416. In at least one embodiment, other parameter(s) 2416 are data comprising any other information usable by operation 2400. In at least one embodiment, other parameter(s) 2416 are data to be input to a function call, if said function call is to perform invocation 2402. In at least one embodiment, other parameter(s) 2416 are data to be input to an API, if said API is to cause invocation 2402 to be performed.

[0366] In at least one embodiment, an example instruction indicating operation 2400 in a parallel computing environment, such as compute uniform device architecture (CUDA), is as follows:

[0367] cudaGraphNodeGetEdges(graph, sourceNode, destinationNode) where graph corresponds to graph 2406, dependentNode corresponds to dependent node 2408, and sourceNode corresponds to source node 2404.

[0368] In at least one embodiment, response 2420 generates, as output, parameters 2422, 2426 comprising a status 2422. In at least one embodiment, status 2422 is data comprising any other information presented by operation 2400. In at least one embodiment, status 2422 is data to be output in response to a function call, if said function call is to perform invocation 2402. In at least one embodiment, status 2422 is data to be output by an API, if said API is to cause invocation 2402 to be performed. In at least one embodiment, status 2422 indicates that operation 2400 was performed successfully. In at least one embodiment, status 2422 indicates that operation 2400 was not performed successfully, or otherwise failed.

[0369] In at least one embodiment, response 2420 generates, as output, parameters 2422, 2426, comprising edge information 2426. In at least one embodiment, edge information 2426 is data comprising information corresponding to one or more edges and/or dependencies of destination node 2408 and/or source node 2404. In at least one embodiment, edge information 2426 includes information indicating one or more dependencies between a node associated with destination node 2408, and/or source node 2404. In at least one embodiment, edge information 2426 includes an indication of one or more of a source port, a destination port, and/or a dependency type, as described above in conjunction with FIG. 1, FIG. 3, FIG. 4, and/or FIG. 5.

[0370] FIG. 25 is a block diagram illustrating a get dependency operation 2500 (“operation 2500”), in accordance with at least one embodiment. In at least one embodiment, operation 2500 is one or more computational operations that, if performed, cause a one or more dependencies associated with one or more nodes to be identified, as described above in conjunction with FIG. 1. In at least one embodiment, operation 2500 is to cause dependency type information of one or more user-indicated graph nodes of a software graph to be indicated. In at least one embodiment, operation 2500 is to cause return dependency information corresponding to one or more nodes of a graph. In at least one embodiment, operation 2500 is a set of instructions that, if performed, cause one or more processors to cause one or more APIs to be performed.

[0371] In at least one embodiment, a get dependency invocation 2502 (“invocation 2502”) is a function call to be performed by one or more software programs, such as kernels to be performed by one or more parallel processing units (PPUs), such as graphics processing units (GPUs). In at least one embodiment, invocation 2502 is an invocation of an instruction to cause one or more processors to perform one or more computational operations 2524 of get dependency response 2520 (“response 2520”). In at least one embodiment, invocation 2502 is an invocation of an API to cause one or more processors to perform one or more computational operations 2522, 2526 of response 2520.

[0372] In at least one embodiment, invocation 2502 receives, when invoked, one or more parameters 2504, 2516, to indicate information about computational operations to be performed. In at least one embodiment, invocation 2502 receives, when invoked, one or more parameters 2504, 2516 to indicate information about instructions to be performed.

[0373] In at least one embodiment, invocation 2502 receives, as input, parameters 2504, 2516 comprising a source node 2504. In at least one embodiment, source node 2504 is data comprising information indicating one or more nodes for which one or more corresponding dependencies are to be identified by operation 2500. In at least one embodiment, source node 2504 is a pointer to an address corresponding to one or more nodes to be identified by operation 2500. In at least one embodiment, source node 2504 is data to be input to a function call, if said function call is to perform invocation 2502. In at least one embodiment, source node 2504 is data to be input to an API, if said API is to cause invocation 2502 to be performed.

[0374] In at least one embodiment, invocation 2502 receives, as input, parameters 2504, 2516 comprising other parameter(s) 2516. In at least one embodiment, other parameter(s) 2516 are data comprising any other information usable by operation 2500. In at least one embodiment, other parameter(s) 2516 are data to be input to a function call, if said function call is to perform invocation 2502. In at least one embodiment, other parameter(s) 2516 are data to be input to an API, if said API is to cause invocation 2502 to be performed.

[0375] In at least one embodiment, an example instruction indicating operation 2500 in a parallel computing environment, such as compute uniform device architecture (CUDA), is as follows:

[0376] cudaGraphNodeGetEdges(sourceNode) where sourceNode corresponds to source node 2504.

[0377] In at least one embodiment, response 2520 generates, as output, parameters 2522, 2526 comprising a status 2522. In at least one embodiment, status 2522 is data comprising any other information presented by operation 2500. In at least one embodiment, status 2522 is data to be output in response to a function call, if said function call is to perform invocation 2502. In at least one embodiment, status 2522 is data to be output by an API, if said API is to cause invocation 2502 to be performed. In at least one embodiment, status 2522 indicates that operation 2500 was performed successfully. In at least one embodiment, status 2522 indicates that operation 2500 was not performed successfully, or otherwise failed.

[0378] In at least one embodiment, response 2520 generates, as output, parameters 2522, 2526, comprising edge information 2526. In at least one embodiment, edge information 2526 is data comprising information corresponding to one or more edges and/or dependencies of destination node 2508 and/or source node 2504. In at least one embodiment, edge information 2526 includes information indicating one or more dependencies between a node associated with destination node 2508, and/or source node 2504. In at least one embodiment, edge information 2526 includes an indication of one or more of a source port, a destination port, and/or a dependency type, as described above in conjunction with FIG. 1, FIG. 3, FIG. 4, and/or FIG. 5.

[0379] FIG. 26 is a block diagram illustrating an update dependency operation 2600 (“operation 2600”), in accordance with at least one embodiment. In at least one embodiment, operation 2600 is one or more computational operations that, if performed, cause a one or more dependencies associated with one or more nodes to be updated, as described above in conjunction with FIG. 1. In at least one embodiment, operation 2600 is to cause dependency type information of one or more graph nodes of a software graph to be modified. In at least one embodiment, operation 2600 is to cause dependency information corresponding to one or more nodes of a graph to be modified. In at least one embodiment, operation 2600 is a set of instructions that, if performed, cause one or more processors to cause one or more APIs to be performed.

[0380] In at least one embodiment, an update dependency invocation 2602 (“invocation 2602”) is a function call to be performed by one or more software programs, such as kernels to be performed by one or more parallel processing units (PPUs), such as graphics processing units (GPUs). In at least one embodiment, invocation 2602 is an invocation of an instruction to cause one or more processors to perform one or more computational operations 2622 of update dependency response 2620 (“response 2620”). In at least one embodiment, invocation 2602 is an invocation of an API to cause one or more processors to perform one or more computational operations 2622 of response 2620.

[0381] In at least one embodiment, invocation 2602 receives, when invoked, one or more parameters 2604, 2606, 2608, 2616, to indicate information about computational operations to be performed. In at least one embodiment, invocation 2602 receives, when invoked, one or more parameters 2604, 2606, 2608, 2616 to indicate information about instructions to be performed.

[0382] In at least one embodiment, invocation 2602 receives, as input, parameters 2604, 2606, 2608, 2616 comprising a source node 2604. In at least one embodiment, source node 2604 is data comprising information indicating one or more nodes for which one or more corresponding dependencies are to be modified by operation 2600. In at least one embodiment, source node 2604 is a pointer to an address corresponding to one or more nodes to be identified by operation 2600. In at least one embodiment, source node 2604 is data to be input to a function call, if said function call is to perform invocation 2602. In at least one embodiment, source node 2604 is data to be input to an API, if said API is to cause invocation 2602 to be performed.

[0383] In at least one embodiment, invocation 2602 receives, as input, parameters 2604, 2606, 2608, 2616 comprising a destination node 2608. In at least one embodiment, destination node 2608 is data comprising information indicating one or more nodes for which one or more corresponding dependencies are to be modified by operation 2600. In at least one embodiment, destination node 2608 is a pointer to an address corresponding to one or more nodes to be identified by operation 2600. In at least one embodiment, destination node 2608 is data to be input to a function call, if said function call is to perform invocation 2602. In at least one embodiment, destination node 2608 is data to be input to an API, if said API is to cause invocation 2602 to be performed.

[0384] In at least one embodiment, invocation 2602 receives, as input, parameters 2604, 2606, 2608, 2616 comprising edge information 2606. In at least one embodiment, edge information 2606 is data comprising information corresponding to one or more dependencies of graph 2606. In at least one embodiment, edge information 2606 includes information indicating one or more dependencies between a node associated with source node 2604 and destination node 2608. In at least one embodiment, edge information 2606 includes an indication of one or more of a source port, a destination port, and/or a dependency type, as described above in conjunction with FIG. 1, FIG. 3, FIG. 4, and/or FIG. 5. In at least one embodiment, edge information 2606 is data to be input to a function call, if said function call is to perform invocation 2602. In at least one embodiment, edge information 2606 is data to be input to an API, if said API is to cause invocation 2602 to be performed.

[0385] In at least one embodiment, invocation 2602 receives, as input, parameters 2604, 2606, 2608, 2616 comprising other parameter(s) 2616. In at least one embodiment, other parameter(s) 2616 are data comprising any other information usable by operation 2600. In at least one embodiment, other parameter(s) 2616 are data to be input to a function call, if said function call is to perform invocation 2602. In at least one embodiment, other parameter(s) 2616 are data to be input to an API, if said API is to cause invocation 2602 to be performed.

[0386] In at least one embodiment, an example instruction indicating operation 2600 in a parallel computing environment, such as compute uniform device architecture (CUDA), is as follows:

[0387] cudaGraphUpdateEdgeData(sourceNode, destinationNode, edgeInformation) where sourceNode corresponds to source node 2604, destinationNode corresponds to destination node 2608, and edgeInformation corresponds to edge information 2606.

[0388] In at least one embodiment, response 2620 generates, as output, parameters 2622 comprising a status 2622. In at least one embodiment, status 2622 is data comprising any other information presented by operation 2600. In at least one embodiment, status 2622 is data to be output in response to a function call, if said function call is to perform invocation 2602. In at least one embodiment, status 2622 is data to be output by an API, if said API is to cause invocation 2602 to be performed. In at least one embodiment, status 2622 indicates that operation 2600 was performed successfully. In at least one embodiment, status 2622 indicates that operation 2600 was not performed successfully, or otherwise failed. FIG. 27 illustrates an example 2700 of a processor, according to at least one embodiment. In at least one embodiment, a processor 2702 performs one or more processes such as those described herein to prevent one or more dependencies from being added to two or more threads. In at least one embodiment, processor 2702 performs one or more operations and/or processes as described in connection with FIG. 1. In at least one embodiment, processor 2702 performs one or more processes such as those described in connection with FIGS. 1-26.

[0389] In at least one embodiment, processor 2702 comprises one or more processors such as those described in connection with FIGS. 34-46. In at least one embodiment, processor 2702 is any suitable processing unit and/or combination of processing units, such as one or more CPUs, GPUs, GPGPUs, PPUs, and/or variations thereof. In at least one embodiment, processor 2702 comprises a graph module 2704 and/or a dependency module 2706. In at least one embodiment, graph module 2704 and/or dependency module 2706 are part of processor 2702 and/or one or more other processors. In at least one embodiment, graph module 2704 and/or dependency module 2706 are distributed among multiple processors that communicate over a bus, network, by writing to shared memory, and/or any suitable communication process such as those described herein.

[0390] In at least one embodiment, as used in any implementation described herein, unless otherwise clear from context or stated explicitly to contrary, a module refers to any combination of software logic, firmware logic, hardware logic, and/or circuitry configured to provide functionality described herein. In at least one embodiment, software may be embodied as a software package, code and/or instruction set or instructions, and “hardware”, as used in any implementation described herein, may include, for example, singly or in any combination, hardwired circuitry, programmable circuitry, state machine circuitry, fixed function circuitry, execution unit circuitry, and/or firmware that stores instructions executed by programmable circuitry. In at least one embodiment, modules may, collectively or individually, be embodied as circuitry that forms part of a larger system, for example, an integrated circuit (IC), system on-chip (SoC), and so forth. In at least one embodiment, a module performs one or more processes in connection with any suitable processing unit and/or combination of processing units, such as one or more CPUs, GPUs, GPGPUs, PPUs, and/or variations thereof.

[0391] In at least one embodiment, graph module 2704 is a module that generates and/or accesses one or more graphs. In at least one embodiment, graph module 2704 performs one or more processes such as those described herein by at least including or otherwise encoding instructions that cause performance of or otherwise can be utilized to perform said one or more processes (e.g., by processor 2702). In at least one embodiment, graph module 2704 obtains or is otherwise provided with one or more graph nodes (e.g., by one or more systems such as those described in connection with FIG. 1). In at least one embodiment, graph module 2704 adds, removes, and/or modifies one or more graph nodes through one or more processes such as those described in connection with FIGS. 1-26. In at least one embodiment, graph module 2704 creates and/or executes a graph, such as those described in connection with FIG. 1. In at least one embodiment, dependency module 2706 is a module that generates, removes, and/or modifies one or more dependencies. In at least one embodiment, dependency module 2706 performs one or more processes such as those described herein by at least including or otherwise encoding instructions that cause performance of or otherwise can be utilized to perform said one or more processes (e.g., by processor 2702). In at least one embodiment, dependency module 2706 accesses one or more dependencies of one or more operations in connection with graph module 2704. In at least one embodiment, dependency module 2706 generates one or more dependencies between two or more nodes of a graph. In at least one embodiment, dependency module 2706 handles dependencies corresponding to one or more operations through one or more processes such as those described in connection with FIGS. 1-26.

Data Center

[0392] FIG. 28 illustrates an exemplary data center 2800, in accordance with at least one embodiment. In at least one embodiment, data center 2800 includes, without limitation, a data center infrastructure layer 2810, a framework layer 2820, a software layer 2830 and an application layer 2840.

[0393] In at least one embodiment, as shown in FIG. 28, data center infrastructure layer 2810 may include a resource orchestrator 2812, grouped computing resources 2814, and node computing resources (“node C.R.s”) 2816(1)-2816(N), where “N” represents any whole, positive integer. In at least one embodiment, node C.R.s 2816(1)-2816(N) may include, but are not limited to, any number of central processing units (“CPUs”) or other processors (including accelerators, field programmable gate arrays (“FPGAs”), data processing units (“DPUs”) in network devices, graphics processors, etc.), memory devices (e.g., dynamic read-only memory), storage devices (e.g., solid state or disk drives), network input/output (“NW I/O”) devices, network switches, virtual machines (“VMs”), power modules, and cooling modules, etc. In at least one embodiment, one or more node C.R.s from among node C.R.s 2816(1)-2816(N) may be a server having one or more of above-mentioned computing resources.

[0394] In at least one embodiment, grouped computing resources 2814 may include separate groupings of node C.R.s housed within one or more racks (not shown), or many racks housed in data centers at various geographical locations (also not shown). Separate groupings of node C.R.s within grouped computing resources 2814 may include grouped compute, network, memory or storage resources that may be configured or allocated to support one or more workloads. In at least one embodiment, several node C.R.s including CPUs or processors may grouped within one or more racks to provide compute resources to support one or more workloads. In at least one embodiment, one or more racks may also include any number of power modules, cooling modules, and network switches, in any combination.

[0395] In at least one embodiment, resource orchestrator 2812 may configure or otherwise control one or more node C.R.s 2816(1)-2816(N) and/or grouped computing resources 2814. In at least one embodiment, resource orchestrator 2812 may include a software design infrastructure (“SDI”) management entity for data center 2800. In at least one embodiment, resource orchestrator 2812 may include hardware, software or some combination thereof.

[0396] In at least one embodiment, as shown in FIG. 28, framework layer 2820 includes, without limitation, a job scheduler 2832, a configuration manager 2834, a resource manager 2836 and a distributed file system 2838. In at least one embodiment, framework layer 2820 may include a framework to support software 2852 of software layer 2830 and/or one or more application(s) 2842 of application layer 2840. In at least one embodiment, software 2852 or application(s) 2842 may respectively include web-based service software or applications, such as those provided by Amazon Web Services, Google Cloud and Microsoft Azure. In at least one embodiment, framework layer 2820 may be, but is not limited to, a type of free and open-source software web application framework such as Apache Spark™ (hereinafter “Spark”) that may utilize distributed file system 2838 for large-scale data processing (e.g., “big data”). In at least one embodiment, job scheduler 2832 may include a Spark driver to facilitate scheduling of workloads supported by various layers of data center 2800. In at least one embodiment, configuration manager 2834 may be capable of configuring different layers such as software layer 2830 and framework layer 2820, including Spark and distributed file system 2838 for supporting large-scale data processing. In at least one embodiment, resource manager 2836 may be capable of managing clustered or grouped computing resources mapped to or allocated for support of distributed file system 2838 and job scheduler 2832. In at least one embodiment, clustered or grouped computing resources may include grouped computing resource 2814 at data center infrastructure layer 2810. In at least one embodiment, resource manager 2836 may coordinate with resource orchestrator 2812 to manage these mapped or allocated computing resources.

[0397] In at least one embodiment, software 2852 included in software layer 2830 may include software used by at least portions of node C.R.s 2816(1)-2816(N), grouped computing resources 2814, and/or distributed file system 2838 of framework layer 2820. One or more types of software may include, but are not limited to, Internet web page search software, e-mail virus scan software, database software, and streaming video content software.

[0398] In at least one embodiment, application(s) 2842 included in application layer 2840 may include one or more types of applications used by at least portions of node C.R.s 2816(1)-2816(N), grouped computing resources 2814, and/or distributed file system 2838 of framework layer 2820. In at least one or more types of applications may include, without limitation, CUDA applications.

[0399] In at least one embodiment, any of configuration manager 2834, resource manager 2836, and resource orchestrator 2812 may implement any number and type of self-modifying actions based on any amount and type of data acquired in any technically feasible fashion. In at least one embodiment, self-modifying actions may relieve a data center operator of data center 2800 from making possibly bad configuration decisions and possibly avoiding underutilized and/or poor performing portions of a data center.

[0400] In at least one embodiment, at least one component shown or described with respect to FIG. 28 is utilized to implement techniques and/or functions described in connection with FIGS. 1-27. In at least one embodiment, at least one component of FIG. 28 is used to identify, generate, remove, process, and/or modify one or more graph dependencies. In at least one embodiment, at least one component of FIG. 28 performs at least one aspect described with respect to graph 102, edge information 110, edge information 112, graph create 120 and/or graph create 122 of FIG. 1, node dependencies 300 of FIG. 3, dependency edge information 400 of FIG. 4, edge information 500 of FIG. 5, operation 600-2600 of FIGS. 6-26, and/or processor 2700 of FIG. 27.

Computer-Based Systems

[0401] The following figures set forth, without limitation, exemplary computer-based systems that can be used to implement at least one embodiment.

[0402] FIG. 29 illustrates a processing system 2900, in accordance with at least one embodiment. In at least one embodiment, processing system 2900 includes one or more processors 2902 and one or more graphics processors 2908, and may be a single processor desktop system, a multiprocessor workstation system, or a server system having a large number of processors 2902 or processor cores 2907. In at least one embodiment, processing system 2900 is a processing platform incorporated within a system-on-a-chip (“SoC”) integrated circuit for use in mobile, handheld, or embedded devices. In at least one embodiment, a processors core 2907 is referred to as a computing unit or compute unit.

[0403] In at least one embodiment, processing system 2900 can include, or be incorporated within a server-based gaming platform, a game console, a media console, a mobile gaming console, a handheld game console, or an online game console. In at least one embodiment, processing system 2900 is a mobile phone, smart phone, tablet computing device or mobile Internet device. In at least one embodiment, processing system 2900 can also include, couple with, or be integrated within a wearable device, such as a smart watch wearable device, smart eyewear device, augmented reality device, or virtual reality device. In at least one embodiment, processing system 2900 is a television or set top box device having one or more processors 2902 and a graphical interface generated by one or more graphics processors 2908.

[0404] In at least one embodiment, one or more processors 2902 each include one or more processor cores 2907 to process instructions which, when executed, perform operations for system and user software. In at least one embodiment, each of one or more processor cores 2907 is configured to process a specific instruction set 2909. In at least one embodiment, instruction set 2909 may facilitate Complex Instruction Set Computing (“CISC”), Reduced Instruction Set Computing (“RISC”), or computing via a Very Long Instruction Word (“VLIW”). In at least one embodiment, processor cores 2907 may each process a different instruction set 2909, which may include instructions to facilitate emulation of other instruction sets. In at least one embodiment, processor core 2907 may also include other processing devices, such as a digital signal processor (“DSP”).

[0405] In at least one embodiment, processor 2902 includes cache memory (‘cache”) 2904. In at least one embodiment, processor 2902 can have a single internal cache or multiple levels of internal cache. In at least one embodiment, cache memory is shared among various components of processor 2902. In at least one embodiment, processor 2902 also uses an external cache (e.g., a Level 3 (“L3”) cache or Last Level Cache (“LLC”)) (not shown), which may be shared among processor cores 2907 using known cache coherency techniques. In at least one embodiment, register file 2906 is additionally included in processor 2902 which may include different types of registers for storing different types of data (e.g., integer registers, floating point registers, status registers, and an instruction pointer register). In at least one embodiment, register file 2906 may include general-purpose registers or other registers.

[0406] In at least one embodiment, one or more processor(s) 2902 are coupled with one or more interface bus(es) 2910 to transmit communication signals such as address, data, or control signals between processor 2902 and other components in processing system 2900. In at least one embodiment interface bus 2910, in one embodiment, can be a processor bus, such as a version of a Direct Media Interface (“DMI”) bus. In at least one embodiment, interface bus 2910 is not limited to a DMI bus, and may include one or more Peripheral Component Interconnect buses (e.g., “PCI,” PCI Express (“PCIe”)), memory buses, or other types of interface buses. In at least one embodiment processor(s) 2902 include an integrated memory controller 2916 and a platform controller hub 2930. In at least one embodiment, memory controller 2916 facilitates communication between a memory device and other components of processing system 2900, while platform controller hub (“PCH”) 2930 provides connections to Input/Output (“I/O”) devices via a local I/O bus.

[0407] In at least one embodiment, memory device 2920 can be a dynamic random access memory (“DRAM”) device, a static random access memory (“SRAM”) device, flash memory device, phase-change memory device, or some other memory device having suitable performance to serve as processor memory. In at least one embodiment memory device 2920 can operate as system memory for processing system 2900, to store data 2922 and instructions 2921 for use when one or more processors 2902 executes an application or process. In at least one embodiment, memory controller 2916 also couples with an optional external graphics processor 2912, which may communicate with one or more graphics processors 2908 in processors 2902 to perform graphics and media operations. In at least one embodiment, a display device 2911 can connect to processor(s) 2902. In at least one embodiment display device 2911 can include one or more of an internal display device, as in a mobile electronic device or a laptop device or an external display device attached via a display interface (e.g., DisplayPort, etc.). In at least one embodiment, display device 2911 can include a head mounted display (“HMD”) such as a stereoscopic display device for use in virtual reality (“VR”) applications or augmented reality (“AR”) applications.

[0408] In at least one embodiment, platform controller hub 2930 enables peripherals to connect to memory device 2920 and processor 2902 via a high-speed I/O bus. In at least one embodiment, I/O peripherals include, but are not limited to, an audio controller 2946, a network controller 2934, a firmware interface 2928, a wireless transceiver 2926, touch sensors 2925, a data storage device 2924 (e.g., hard disk drive, flash memory, etc.). In at least one embodiment, data storage device 2924 can connect via a storage interface (e.g., SATA) or via a peripheral bus, such as PCI, or PCIe. In at least one embodiment, touch sensors 2925 can include touch screen sensors, pressure sensors, or fingerprint sensors. In at least one embodiment, wireless transceiver 2926 can be a Wi-Fi transceiver, a Bluetooth transceiver, or a mobile network transceiver such as a 3G, 4G, or Long Term Evolution (“LTE”) transceiver. In at least one embodiment, firmware interface 2928 enables communication with system firmware, and can be, for example, a unified extensible firmware interface (“UEFI”). In at least one embodiment, network controller 2934 can enable a network connection to a wired network. In at least one embodiment, a high-performance network controller (not shown) couples with interface bus 2910. In at least one embodiment, audio controller 2946 is a multi-channel high definition audio controller. In at least one embodiment, processing system 2900 includes an optional legacy I/O controller 2940 for coupling legacy (e.g., Personal System 2 (“PS/2”)) devices to processing system 2900. In at least one embodiment, platform controller hub 2930 can also connect to one or more Universal Serial Bus (“USB”) controllers 2942 connect input devices, such as keyboard and mouse 2943 combinations, a camera 2944, or other USB input devices.

[0409] In at least one embodiment, an instance of memory controller 2916 and platform controller hub 2930 may be integrated into a discreet external graphics processor, such as external graphics processor 2912. In at least one embodiment, platform controller hub 2930 and/or memory controller 2916 may be external to one or more processor(s) 2902. For example, in at least one embodiment, processing system 2900 can include an external memory controller 2916 and platform controller hub 2930, which may be configured as a memory controller hub and peripheral controller hub within a system chipset that is in communication with processor(s) 2902.

[0410] In at least one embodiment, at least one component shown or described with respect to FIG. 29 is utilized to implement techniques and/or functions described in connection with FIGS. 1-27. In at least one embodiment, at least one component of FIG. 29 is used to identify, generate, remove, process, and/or modify one or more graph dependencies. In at least one embodiment, at least one component of FIG. 29 performs at least one aspect described with respect to graph 102, edge information 110, edge information 112, graph create 120 and/or graph create 122 of FIG. 1, node dependencies 300 of FIG. 3, dependency edge information 400 of FIG. 4, edge information 500 of FIG. 5, operation 600-2600 of FIGS. 6-26, and/or processor 2700 of FIG. 27.

[0411] FIG. 30 illustrates a computer system 3000, in accordance with at least one embodiment. In at least one embodiment, computer system 3000 may be a system with interconnected devices and components, an SOC, or some combination. In at least on embodiment, computer system 3000 is formed with a processor 3002 that may include execution units to execute an instruction. In at least one embodiment, computer system 3000 may include, without limitation, a component, such as processor 3002 to employ execution units including logic to perform algorithms for processing data. In at least one embodiment, computer system 3000 may include processors, such as PENTIUM® Processor family, Xeon™, Itanium®, XScale™ and/or StrongARM™, Intel® Core™, or Intel® Nervana™ microprocessors available from Intel Corporation of Santa Clara, California, although other systems (including PCs having other microprocessors, engineering workstations, set-top boxes and like) may also be used. In at least one embodiment, computer system 3000 may execute a version of WINDOWS' operating system available from Microsoft Corporation of Redmond, Wash., although other operating systems (UNIX and Linux for example), embedded software, and/or graphical user interfaces, may also be used.

[0412] In at least one embodiment, computer system 3000 may be used in other devices such as handheld devices and embedded applications. Some examples of handheld devices include cellular phones, Internet Protocol devices, digital cameras, personal digital assistants (“PDAs”), and handheld PCs. In at least one embodiment, embedded applications may include a microcontroller, a digital signal processor (DSP), an SoC, network computers (“NetPCs”), set-top boxes, network hubs, wide area network (“WAN”) switches, or any other system that may perform one or more instructions.

[0413] In at least one embodiment, computer system 3000 may include, without limitation, processor 3002 that may include, without limitation, one or more execution units 3008 that may be configured to execute a Compute Unified Device Architecture (“CUDA”) (CUDA® is developed by NVIDIA Corporation of Santa Clara, CA) program. In at least one embodiment, a CUDA program is at least a portion of a software application written in a CUDA programming language. In at least one embodiment, computer system 3000 is a single processor desktop or server system. In at least one embodiment, computer system 3000 may be a multiprocessor system. In at least one embodiment, processor 3002 may include, without limitation, a CISC microprocessor, a RISC microprocessor, a VLIW microprocessor, a processor implementing a combination of instruction sets, or any other processor device, such as a digital signal processor, for example. In at least one embodiment, processor 3002 may be coupled to a processor bus 3010 that may transmit data signals between processor 3002 and other components in computer system 3000.

[0414] In at least one embodiment, processor 3002 may include, without limitation, a Level 1 (“L1”) internal cache memory (“cache”) 3004. In at least one embodiment, processor 3002 may have a single internal cache or multiple levels of internal cache. In at least one embodiment, cache memory may reside external to processor 3002. In at least one embodiment, processor 3002 may also include a combination of both internal and external caches. In at least one embodiment, a register file 3006 may store different types of data in various registers including, without limitation, integer registers, floating point registers, status registers, and instruction pointer register.

[0415] In at least one embodiment, execution unit 3008, including, without limitation, logic to perform integer and floating point operations, also resides in processor 3002. Processor 3002 may also include a microcode (“ucode”) read only memory (“ROM”) that stores microcode for certain macro instructions. In at least one embodiment, execution unit 3008 may include logic to handle a packed instruction set 3009. In at least one embodiment, by including packed instruction set 3009 in an instruction set of a general-purpose processor 3002, along with associated circuitry to execute instructions, operations used by many multimedia applications may be performed using packed data in a general-purpose processor 3002. In at least one embodiment, many multimedia applications may be accelerated and executed more efficiently by using full width of a processor's data bus for performing operations on packed data, which may eliminate a need to transfer smaller units of data across a processor's data bus to perform one or more operations one data element at a time.

[0416] In at least one embodiment, execution unit 3008 may also be used in microcontrollers, embedded processors, graphics devices, DSPs, and other types of logic circuits. In at least one embodiment, computer system 3000 may include, without limitation, a memory 3020. In at least one embodiment, memory 3020 may be implemented as a DRAM device, an SRAM device, flash memory device, or other memory device. Memory 3020 may store instruction(s) 3019 and/or data 3021 represented by data signals that may be executed by processor 3002.

[0417] In at least one embodiment, a system logic chip may be coupled to processor bus 3010 and memory 3020. In at least one embodiment, the system logic chip may include, without limitation, a memory controller hub (“MCH”) 3016, and processor 3002 may communicate with MCH 3016 via processor bus 3010. In at least one embodiment, MCH 3016 may provide a high bandwidth memory path 3018 to memory 3020 for instruction and data storage and for storage of graphics commands, data and textures. In at least one embodiment, MCH 3016 may direct data signals between processor 3002, memory 3020, and other components in computer system 3000 and to bridge data signals between processor bus 3010, memory 3020, and a system I/O 3022. In at least one embodiment, system logic chip may provide a graphics port for coupling to a graphics controller. In at least one embodiment, MCH 3016 may be coupled to memory 3020 through high bandwidth memory path 3018 and graphics/video card 3012 may be coupled to MCH 3016 through an Accelerated Graphics Port (“AGP”) interconnect 3014.

[0418] In at least one embodiment, computer system 3000 may use system I/O 3022 that is a proprietary hub interface bus to couple MCH 3016 to I/O controller hub (“ICH”) 3030. In at least one embodiment, ICH 3030 may provide direct connections to some I/O devices via a local I/O bus. In at least one embodiment, local I/O bus may include, without limitation, a high-speed I/O bus for connecting peripherals to memory 3020, a chipset, and processor 3002. Examples may include, without limitation, an audio controller 3029, a firmware hub (“flash BIOS”) 3028, a wireless transceiver 3026, a data storage 3024, a legacy I/O controller 3023 containing a user input interface 3025 and a keyboard interface, a serial expansion port 3027, such as a USB, and a network controller 3034. Data storage 3024 may comprise a hard disk drive, a floppy disk drive, a CD-ROM device, a flash memory device, or other mass storage device.

[0419] In at least one embodiment, FIG. 30 illustrates a system, which includes interconnected hardware devices or “chips.” In at least one embodiment, FIG. 30 may illustrate an exemplary SoC. In at least one embodiment, devices illustrated in FIG. 30 may be interconnected with proprietary interconnects, standardized interconnects (e.g., PCIe), or some combination thereof. In at least one embodiment, one or more components of system 3000 are interconnected using compute express link (“CXL”) interconnects.

[0420] In at least one embodiment, at least one component shown or described with respect to FIG. 30 is utilized to implement techniques and/or functions described in connection with FIGS. 1-27. In at least one embodiment, at least one component of FIG. 30 is used to identify, generate, remove, process, and/or modify one or more graph dependencies. In at least one embodiment, at least one component of FIG. 30 performs at least one aspect described with respect to graph 102, edge information 110, edge information 112, graph create 120 and/or graph create 122 of FIG. 1, node dependencies 300 of FIG. 3, dependency edge information 400 of FIG. 4, edge information 500 of FIG. 5, operation 600-2600 of FIGS. 6-26, and/or processor 2700 of FIG. 27.

[0421] FIG. 31 illustrates a system 3100, in accordance with at least one embodiment. In at least one embodiment, system 3100 is an electronic device that utilizes a processor 3110. In at least one embodiment, system 3100 may be, for example and without limitation, a notebook, a tower server, a rack server, a blade server, an edge device communicatively coupled to one or more on-premise or cloud service providers, a laptop, a desktop, a tablet, a mobile device, a phone, an embedded computer, or any other suitable electronic device.

[0422] In at least one embodiment, system 3100 may include, without limitation, processor 3110 communicatively coupled to any suitable number or kind of components, peripherals, modules, or devices. In at least one embodiment, processor 3110 is coupled using a bus or interface, such as an I²C bus, a System Management Bus (“SMBus”), a Low Pin Count (“LPC”) bus, a Serial Peripheral Interface (“SPI”), a High Definition Audio (“HDA”) bus, a Serial Advance Technology Attachment (“SATA”) bus, a USB (versions 1, 2, 3), or a Universal Asynchronous Receiver/Transmitter (“UART”) bus. In at least one embodiment, FIG. 31 illustrates a system which includes interconnected hardware devices or “chips.” In at least one embodiment, FIG. 31 may illustrate an exemplary SoC. In at least one embodiment, devices illustrated in FIG. 31 may be interconnected with proprietary interconnects, standardized interconnects (e.g., PCIe) or some combination thereof. In at least one embodiment, one or more components of FIG. 31 are interconnected using CXL interconnects.

[0423] In at least one embodiment, FIG. 31 may include a display 3124, a touch screen 3125, a touch pad 3130, a Near Field Communications unit (“NFC”) 3145, a sensor hub 3140, a thermal sensor 3146, an Express Chipset (“EC”) 3135, a Trusted Platform Module (“TPM”) 3138, BIOS/firmware/flash memory (“BIOS, FW Flash”) 3122, a DSP 3160, a Solid State Disk (“SSD”) or Hard Disk Drive (“HDD”) 3120, a wireless local area network unit (“WLAN”) 3150, a Bluetooth unit 3152, a Wireless Wide Area Network unit (“WWAN”) 3156, a Global Positioning System (“GPS”) 3155, a camera (“USB 3.0 camera”) 3154 such as a USB 3.0 camera, or a Low Power Double Data Rate (“LPDDR”) memory unit (“LPDDR3”) 3115 implemented in, for example, LPDDR3 standard. These components may each be implemented in any suitable manner.

[0424] In at least one embodiment, other components may be communicatively coupled to processor 3110 through components discussed above. In at least one embodiment, an accelerometer 3141, an Ambient Light Sensor (“ALS”) 3142, a compass 3143, and a gyroscope 3144 may be communicatively coupled to sensor hub 3140. In at least one embodiment, a thermal sensor 3139, a fan 3137, a keyboard 3136, and a touch pad 3130 may be communicatively coupled to EC 3135. In at least one embodiment, a speaker 3163, a headphones 3164, and a microphone (“mic”) 3165 may be communicatively coupled to an audio unit (“audio codec and class d amp”) 3162, which may in turn be communicatively coupled to DSP 3160. In at least one embodiment, audio unit 3162 may include, for example and without limitation, an audio coder/decoder (“codec”) and a class D amplifier. In at least one embodiment, a SIM card (“SIM”) 3157 may be communicatively coupled to WWAN unit 3156. In at least one embodiment, components such as WLAN unit 3150 and Bluetooth unit 3152, as well as WWAN unit 3156 may be implemented in a Next Generation Form Factor (“NGFF”).

[0425] In at least one embodiment, at least one component shown or described with respect to FIG. 31 is utilized to implement techniques and/or functions described in connection with FIGS. 1-27. In at least one embodiment, at least one component of FIG. 31 is used to identify, generate, remove, process, and/or modify one or more graph dependencies. In at least one embodiment, at least one component of FIG. 31 performs at least one aspect described with respect to graph 102, edge information 110, edge information 112, graph create 120 and/or graph create 122 of FIG. 1, node dependencies 300 of FIG. 3, dependency edge information 400 of FIG. 4, edge information 500 of FIG. 5, operation 600-2600 of FIGS. 6-26, and/or processor 2700 of FIG. 27.

[0426] FIG. 32 illustrates an exemplary integrated circuit 3200, in accordance with at least one embodiment. In at least one embodiment, exemplary integrated circuit 3200 is an SoC that may be fabricated using one or more IP cores. In at least one embodiment, integrated circuit 3200 includes one or more application processor(s) 3205 (e.g., CPUs, DPUs), at least one graphics processor 3210, and may additionally include an image processor 3215 and/or a video processor 3220, any of which may be a modular IP core. In at least one embodiment, integrated circuit 3200 includes peripheral or bus logic including a USB controller 3225, a UART controller 3230, an SPI/SDIO controller 3235, and an I²S/I²C controller 3240. In at least one embodiment, integrated circuit 3200 can include a display device 3245 coupled to one or more of a high-definition multimedia interface (“HDMI”) controller 3250 and a mobile industry processor interface (“MIPI”) display interface 3255. In at least one embodiment, storage may be provided by a flash memory subsystem 3260 including flash memory and a flash memory controller. In at least one embodiment, a memory interface may be provided via a memory controller 3265 for access to SDRAM or SRAM memory devices. In at least one embodiment, some integrated circuits additionally include an embedded security engine 3270.

[0427] FIG. 33 illustrates a computing system 3300, according to at least one embodiment; In at least one embodiment, computing system 3300 includes a processing subsystem 3301 having one or more processor(s) 3302 and a system memory 3304 communicating via an interconnection path that may include a memory hub 3305. In at least one embodiment, memory hub 3305 may be a separate component within a chipset component or may be integrated within one or more processor(s) 3302. In at least one embodiment, memory hub 3305 couples with an I/O subsystem 3311 via a communication link 3306. In at least one embodiment, I/O subsystem 3311 includes an I/O hub 3307 that can enable computing system 3300 to receive input from one or more input device(s) 3308. In at least one embodiment, I/O hub 3307 can enable a display controller, which may be included in one or more processor(s) 3302, to provide outputs to one or more display device(s) 3310A. In at least one embodiment, one or more display device(s) 3310A coupled with I/O hub 3307 can include a local, internal, or embedded display device.

[0428] In at least one embodiment, processing subsystem 3301 includes one or more parallel processor(s) 3312 coupled to memory hub 3305 via a bus or other communication link 3313. In at least one embodiment, communication link 3313 may be one of any number of standards based communication link technologies or protocols, such as, but not limited to PCIe, or may be a vendor specific communications interface or communications fabric. In at least one embodiment, one or more parallel processor(s) 3312 form a computationally focused parallel or vector processing system that can include a large number of processing cores and/or processing clusters, such as a many integrated core processor or compute units. In at least one embodiment, one or more parallel processor(s) 3312 form a graphics processing subsystem that can output pixels to one of one or more display device(s) 3310A coupled via I/O Hub 3307. In at least one embodiment, one or more parallel processor(s) 3312 can also include a display controller and display interface (not shown) to enable a direct connection to one or more display device(s) 3310B.

[0429] In at least one embodiment, a system storage unit 3314 can connect to I/O hub 3307 to provide a storage mechanism for computing system 3300. In at least one embodiment, an I/O switch 3316 can be used to provide an interface mechanism to enable connections between I/O hub 3307 and other components, such as a network adapter 3318 and/or wireless network adapter 3319 that may be integrated into a platform, and various other devices that can be added via one or more add-in device(s) 3320. In at least one embodiment, network adapter 3318 can be an Ethernet adapter or another wired network adapter. In at least one embodiment, wireless network adapter 3319 can include one or more of a Wi-Fi, Bluetooth, NFC, or other network device that includes one or more wireless radios.

[0430] In at least one embodiment, computing system 3300 can include other components not explicitly shown, including USB or other port connections, optical storage drives, video capture devices, and the like, that may also be connected to I/O hub 3307. In at least one embodiment, communication paths interconnecting various components in FIG. 33 may be implemented using any suitable protocols, such as PCI based protocols (e.g., PCIe), or other bus or point-to-point communication interfaces and/or protocol(s), such as NVLink high-speed interconnect, or interconnect protocols.

[0431] In at least one embodiment, one or more parallel processor(s) 3312 incorporate circuitry optimized for graphics and video processing, including, for example, video output circuitry, and constitutes a graphics processing unit (“GPU”). In at least one embodiment, one or more parallel processor(s) 3312 incorporate circuitry optimized for general purpose processing. In at least embodiment, components of computing system 3300 may be integrated with one or more other system elements on a single integrated circuit. For example, in at least one embodiment, one or more parallel processor(s) 3312, memory hub 3305, processor(s) 3302, and I/O hub 3307 can be integrated into an SoC integrated circuit. In at least one embodiment, components of computing system 3300 can be integrated into a single package to form a system in package (“SIP”) configuration. In at least one embodiment, at least a portion of the components of computing system 3300 can be integrated into a multi-chip module (“MCM”), which can be interconnected with other multi-chip modules into a modular computing system. In at least one embodiment, I/O subsystem 3311 and display devices 3310B are omitted from computing system 3300.

[0432] In at least one embodiment, at least one component shown or described with respect to FIG. 33 is utilized to implement techniques and/or functions described in connection with FIGS. 1-27. In at least one embodiment, at least one component of FIG. 33 is used to identify, generate, remove, process, and/or modify one or more graph dependencies. In at least one embodiment, at least one component of FIG. 33 performs at least one aspect described with respect to graph 102, edge information 110, edge information 112, graph create 120 and/or graph create 122 of FIG. 1, node dependencies 300 of FIG. 3, dependency edge information 400 of FIG. 4, edge information 500 of FIG. 5, operation 600-2600 of FIGS. 6-26, and/or processor 2700 of FIG. 27.

Processing Systems

[0433] The following figures set forth, without limitation, exemplary processing systems that can be used to implement at least one embodiment.

[0434] FIG. 34 illustrates an accelerated processing unit (“APU”) 3400, in accordance with at least one embodiment. In at least one embodiment, APU 3400 is developed by AMD Corporation of Santa Clara, CA. In at least one embodiment, APU 3400 can be configured to execute an application program, such as a CUDA program. In at least one embodiment, APU 3400 includes, without limitation, a core complex 3410, a graphics complex 3440, fabric 3460, I/O interfaces 3470, memory controllers 3480, a display controller 3492, and a multimedia engine 3494. In at least one embodiment, APU 3400 may include, without limitation, any number of core complexes 3410, any number of graphics complexes 3450, any number of display controllers 3492, and any number of multimedia engines 3494 in any combination. For explanatory purposes, multiple instances of like objects are denoted herein with reference numbers identifying the object and parenthetical numbers identifying the instance where needed.

[0435] In at least one embodiment, core complex 3410 is a CPU, graphics complex 3440 is a GPU, and APU 3400 is a processing unit that integrates, without limitation, 3410 and 3440 onto a single chip. In at least one embodiment, some tasks may be assigned to core complex 3410 and other tasks may be assigned to graphics complex 3440. In at least one embodiment, core complex 3410 is configured to execute main control software associated with APU 3400, such as an operating system. In at least one embodiment, core complex 3410 is the master processor of APU 3400, controlling and coordinating operations of other processors. In at least one embodiment, core complex 3410 issues commands that control the operation of graphics complex 3440. In at least one embodiment, core complex 3410 can be configured to execute host executable code derived from CUDA source code, and graphics complex 3440 can be configured to execute device executable code derived from CUDA source code.

[0436] In at least one embodiment, core complex 3410 includes, without limitation, cores 3420(1)-3420(4) and an L3 cache 3430. In at least one embodiment, core complex 3410 may include, without limitation, any number of cores 3420 and any number and type of caches in any combination. In at least one embodiment, cores 3420 are configured to execute instructions of a particular instruction set architecture (“ISA”). In at least one embodiment, each core 3420 is a CPU core. In at least one embodiment, core 3420 is referred to as a computing unit or compute unit.

[0437] In at least one embodiment, each core 3420 includes, without limitation, a fetch/decode unit 3422, an integer execution engine 3424, a floating point execution engine 3426, and an L2 cache 3428. In at least one embodiment, fetch/decode unit 3422 fetches instructions, decodes such instructions, generates micro-operations, and dispatches separate micro-instructions to integer execution engine 3424 and floating point execution engine 3426. In at least one embodiment, fetch/decode unit 3422 can concurrently dispatch one micro-instruction to integer execution engine 3424 and another micro-instruction to floating point execution engine 3426. In at least one embodiment, integer execution engine 3424 executes, without limitation, integer and memory operations. In at least one embodiment, floating point engine 3426 executes, without limitation, floating point and vector operations. In at least one embodiment, fetch-decode unit 3422 dispatches micro-instructions to a single execution engine that replaces both integer execution engine 3424 and floating point execution engine 3426.

[0438] In at least one embodiment, each core 3420(i), where i is an integer representing a particular instance of core 3420, may access L2 cache 3428(i) included in core 3420(i). In at least one embodiment, each core 3420 included in core complex 3410(j), where j is an integer representing a particular instance of core complex 3410, is connected to other cores 3420 included in core complex 3410(j) via L3 cache 3430(j) included in core complex 3410(j). In at least one embodiment, cores 3420 included in core complex 3410(j), where j is an integer representing a particular instance of core complex 3410, can access all of L3 cache 3430(j) included in core complex 3410(j). In at least one embodiment, L3 cache 3430 may include, without limitation, any number of slices.

[0439] In at least one embodiment, graphics complex 3440 can be configured to perform compute operations in a highly-parallel fashion. In at least one embodiment, graphics complex 3440 is configured to execute graphics pipeline operations such as draw commands, pixel operations, geometric computations, and other operations associated with rendering an image to a display. In at least one embodiment, graphics complex 3440 is configured to execute operations unrelated to graphics. In at least one embodiment, graphics complex 3440 is configured to execute both operations related to graphics and operations unrelated to graphics.

[0440] In at least one embodiment, graphics complex 3440 includes, without limitation, any number of compute units 3450 and an L2 cache 3442. In at least one embodiment, compute units 3450 share L2 cache 3442. In at least one embodiment, L2 cache 3442 is partitioned. In at least one embodiment, graphics complex 3440 includes, without limitation, any number of compute units 3450 and any number (including zero) and type of caches. In at least one embodiment, graphics complex 3440 includes, without limitation, any amount of dedicated graphics hardware.

[0441] In at least one embodiment, each compute unit 3450 includes, without limitation, any number of SIMD units 3452 and a shared memory 3454. In at least one embodiment, each SIMD unit 3452 implements a STMD architecture and is configured to perform operations in parallel. In at least one embodiment, each compute unit 3450 may execute any number of thread blocks, but each thread block executes on a single compute unit 3450. In at least one embodiment, a thread block includes, without limitation, any number of threads of execution. In at least one embodiment, a workgroup is a thread block. In at least one embodiment, each SIMD unit 3452 executes a different warp. In at least one embodiment, a warp is a group of threads (e.g., 16 threads), where each thread in the warp belongs to a single thread block and is configured to process a different set of data based on a single set of instructions. In at least one embodiment, predication can be used to disable one or more threads in a warp. In at least one embodiment, a lane is a thread. In at least one embodiment, a work item is a thread. In at least one embodiment, a wavefront is a warp. In at least one embodiment, different wavefronts in a thread block may synchronize together and communicate via shared memory 3454.

[0442] In at least one embodiment, fabric 3460 is a system interconnect that facilitates data and control transmissions across core complex 3410, graphics complex 3440, I/O interfaces 3470, memory controllers 3480, display controller 3492, and multimedia engine 3494. In at least one embodiment, APU 3400 may include, without limitation, any amount and type of system interconnect in addition to or instead of fabric 3460 that facilitates data and control transmissions across any number and type of directly or indirectly linked components that may be internal or external to APU 3400. In at least one embodiment, I/O interfaces 3470 are representative of any number and type of I/O interfaces (e.g., PCI, PCI-Extended (“PCI-X”), PCIe, gigabit Ethernet (“GBE”), USB, etc.). In at least one embodiment, various types of peripheral devices are coupled to I/O interfaces 3470 In at least one embodiment, peripheral devices that are coupled to I/O interfaces 3470 may include, without limitation, keyboards, mice, printers, scanners, joysticks or other types of game controllers, media recording devices, external storage devices, network interface cards, and so forth.

[0443] In at least one embodiment, display controller AMD92 displays images on one or more display device(s), such as a liquid crystal display (“LCD”) device. In at least one embodiment, multimedia engine 3494 includes, without limitation, any amount and type of circuitry that is related to multimedia, such as a video decoder, a video encoder, an image signal processor, etc. In at least one embodiment, memory controllers 3480 facilitate data transfers between APU 3400 and a unified system memory 3490. In at least one embodiment, core complex 3410 and graphics complex 3440 share unified system memory 3490.

[0444] In at least one embodiment, APU 3400 implements a memory subsystem that includes, without limitation, any amount and type of memory controllers 3480 and memory devices (e.g., shared memory 3454) that may be dedicated to one component or shared among multiple components. In at least one embodiment, APU 3400 implements a cache subsystem that includes, without limitation, one or more cache memories (e.g., L2 caches 3528, L3 cache 3430, and L2 cache 3442) that may each be private to or shared between any number of components (e.g., cores 3420, core complex 3410, SIMD units 3452, compute units 3450, and graphics complex 3440).

[0445] In at least one embodiment, at least one component shown or described with respect to FIG. 34 is utilized to implement techniques and/or functions described in connection with FIGS. 1-27. In at least one embodiment, at least one component of FIG. 34 is used to identify, generate, remove, process, and/or modify one or more graph dependencies. In at least one embodiment, at least one component of FIG. 34 performs at least one aspect described with respect to graph 102, edge information 110, edge information 112, graph create 120 and/or graph create 122 of FIG. 1, node dependencies 300 of FIG. 3, dependency edge information 400 of FIG. 4, edge information 500 of FIG. 5, operation 600-2600 of FIGS. 6-26, and/or processor 2700 of FIG. 27.

[0446] FIG. 35 illustrates a CPU 3500, in accordance with at least one embodiment. In at least one embodiment, CPU 3500 is developed by AMD Corporation of Santa Clara, CA. In at least one embodiment, CPU 3500 can be configured to execute an application program. In at least one embodiment, CPU 3500 is configured to execute main control software, such as an operating system. In at least one embodiment, CPU 3500 issues commands that control the operation of an external GPU (not shown). In at least one embodiment, CPU 3500 can be configured to execute host executable code derived from CUDA source code, and an external GPU can be configured to execute device executable code derived from such CUDA source code. In at least one embodiment, CPU 3500 includes, without limitation, any number of core complexes 3510, fabric 3560, I/O interfaces 3570, and memory controllers 3580.

[0447] In at least one embodiment, core complex 3510 includes, without limitation, cores 3520(1)-3520(4) and an L3 cache 3530. In at least one embodiment, core complex 3510 may include, without limitation, any number of cores 3520 and any number and type of caches in any combination. In at least one embodiment, cores 3520 are configured to execute instructions of a particular ISA. In at least one embodiment, each core 3520 is a CPU core.

[0448] In at least one embodiment, each core 3520 includes, without limitation, a fetch/decode unit 3522, an integer execution engine 3524, a floating point execution engine 3526, and an L2 cache 3528. In at least one embodiment, fetch/decode unit 3522 fetches instructions, decodes such instructions, generates micro-operations, and dispatches separate micro-instructions to integer execution engine 3524 and floating point execution engine 3526. In at least one embodiment, fetch/decode unit 3522 can concurrently dispatch one micro-instruction to integer execution engine 3524 and another micro-instruction to floating point execution engine 3526. In at least one embodiment, integer execution engine 3524 executes, without limitation, integer and memory operations. In at least one embodiment, floating point engine 3526 executes, without limitation, floating point and vector operations. In at least one embodiment, fetch-decode unit 3522 dispatches micro-instructions to a single execution engine that replaces both integer execution engine 3524 and floating point execution engine 3526.

[0449] In at least one embodiment, each core 3520(i), where i is an integer representing a particular instance of core 3520, may access L2 cache 3528(i) included in core 3520(i). In at least one embodiment, each core 3520 included in core complex 3510(j), where j is an integer representing a particular instance of core complex 3510, is connected to other cores 3520 in core complex 3510(j) via L3 cache 3530(j) included in core complex 3510(j). In at least one embodiment, cores 3520 included in core complex 3510(j), where j is an integer representing a particular instance of core complex 3510, can access all of L3 cache 3530(j) included in core complex 3510(j). In at least one embodiment, L3 cache 3530 may include, without limitation, any number of slices.

[0450] In at least one embodiment, fabric 3560 is a system interconnect that facilitates data and control transmissions across core complexes 3510(1)-3510(N) (where N is an integer greater than zero), I/O interfaces 3570, and memory controllers 3580. In at least one embodiment, CPU 3500 may include, without limitation, any amount and type of system interconnect in addition to or instead of fabric 3560 that facilitates data and control transmissions across any number and type of directly or indirectly linked components that may be internal or external to CPU 3500. In at least one embodiment, I/O interfaces 3570 are representative of any number and type of I/O interfaces (e.g., PCI, PCI-X, PCIe, GBE, USB, etc.). In at least one embodiment, various types of peripheral devices are coupled to I/O interfaces 3570 In at least one embodiment, peripheral devices that are coupled to I/O interfaces 3570 may include, without limitation, displays, keyboards, mice, printers, scanners, joysticks or other types of game controllers, media recording devices, external storage devices, network interface cards, and so forth.

[0451] In at least one embodiment, memory controllers 3580 facilitate data transfers between CPU 3500 and a system memory 3590. In at least one embodiment, core complex 3510 and graphics complex 3540 share system memory 3590. In at least one embodiment, CPU 3500 implements a memory subsystem that includes, without limitation, any amount and type of memory controllers 3580 and memory devices that may be dedicated to one component or shared among multiple components. In at least one embodiment, CPU 3500 implements a cache subsystem that includes, without limitation, one or more cache memories (e.g., L2 caches 3528 and L3 caches 3530) that may each be private to or shared between any number of components (e.g., cores 3520 and core complexes 3510).

[0452] In at least one embodiment, at least one component shown or described with respect to FIG. 35 is utilized to implement techniques and/or functions described in connection with FIGS. 1-27. In at least one embodiment, at least one component of FIG. 35 is used to identify, generate, remove, process, and/or modify one or more graph dependencies. In at least one embodiment, at least one component of FIG. 35 performs at least one aspect described with respect to graph 102, edge information 110, edge information 112, graph create 120 and/or graph create 122 of FIG. 1, node dependencies 300 of FIG. 3, dependency edge information 400 of FIG. 4, edge information 500 of FIG. 5, operation 600-2600 of FIGS. 6-26, and/or processor 2700 of FIG. 27.

[0453] FIG. 36 illustrates an exemplary accelerator integration slice 3690, in accordance with at least one embodiment. As used herein, a “slice” comprises a specified portion of processing resources of an accelerator integration circuit. In at least one embodiment, the accelerator integration circuit provides cache management, memory access, context management, and interrupt management services on behalf of multiple graphics processing engines included in a graphics acceleration module. The graphics processing engines may each comprise a separate GPU. Alternatively, the graphics processing engines may comprise different types of graphics processing engines within a GPU such as graphics execution units, media processing engines (e.g., video encoders/decoders), samplers, and blit engines. In at least one embodiment, the graphics acceleration module may be a GPU with multiple graphics processing engines. In at least one embodiment, the graphics processing engines may be individual GPUs integrated on a common package, line card, or chip.

[0454] An application effective address space 3682 within system memory 3614 stores process elements 3683. In one embodiment, process elements 3683 are stored in response to GPU invocations 3681 from applications 3680 executed on processor 3607. A process element 3683 contains process state for corresponding application 3680. A work descriptor (“WD”) 3684 contained in process element 3683 can be a single job requested by an application or may contain a pointer to a queue of jobs. In at least one embodiment, WD 3684 is a pointer to a job request queue in application effective address space 3682.

[0455] Graphics acceleration module 3646 and/or individual graphics processing engines can be shared by all or a subset of processes in a system. In at least one embodiment, an infrastructure for setting up process state and sending WD 3684 to graphics acceleration module 3646 to start a job in a virtualized environment may be included.

[0456] In at least one embodiment, a dedicated-process programming model is implementation-specific. In this model, a single process owns graphics acceleration module 3646 or an individual graphics processing engine. Because graphics acceleration module 3646 is owned by a single process, a hypervisor initializes an accelerator integration circuit for an owning partition and an operating system initializes accelerator integration circuit for an owning process when graphics acceleration module 3646 is assigned.

[0457] In operation, a WD fetch unit 3691 in accelerator integration slice 3690 fetches next WD 3684 which includes an indication of work to be done by one or more graphics processing engines of graphics acceleration module 3646. Data from WD 3684 may be stored in registers 3645 and used by a memory management unit (“MMU”) 3639, interrupt management circuit 3647 and/or context management circuit 3648 as illustrated. For example, one embodiment of MMU 3639 includes segment/page walk circuitry for accessing segment/page tables 3686 within OS virtual address space 3685. Interrupt management circuit 3647 may process interrupt events (“INT”) 3692 received from graphics acceleration module 3646. When performing graphics operations, an effective address 3693 generated by a graphics processing engine is translated to a real address by MMU 3639.

[0458] In one embodiment, a same set of registers 3645 are duplicated for each graphics processing engine and/or graphics acceleration module 3646 and may be initialized by a hypervisor or operating system. Each of these duplicated registers may be included in accelerator integration slice 3690. Exemplary registers that may be initialized by a hypervisor are shown in Table 1.

[0459]

TABLE 1
Hypervisor Initialized Registers
1	Slice Control Register
2	Real Address (RA) Scheduled Processes Area Pointer
3	Authority Mask Override Register
4	Interrupt Vector Table Entry Offset
5	Interrupt Vector Table Entry Limit
6	State Register
7	Logical Partition ID
8	Real address (RA) Hypervisor Accelerator Utilization Record Pointer
9	Storage Description Register

[0460] Exemplary registers that may be initialized by an operating system are shown in Table 2.

[0461]

TABLE 2
Operating System Initialized Registers
1	Process and Thread Identification
2	Effective Address (EA) Context Save/Restore Pointer
3	Virtual Address (VA) Accelerator Utilization Record Pointer
4	Virtual Address (VA) Storage Segment Table Pointer
5	Authority Mask
6	Work descriptor

[0462] In one embodiment, each WD 3684 is specific to a particular graphics acceleration module 3646 and/or a particular graphics processing engine. It contains all information required by a graphics processing engine to do work or it can be a pointer to a memory location where an application has set up a command queue of work to be completed.

[0463] FIGS. 37A and 37B illustrate exemplary graphics processors, in accordance with at least one embodiment. In at least one embodiment, any of the exemplary graphics processors may be fabricated using one or more IP cores. In addition to what is illustrated, other logic and circuits may be included in at least one embodiment, including additional graphics processors/cores, peripheral interface controllers, or general-purpose processor cores. In at least one embodiment, the exemplary graphics processors are for use within an SoC.

[0464] FIG. 37A illustrates an exemplary graphics processor 3710 of an SoC integrated circuit that may be fabricated using one or more IP cores, in accordance with at least one embodiment. FIG. 37B illustrates an additional exemplary graphics processor 3740 of an SoC integrated circuit that may be fabricated using one or more IP cores, in accordance with at least one embodiment. In at least one embodiment, graphics processor 3710 of FIG. 37A is a low power graphics processor core. In at least one embodiment, graphics processor 3740 of FIG. 37B is a higher performance graphics processor core. In at least one embodiment, each of graphics processors 3710, 3740 can be variants of graphics processor 3210 of FIG. 32.

[0465] In at least one embodiment, graphics processor 3710 includes a vertex processor 3705 and one or more fragment processor(s) 3715A-3715N (e.g., 3715A, 3715B, 3715C, 3715D, through 3715N-1, and 3715N). In at least one embodiment, graphics processor 3710 can execute different shader programs via separate logic, such that vertex processor 3705 is optimized to execute operations for vertex shader programs, while one or more fragment processor(s) 3715A-3715N execute fragment (e.g., pixel) shading operations for fragment or pixel shader programs. In at least one embodiment, vertex processor 3705 performs a vertex processing stage of a 3D graphics pipeline and generates primitives and vertex data. In at least one embodiment, fragment processor(s) 3715A-3715N use primitive and vertex data generated by vertex processor 3705 to produce a framebuffer that is displayed on a display device. In at least one embodiment, fragment processor(s) 3715A-3715N are optimized to execute fragment shader programs as provided for in an OpenGL API, which may be used to perform similar operations as a pixel shader program as provided for in a Direct 3D API.

[0466] In at least one embodiment, graphics processor 3710 additionally includes one or more MMU(s) 3720A-3720B, cache(s) 3725A-3725B, and circuit interconnect(s) 3730A-3730B. In at least one embodiment, one or more MMU(s) 3720A-3720B provide for virtual to physical address mapping for graphics processor 3710, including for vertex processor 3705 and/or fragment processor(s) 3715A-3715N, which may reference vertex or image/texture data stored in memory, in addition to vertex or image/texture data stored in one or more cache(s) 3725A-3725B. In at least one embodiment, one or more MMU(s) 3720A-3720B may be synchronized with other MMUs within a system, including one or more MMUs associated with one or more application processor(s) 3205, image processors 3215, and/or video processors 3220 of FIG. 32, such that each processor 3205-3220 can participate in a shared or unified virtual memory system. In at least one embodiment, one or more circuit interconnect(s) 3730A-3730B enable graphics processor 3710 to interface with other IP cores within an SoC, either via an internal bus of the SoC or via a direct connection.

[0467] In at least one embodiment, graphics processor 3740 includes one or more MMU(s) 3720A-3720B, caches 3725A-3725B, and circuit interconnects 3730A-3730B of graphics processor 3710 of FIG. 37A. In at least one embodiment, graphics processor 3740 includes one or more shader core(s) 3755A-3755N (e.g., 3755A, 3755B, 3755C, 3755D, 3755E, 3755F, through 3755N-1, and 3755N), which provides for a unified shader core architecture in which a single core or type or core can execute all types of programmable shader code, including shader program code to implement vertex shaders, fragment shaders, and/or compute shaders. In at least one embodiment, a number of shader cores can vary. In at least one embodiment, graphics processor 3740 includes an inter-core task manager 3745, which acts as a thread dispatcher to dispatch execution threads to one or more shader cores 3755A-3755N and a tiling unit 3758 to accelerate tiling operations for tile-based rendering, in which rendering operations for a scene are subdivided in image space, for example to exploit local spatial coherence within a scene or to optimize use of internal caches.

[0468] In at least one embodiment, at least one component shown or described with respect to FIG. 37 is utilized to implement techniques and/or functions described in connection with FIGS. 1-27. In at least one embodiment, at least one component of FIG. 37 is used to identify, generate, remove, process, and/or modify one or more graph dependencies. In at least one embodiment, at least one component of FIG. 37 performs at least one aspect described with respect to graph 102, edge information 110, edge information 112, graph create 120 and/or graph create 122 of FIG. 1, node dependencies 300 of FIG. 3, dependency edge information 400 of FIG. 4, edge information 500 of FIG. 5, operation 600-2600 of FIGS. 6-26, and/or processor 2700 of FIG. 27.

[0469] FIG. 38A illustrates a graphics core 3800, in accordance with at least one embodiment. In at least one embodiment, graphics core 3800 may be included within graphics processor 3210 of FIG. 32. In at least one embodiment, graphics core 3800 may be a unified shader core 3755A-3755N as in FIG. 37B. In at least one embodiment, graphics core 3800 includes a shared instruction cache 3802, a texture unit 3818, and a cache/shared memory 3820 that are common to execution resources within graphics core 3800. In at least one embodiment, graphics core 3800 can include multiple slices 3801A-3801N or partition for each core, and a graphics processor can include multiple instances of graphics core 3800. Slices 3801A-3801N can include support logic including a local instruction cache 3804A-3804N, a thread scheduler 3806A-3806N, a thread dispatcher 3808A-3808N, and a set of registers 3810A-3810N. In at least one embodiment, slices 3801A-3801N can include a set of additional function units (“AFUs”) 3812A-3812N, floating-point units (“FPUs”) 3814A-3814N, integer arithmetic logic units (“ALUs”) 3816-3816N, address computational units (“ACUs”) 3813A-3813N, double-precision floating-point units (“DPFPUs”) 3815A-3815N, and matrix processing units (“MPUs”) 3817A-3817N. In at least one embodiment, a graphics core 3800 is referred to as a compute unit or computing unit.

[0470] In at least one embodiment, FPUs 3814A-3814N can perform single-precision (32-bit) and half-precision (16-bit) floating point operations, while DPFPUs 3815A-3815N perform double precision (64-bit) floating point operations. In at least one embodiment, ALUs 3816A-3816N can perform variable precision integer operations at 8-bit, 16-bit, and 32-bit precision, and can be configured for mixed precision operations. In at least one embodiment, MPUs 3817A-3817N can also be configured for mixed precision matrix operations, including half-precision floating point and 8-bit integer operations. In at least one embodiment, MPUs 3817-3817N can perform a variety of matrix operations to accelerate CUDA programs, including enabling support for accelerated general matrix to matrix multiplication (“GEMM”). In at least one embodiment, AFUs 3812A-3812N can perform additional logic operations not supported by floating-point or integer units, including trigonometric operations (e.g., Sine, Cosine, etc.).

[0471] FIG. 38B illustrates a general-purpose graphics processing unit (“GPGPU”) 3830, in accordance with at least one embodiment. In at least one embodiment, GPGPU 3830 is highly-parallel and suitable for deployment on a multi-chip module. In at least one embodiment, GPGPU 3830 can be configured to enable highly-parallel compute operations to be performed by an array of GPUs. In at least one embodiment, GPGPU 3830 can be linked directly to other instances of GPGPU 3830 to create a multi-GPU cluster to improve execution time for CUDA programs. In at least one embodiment, GPGPU 3830 includes a host interface 3832 to enable a connection with a host processor. In at least one embodiment, host interface 3832 is a PCIe interface. In at least one embodiment, host interface 3832 can be a vendor specific communications interface or communications fabric. In at least one embodiment, GPGPU 3830 receives commands from a host processor and uses a global scheduler 3834 to distribute execution threads associated with those commands to a set of compute clusters 3836A-3836H. In at least one embodiment, compute clusters 3836A-3836H share a cache memory 3838. In at least one embodiment, cache memory 3838 can serve as a higher-level cache for cache memories within compute clusters 3836A-3836H.

[0472] In at least one embodiment, GPGPU 3830 includes memory 3844A-3844B coupled with compute clusters 3836A-3836H via a set of memory controllers 3842A-3842B. In at least one embodiment, memory 3844A-3844B can include various types of memory devices including DRAM or graphics random access memory, such as synchronous graphics random access memory (“SGRAM”), including graphics double data rate (“GDDR”) memory.

[0473] In at least one embodiment, compute clusters 3836A-3836H each include a set of graphics cores, such as graphics core 3800 of FIG. 38A, which can include multiple types of integer and floating point logic units that can perform computational operations at a range of precisions including suited for computations associated with CUDA programs. For example, in at least one embodiment, at least a subset of floating point units in each of compute clusters 3836A-3836H can be configured to perform 16-bit or 32-bit floating point operations, while a different subset of floating point units can be configured to perform 64-bit floating point operations.

[0474] In at least one embodiment, multiple instances of GPGPU 3830 can be configured to operate as a compute cluster. Compute clusters 3836A-3836H may implement any technically feasible communication techniques for synchronization and data exchange. In at least one embodiment, multiple instances of GPGPU 3830 communicate over host interface 3832. In at least one embodiment, GPGPU 3830 includes an I/O hub 3839 that couples GPGPU 3830 with a GPU link 3840 that enables a direct connection to other instances of GPGPU 3830. In at least one embodiment, GPU link 3840 is coupled to a dedicated GPU-to-GPU bridge that enables communication and synchronization between multiple instances of GPGPU 3830. In at least one embodiment GPU link 3840 couples with a high speed interconnect to transmit and receive data to other GPGPUs 3830 or parallel processors. In at least one embodiment, multiple instances of GPGPU 3830 are located in separate data processing systems and communicate via a network device that is accessible via host interface 3832. In at least one embodiment GPU link 3840 can be configured to enable a connection to a host processor in addition to or as an alternative to host interface 3832. In at least one embodiment, GPGPU 3830 can be configured to execute a CUDA program.

[0475] In at least one embodiment, at least one component shown or described with respect to FIG. 38 is utilized to implement techniques and/or functions described in connection with FIGS. 1-27. In at least one embodiment, at least one component of FIG. 38 is used to identify, generate, remove, process, and/or modify one or more graph dependencies. In at least one embodiment, at least one component of FIG. 38 performs at least one aspect described with respect to graph 102, edge information 110, edge information 112, graph create 120 and/or graph create 122 of FIG. 1, node dependencies 300 of FIG. 3, dependency edge information 400 of FIG. 4, edge information 500 of FIG. 5, operation 600-2600 of FIGS. 6-26, and/or processor 2700 of FIG. 27.

[0476] FIG. 39A illustrates a parallel processor 3900, in accordance with at least one embodiment. In at least one embodiment, various components of parallel processor 3900 may be implemented using one or more integrated circuit devices, such as programmable processors, application specific integrated circuits (“ASICs”), or FPGAs.

[0477] In at least one embodiment, parallel processor 3900 includes a parallel processing unit 3902. In at least one embodiment, parallel processing unit 3902 includes an I/O unit 3904 that enables communication with other devices, including other instances of parallel processing unit 3902. In at least one embodiment, I/O unit 3904 may be directly connected to other devices. In at least one embodiment, I/O unit 3904 connects with other devices via use of a hub or switch interface, such as memory hub 3905. In at least one embodiment, connections between memory hub 3905 and I/O unit 3904 form a communication link. In at least one embodiment, I/O unit 3904 connects with a host interface 3906 and a memory crossbar 3916, where host interface 3906 receives commands directed to performing processing operations and memory crossbar 3916 receives commands directed to performing memory operations.

[0478] In at least one embodiment, when host interface 3906 receives a command buffer via I/O unit 3904, host interface 3906 can direct work operations to perform those commands to a front end 3908. In at least one embodiment, front end 3908 couples with a scheduler 3910, which is configured to distribute commands or other work items to a processing array 3912. In at least one embodiment, scheduler 3910 ensures that processing array 3912 is properly configured and in a valid state before tasks are distributed to processing array 3912. In at least one embodiment, scheduler 3910 is implemented via firmware logic executing on a microcontroller. In at least one embodiment, microcontroller implemented scheduler 3910 is configurable to perform complex scheduling and work distribution operations at coarse and fine granularity, enabling rapid preemption and context switching of threads executing on processing array 3912. In at least one embodiment, host software can prove workloads for scheduling on processing array 3912 via one of multiple graphics processing doorbells. In at least one embodiment, workloads can then be automatically distributed across processing array 3912 by scheduler 3910 logic within a microcontroller including scheduler 3910.

[0479] In at least one embodiment, processing array 3912 can include up to “N” clusters (e.g., cluster 3914A, cluster 3914B, through cluster 3914N). In at least one embodiment, each cluster 3914A-3914N of processing array 3912 can execute a large number of concurrent threads. In at least one embodiment, scheduler 3910 can allocate work to clusters 3914A-3914N of processing array 3912 using various scheduling and/or work distribution algorithms, which may vary depending on the workload arising for each type of program or computation. In at least one embodiment, scheduling can be handled dynamically by scheduler 3910, or can be assisted in part by compiler logic during compilation of program logic configured for execution by processing array 3912. In at least one embodiment, different clusters 3914A-3914N of processing array 3912 can be allocated for processing different types of programs or for performing different types of computations.

[0480] In at least one embodiment, processing array 3912 can be configured to perform various types of parallel processing operations. In at least one embodiment, processing array 3912 is configured to perform general-purpose parallel compute operations. For example, in at least one embodiment, processing array 3912 can include logic to execute processing tasks including filtering of video and/or audio data, performing modeling operations, including physics operations, and performing data transformations.

[0481] In at least one embodiment, processing array 3912 is configured to perform parallel graphics processing operations. In at least one embodiment, processing array 3912 can include additional logic to support execution of such graphics processing operations, including, but not limited to texture sampling logic to perform texture operations, as well as tessellation logic and other vertex processing logic. In at least one embodiment, processing array 3912 can be configured to execute graphics processing related shader programs such as, but not limited to vertex shaders, tessellation shaders, geometry shaders, and pixel shaders. In at least one embodiment, parallel processing unit 3902 can transfer data from system memory via I/O unit 3904 for processing. In at least one embodiment, during processing, transferred data can be stored to on-chip memory (e.g., a parallel processor memory 3922) during processing, then written back to system memory.

[0482] In at least one embodiment, when parallel processing unit 3902 is used to perform graphics processing, scheduler 3910 can be configured to divide a processing workload into approximately equal sized tasks, to better enable distribution of graphics processing operations to multiple clusters 3914A-3914N of processing array 3912. In at least one embodiment, portions of processing array 3912 can be configured to perform different types of processing. For example, in at least one embodiment, a first portion may be configured to perform vertex shading and topology generation, a second portion may be configured to perform tessellation and geometry shading, and a third portion may be configured to perform pixel shading or other screen space operations, to produce a rendered image for display. In at least one embodiment, intermediate data produced by one or more of clusters 3914A-3914N may be stored in buffers to allow intermediate data to be transmitted between clusters 3914A-3914N for further processing.

[0483] In at least one embodiment, processing array 3912 can receive processing tasks to be executed via scheduler 3910, which receives commands defining processing tasks from front end 3908. In at least one embodiment, processing tasks can include indices of data to be processed, e.g., surface (patch) data, primitive data, vertex data, and/or pixel data, as well as state parameters and commands defining how data is to be processed (e.g., what program is to be executed). In at least one embodiment, scheduler 3910 may be configured to fetch indices corresponding to tasks or may receive indices from front end 3908. In at least one embodiment, front end 3908 can be configured to ensure processing array 3912 is configured to a valid state before a workload specified by incoming command buffers (e.g., batch-buffers, push buffers, etc.) is initiated.

[0484] In at least one embodiment, each of one or more instances of parallel processing unit 3902 can couple with parallel processor memory 3922. In at least one embodiment, parallel processor memory 3922 can be accessed via memory crossbar 3916, which can receive memory requests from processing array 3912 as well as I/O unit 3904. In at least one embodiment, memory crossbar 3916 can access parallel processor memory 3922 via a memory interface 3918. In at least one embodiment, memory interface 3918 can include multiple partition units (e.g., a partition unit 3920A, partition unit 3920B, through partition unit 3920N) that can each couple to a portion (e.g., memory unit) of parallel processor memory 3922. In at least one embodiment, a number of partition units 3920A-3920N is configured to be equal to a number of memory units, such that a first partition unit 3920A has a corresponding first memory unit 3924A, a second partition unit 3920B has a corresponding memory unit 3924B, and an Nth partition unit 3920N has a corresponding Nth memory unit 3924N. In at least one embodiment, a number of partition units 3920A-3920N may not be equal to a number of memory devices.

[0485] In at least one embodiment, memory units 3924A-3924N can include various types of memory devices, including DRAM or graphics random access memory, such as SGRAM, including GDDR memory. In at least one embodiment, memory units 3924A-3924N may also include 3D stacked memory, including but not limited to high bandwidth memory (“HBM”). In at least one embodiment, render targets, such as frame buffers or texture maps may be stored across memory units 3924A-3924N, allowing partition units 3920A-3920N to write portions of each render target in parallel to efficiently use available bandwidth of parallel processor memory 3922. In at least one embodiment, a local instance of parallel processor memory 3922 may be excluded in favor of a unified memory design that utilizes system memory in conjunction with local cache memory.

[0486] In at least one embodiment, any one of clusters 3914A-3914N of processing array 3912 can process data that will be written to any of memory units 3924A-3924N within parallel processor memory 3922. In at least one embodiment, memory crossbar 3916 can be configured to transfer an output of each cluster 3914A-3914N to any partition unit 3920A-3920N or to another cluster 3914A-3914N, which can perform additional processing operations on an output. In at least one embodiment, each cluster 3914A-3914N can communicate with memory interface 3918 through memory crossbar 3916 to read from or write to various external memory devices. In at least one embodiment, memory crossbar 3916 has a connection to memory interface 3918 to communicate with I/O unit 3904, as well as a connection to a local instance of parallel processor memory 3922, enabling processing units within different clusters 3914A-3914N to communicate with system memory or other memory that is not local to parallel processing unit 3902. In at least one embodiment, memory crossbar 3916 can use virtual channels to separate traffic streams between clusters 3914A-3914N and partition units 3920A-3920N.

[0487] In at least one embodiment, multiple instances of parallel processing unit 3902 can be provided on a single add-in card, or multiple add-in cards can be interconnected. In at least one embodiment, different instances of parallel processing unit 3902 can be configured to interoperate even if different instances have different numbers of processing cores, different amounts of local parallel processor memory, and/or other configuration differences. For example, in at least one embodiment, some instances of parallel processing unit 3902 can include higher precision floating point units relative to other instances. In at least one embodiment, systems incorporating one or more instances of parallel processing unit 3902 or parallel processor 3900 can be implemented in a variety of configurations and form factors, including but not limited to desktop, laptop, or handheld personal computers, servers, workstations, game consoles, and/or embedded systems.

[0488] FIG. 39B illustrates a processing cluster 3994, in accordance with at least one embodiment. In at least one embodiment, processing cluster 3994 is included within a parallel processing unit. In at least one embodiment, processing cluster 3994 is one of processing clusters 3914A-3914N of FIG. 39. In at least one embodiment, processing cluster 3994 can be configured to execute many threads in parallel, where the term “thread” refers to an instance of a particular program executing on a particular set of input data. In at least one embodiment, single instruction, multiple data (“SIMD”) instruction issue techniques are used to support parallel execution of a large number of threads without providing multiple independent instruction units. In at least one embodiment, single instruction, multiple thread (“SIMT”) techniques are used to support parallel execution of a large number of generally synchronized threads, using a common instruction unit configured to issue instructions to a set of processing engines within each processing cluster 3994.

[0489] In at least one embodiment, operation of processing cluster 3994 can be controlled via a pipeline manager 3932 that distributes processing tasks to SIMT parallel processors. In at least one embodiment, pipeline manager 3932 receives instructions from scheduler 3910 of FIG. 39 and manages execution of those instructions via a graphics multiprocessor 3934 and/or a texture unit 3936. In at least one embodiment, graphics multiprocessor 3934 is an exemplary instance of a SIMT parallel processor. However, in at least one embodiment, various types of SIMT parallel processors of differing architectures may be included within processing cluster 3994. In at least one embodiment, one or more instances of graphics multiprocessor 3934 can be included within processing cluster 3994. In at least one embodiment, graphics multiprocessor 3934 can process data and a data crossbar 3940 can be used to distribute processed data to one of multiple possible destinations, including other shader units. In at least one embodiment, pipeline manager 3932 can facilitate distribution of processed data by specifying destinations for processed data to be distributed via data crossbar 3940.

[0490] In at least one embodiment, each graphics multiprocessor 3934 within processing cluster 3994 can include an identical set of functional execution logic (e.g., arithmetic logic units, load/store units (“LSUs”), etc.). In at least one embodiment, functional execution logic can be configured in a pipelined manner in which new instructions can be issued before previous instructions are complete. In at least one embodiment, functional execution logic supports a variety of operations including integer and floating point arithmetic, comparison operations, Boolean operations, bit-shifting, and computation of various algebraic functions. In at least one embodiment, same functional-unit hardware can be leveraged to perform different operations and any combination of functional units may be present.

[0491] In at least one embodiment, instructions transmitted to processing cluster 3994 constitute a thread. In at least one embodiment, a set of threads executing across a set of parallel processing engines is a thread group. In at least one embodiment, a thread group executes a program on different input data. In at least one embodiment, each thread within a thread group can be assigned to a different processing engine within graphics multiprocessor 3934. In at least one embodiment, a thread group may include fewer threads than a number of processing engines within graphics multiprocessor 3934. In at least one embodiment, when a thread group includes fewer threads than a number of processing engines, one or more of the processing engines may be idle during cycles in which that thread group is being processed. In at least one embodiment, a thread group may also include more threads than a number of processing engines within graphics multiprocessor 3934. In at least one embodiment, when a thread group includes more threads than the number of processing engines within graphics multiprocessor 3934, processing can be performed over consecutive clock cycles. In at least one embodiment, multiple thread groups can be executed concurrently on graphics multiprocessor 3934.

[0492] In at least one embodiment, graphics multiprocessor 3934 includes an internal cache memory to perform load and store operations. In at least one embodiment, graphics multiprocessor 3934 can forego an internal cache and use a cache memory (e.g., L1 cache 3948) within processing cluster 3994. In at least one embodiment, each graphics multiprocessor 3934 also has access to Level 2 (“L2”) caches within partition units (e.g., partition units 3920A-3920N of FIG. 39A) that are shared among all processing clusters 3994 and may be used to transfer data between threads. In at least one embodiment, graphics multiprocessor 3934 may also access off-chip global memory, which can include one or more of local parallel processor memory and/or system memory. In at least one embodiment, any memory external to parallel processing unit 3902 may be used as global memory. In at least one embodiment, processing cluster 3994 includes multiple instances of graphics multiprocessor 3934 that can share common instructions and data, which may be stored in L1 cache 3948.

[0493] In at least one embodiment, each processing cluster 3994 may include an MMU 3945 that is configured to map virtual addresses into physical addresses. In at least one embodiment, one or more instances of MMU 3945 may reside within memory interface 3918 of FIG. 39. In at least one embodiment, MMU 3945 includes a set of page table entries (“PTEs”) used to map a virtual address to a physical address of a tile and optionally a cache line index. In at least one embodiment, MMU 3945 may include address translation lookaside buffers (“TLBs”) or caches that may reside within graphics multiprocessor 3934 or L1 cache 3948 or processing cluster 3994. In at least one embodiment, a physical address is processed to distribute surface data access locality to allow efficient request interleaving among partition units. In at least one embodiment, a cache line index may be used to determine whether a request for a cache line is a hit or miss.

[0494] In at least one embodiment, processing cluster 3994 may be configured such that each graphics multiprocessor 3934 is coupled to a texture unit 3936 for performing texture mapping operations, e.g., determining texture sample positions, reading texture data, and filtering texture data. In at least one embodiment, texture data is read from an internal texture L1 cache (not shown) or from an L1 cache within graphics multiprocessor 3934 and is fetched from an L2 cache, local parallel processor memory, or system memory, as needed. In at least one embodiment, each graphics multiprocessor 3934 outputs a processed task to data crossbar 3940 to provide the processed task to another processing cluster 3994 for further processing or to store the processed task in an L2 cache, a local parallel processor memory, or a system memory via memory crossbar 3916. In at least one embodiment, a pre-raster operations unit (“preROP”) 3942 is configured to receive data from graphics multiprocessor 3934, direct data to ROP units, which may be located with partition units as described herein (e.g., partition units 3920A-3920N of FIG. 39). In at least one embodiment, PreROP 3942 can perform optimizations for color blending, organize pixel color data, and perform address translations.

[0495] FIG. 39C illustrates a graphics multiprocessor 3996, in accordance with at least one embodiment. In at least one embodiment, graphics multiprocessor 3996 is graphics multiprocessor 3934 of FIG. 39B. In at least one embodiment, graphics multiprocessor 3996 couples with pipeline manager 3932 of processing cluster 3994. In at least one embodiment, graphics multiprocessor 3996 has an execution pipeline including but not limited to an instruction cache 3952, an instruction unit 3954, an address mapping unit 3956, a register file 3958, one or more GPGPU cores 3962, and one or more LSUs 3966. GPGPU cores 3962 and LSUs 3966 are coupled with cache memory 3972 and shared memory 3970 via a memory and cache interconnect 3968.

[0496] In at least one embodiment, instruction cache 3952 receives a stream of instructions to execute from pipeline manager 3932. In at least one embodiment, instructions are cached in instruction cache 3952 and dispatched for execution by instruction unit 3954. In at least one embodiment, instruction unit 3954 can dispatch instructions as thread groups (e.g., warps), with each thread of a thread group assigned to a different execution unit within GPGPU core 3962. In at least one embodiment, an instruction can access any of a local, shared, or global address space by specifying an address within a unified address space. In at least one embodiment, address mapping unit 3956 can be used to translate addresses in a unified address space into a distinct memory address that can be accessed by LSUs 3966.

[0497] In at least one embodiment, register file 3958 provides a set of registers for functional units of graphics multiprocessor 3996. In at least one embodiment, register file 3958 provides temporary storage for operands connected to data paths of functional units (e.g., GPGPU cores 3962, LSUs 3966) of graphics multiprocessor 3996. In at least one embodiment, register file 3958 is divided between each of functional units such that each functional unit is allocated a dedicated portion of register file 3958. In at least one embodiment, register file 3958 is divided between different thread groups being executed by graphics multiprocessor 3996.

[0498] In at least one embodiment, GPGPU cores 3962 can each include FPUs and/or integer ALUs that are used to execute instructions of graphics multiprocessor 3996. GPGPU cores 3962 can be similar in architecture or can differ in architecture. In at least one embodiment, a first portion of GPGPU cores 3962 include a single precision FPU and an integer ALU while a second portion of GPGPU cores 3962 include a double precision FPU. In at least one embodiment, FPUs can implement IEEE 754-2008 standard for floating point arithmetic or enable variable precision floating point arithmetic. In at least one embodiment, graphics multiprocessor 3996 can additionally include one or more fixed function or special function units to perform specific functions such as copy rectangle or pixel blending operations. In at least one embodiment one or more of GPGPU cores 3962 can also include fixed or special function logic.

[0499] In at least one embodiment, GPGPU cores 3962 include SIMD logic capable of performing a single instruction on multiple sets of data. In at least one embodiment GPGPU cores 3962 can physically execute SIMD4, SIMD8, and SIMD16 instructions and logically execute SIMD1, SIMD2, and SIMD32 instructions. In at least one embodiment, SIMD instructions for GPGPU cores 3962 can be generated at compile time by a shader compiler or automatically generated when executing programs written and compiled for single program multiple data (“SPMD”) or SIMT architectures. In at least one embodiment, multiple threads of a program configured for an SIMT execution model can executed via a single SIMD instruction. For example, in at least one embodiment, eight SIMT threads that perform the same or similar operations can be executed in parallel via a single SIMD8 logic unit.

[0500] In at least one embodiment, memory and cache interconnect 3968 is an interconnect network that connects each functional unit of graphics multiprocessor 3996 to register file 3958 and to shared memory 3970. In at least one embodiment, memory and cache interconnect 3968 is a crossbar interconnect that allows LSU 3966 to implement load and store operations between shared memory 3970 and register file 3958. In at least one embodiment, register file 3958 can operate at a same frequency as GPGPU cores 3962, thus data transfer between GPGPU cores 3962 and register file 3958 is very low latency. In at least one embodiment, shared memory 3970 can be used to enable communication between threads that execute on functional units within graphics multiprocessor 3996. In at least one embodiment, cache memory 3972 can be used as a data cache for example, to cache texture data communicated between functional units and texture unit 3936. In at least one embodiment, shared memory 3970 can also be used as a program managed cached. In at least one embodiment, threads executing on GPGPU cores 3962 can programmatically store data within shared memory in addition to automatically cached data that is stored within cache memory 3972.

[0501] In at least one embodiment, a parallel processor or GPGPU as described herein is communicatively coupled to host/processor cores to accelerate graphics operations, machine-learning operations, pattern analysis operations, and various general purpose GPU (GPGPU) functions. In at least one embodiment, a GPU may be communicatively coupled to host processor/cores over a bus or other interconnect (e.g., a high speed interconnect such as PCIe or NVLink). In at least one embodiment, a GPU may be integrated on the same package or chip as cores and communicatively coupled to cores over a processor bus/interconnect that is internal to a package or a chip. In at least one embodiment, regardless of the manner in which a GPU is connected, processor cores may allocate work to the GPU in the form of sequences of commands/instructions contained in a WD. In at least one embodiment, the GPU then uses dedicated circuitry/logic for efficiently processing these commands/instructions.

[0502] In at least one embodiment, at least one component shown or described with respect to FIG. 40 is utilized to implement techniques and/or functions described in connection with FIGS. 1-27. In at least one embodiment, at least one component of FIG. 40 is used to identify, generate, remove, process, and/or modify one or more graph dependencies. In at least one embodiment, at least one component of FIG. 40 performs at least one aspect described with respect to graph 102, edge information 110, edge information 112, graph create 120 and/or graph create 122 of FIG. 1, node dependencies 300 of FIG. 3, dependency edge information 400 of FIG. 4, edge information 500 of FIG. 5, operations 600-2600 of FIGS. 6-26, and/or processor 2700 of FIG. 27.

[0503] FIG. 40 illustrates a graphics processor 4000, in accordance with at least one embodiment. In at least one embodiment, graphics processor 4000 includes a ring interconnect 4002, a pipeline front-end 4004, a media engine 4037, and graphics cores 4080A-4080N. In at least one embodiment, ring interconnect 4002 couples graphics processor 4000 to other processing units, including other graphics processors or one or more general-purpose processor cores. In at least one embodiment, graphics processor 4000 is one of many processors integrated within a multi-core processing system.

[0504] In at least one embodiment, graphics processor 4000 receives batches of commands via ring interconnect 4002. In at least one embodiment, incoming commands are interpreted by a command streamer 4003 in pipeline front-end 4004. In at least one embodiment, graphics processor 4000 includes scalable execution logic to perform 3D geometry processing and media processing via graphics core(s) 4080A-4080N. In at least one embodiment, for 3D geometry processing commands, command streamer 4003 supplies commands to geometry pipeline 4036. In at least one embodiment, for at least some media processing commands, command streamer 4003 supplies commands to a video front end 4034, which couples with a media engine 4037. In at least one embodiment, media engine 4037 includes a Video Quality Engine (“VQE”) 4030 for video and image post-processing and a multi-format encode/decode (“MFX”) engine 4033 to provide hardware-accelerated media data encode and decode. In at least one embodiment, geometry pipeline 4036 and media engine 4037 each generate execution threads for thread execution resources provided by at least one graphics core 4080A.

[0505] In at least one embodiment, graphics processor 4000 includes scalable thread execution resources featuring modular graphics cores 4080A-4080N (sometimes referred to as core slices), each having multiple sub-cores 4050A-550N, 4060A-4060N (sometimes referred to as core sub-slices). In at least one embodiment, graphics processor 4000 can have any number of graphics cores 4080A through 4080N. In at least one embodiment, graphics processor 4000 includes a graphics core 4080A having at least a first sub-core 4050A and a second sub-core 4060A. In at least one embodiment, graphics processor 4000 is a low power processor with a single sub-core (e.g., sub-core 4050A). In at least one embodiment, graphics processor 4000 includes multiple graphics cores 4080A-4080N, each including a set of first sub-cores 4050A-4050N and a set of second sub-cores 4060A-4060N. In at least one embodiment, each sub-core in first sub-cores 4050A-4050N includes at least a first set of execution units (“EUs”) 4052A-4052N and media/texture samplers 4054A-4054N. In at least one embodiment, each sub-core in second sub-cores 4060A-4060N includes at least a second set of execution units 4062A-4062N and samplers 4064A-4064N. In at least one embodiment, each sub-core 4050A-4050N, 4060A-4060N shares a set of shared resources 4070A-4070N. In at least one embodiment, shared resources 4070 include shared cache memory and pixel operation logic.

[0506] FIG. 41 illustrates a processor 4100, in accordance with at least one embodiment. In at least one embodiment, processor 4100 may include, without limitation, logic circuits to perform instructions. In at least one embodiment, processor 4100 may perform instructions, including x86 instructions, ARM instructions, specialized instructions for ASICs, etc. In at least one embodiment, processor 4110 may include registers to store packed data, such as 64-bit wide MMX™ registers in microprocessors enabled with MMX technology from Intel Corporation of Santa Clara, Calif. In at least one embodiment, MMX registers, available in both integer and floating point forms, may operate with packed data elements that accompany SIMD and streaming SIMD extensions (“SSE”) instructions. In at least one embodiment, 128-bit wide XMM registers relating to SSE2, SSE3, SSE4, AVX, or beyond (referred to generically as “SSEx”) technology may hold such packed data operands. In at least one embodiment, processors 4110 may perform instructions to accelerate CUDA programs.

[0507] In at least one embodiment, processor 4100 includes an in-order front end (“front end”) 4101 to fetch instructions to be executed and prepare instructions to be used later in processor pipeline. In at least one embodiment, front end 4101 may include several units. In at least one embodiment, an instruction prefetcher 4126 fetches instructions from memory and feeds instructions to an instruction decoder 4128 which in turn decodes or interprets instructions. For example, in at least one embodiment, instruction decoder 4128 decodes a received instruction into one or more operations called “micro-instructions” or “micro-operations” (also called “micro ops” or “uops”) for execution. In at least one embodiment, instruction decoder 4128 parses instruction into an opcode and corresponding data and control fields that may be used by micro-architecture to perform operations. In at least one embodiment, a trace cache 4130 may assemble decoded uops into program ordered sequences or traces in a uop queue 4134 for execution. In at least one embodiment, when trace cache 4130 encounters a complex instruction, a microcode ROM 4132 provides uops needed to complete an operation.

[0508] In at least one embodiment, some instructions may be converted into a single micro-op, whereas others need several micro-ops to complete full operation. In at least one embodiment, if more than four micro-ops are needed to complete an instruction, instruction decoder 4128 may access microcode ROM 4132 to perform instruction. In at least one embodiment, an instruction may be decoded into a small number of micro-ops for processing at instruction decoder 4128. In at least one embodiment, an instruction may be stored within microcode ROM 4132 should a number of micro-ops be needed to accomplish operation. In at least one embodiment, trace cache 4130 refers to an entry point programmable logic array (“PLA”) to determine a correct micro-instruction pointer for reading microcode sequences to complete one or more instructions from microcode ROM 4132. In at least one embodiment, after microcode ROM 4132 finishes sequencing micro-ops for an instruction, front end 4101 of machine may resume fetching micro-ops from trace cache 4130.

[0509] In at least one embodiment, out-of-order execution engine (“out of order engine”) 4103 may prepare instructions for execution. In at least one embodiment, out-of-order execution logic has a number of buffers to smooth out and re-order the flow of instructions to optimize performance as they go down a pipeline and get scheduled for execution. Out-of-order execution engine 4103 includes, without limitation, an allocator/register renamer 4140, a memory uop queue 4142, an integer/floating point uop queue 4144, a memory scheduler 4146, a fast scheduler 4102, a slow/general floating point scheduler (“slow/general FP scheduler”) 4104, and a simple floating point scheduler (“simple FP scheduler”) 4106. In at least one embodiment, fast schedule 4102, slow/general floating point scheduler 4104, and simple floating point scheduler 4106 are also collectively referred to herein as “uop schedulers 4102, 4104, 4106.” Allocator/register renamer 4140 allocates machine buffers and resources that each uop needs in order to execute. In at least one embodiment, allocator/register renamer 4140 renames logic registers onto entries in a register file. In at least one embodiment, allocator/register renamer 4140 also allocates an entry for each uop in one of two uop queues, memory uop queue 4142 for memory operations and integer/floating point uop queue 4144 for non-memory operations, in front of memory scheduler 4146 and uop schedulers 4102, 4104, 4106. In at least one embodiment, uop schedulers 4102, 4104, 4106, determine when a uop is ready to execute based on readiness of their dependent input register operand sources and availability of execution resources uops need to complete their operation. In at least one embodiment, fast scheduler 4102 of at least one embodiment may schedule on each half of main clock cycle while slow/general floating point scheduler 4104 and simple floating point scheduler 4106 may schedule once per main processor clock cycle. In at least one embodiment, uop schedulers 4102, 4104, 4106 arbitrate for dispatch ports to schedule uops for execution.

[0510] In at least one embodiment, execution block 4111 includes, without limitation, an integer register file/bypass network 4108, a floating point register file/bypass network (“FP register file/bypass network”) 4110, address generation units (“AGUs”) 4112 and 4114, fast ALUs 4116 and 4118, a slow ALU 4120, a floating point ALU (“FP”) 4122, and a floating point move unit (“FP move”) 4124. In at least one embodiment, integer register file/bypass network 4108 and floating point register file/bypass network 4110 are also referred to herein as “register files 4108, 4110.” In at least one embodiment, AGUSs 4112 and 4114, fast ALUs 4116 and 4118, slow ALU 4120, floating point ALU 4122, and floating point move unit 4124 are also referred to herein as “execution units 4112, 4114, 4116, 4118, 4120, 4122, and 4124.” In at least one embodiment, an execution block may include, without limitation, any number (including zero) and type of register files, bypass networks, address generation units, and execution units, in any combination.

[0511] In at least one embodiment, register files 4108, 4110 may be arranged between uop schedulers 4102, 4104, 4106, and execution units 4112, 4114, 4116, 4118, 4120, 4122, and 4124. In at least one embodiment, integer register file/bypass network 4108 performs integer operations. In at least one embodiment, floating point register file/bypass network 4110 performs floating point operations. In at least one embodiment, each of register files 4108, 4110 may include, without limitation, a bypass network that may bypass or forward just completed results that have not yet been written into register file to new dependent uops. In at least one embodiment, register files 4108, 4110 may communicate data with each other. In at least one embodiment, integer register file/bypass network 4108 may include, without limitation, two separate register files, one register file for low-order thirty-two bits of data and a second register file for high order thirty-two bits of data. In at least one embodiment, floating point register file/bypass network 4110 may include, without limitation, 128-bit wide entries because floating point instructions typically have operands from 64 to 128 bits in width.

[0512] In at least one embodiment, execution units 4112, 4114, 4116, 4118, 4120, 4122, 4124 may execute instructions. In at least one embodiment, register files 4108, 4110 store integer and floating point data operand values that micro-instructions need to execute. In at least one embodiment, processor 4100 may include, without limitation, any number and combination of execution units 4112, 4114, 4116, 4118, 4120, 4122, 4124. In at least one embodiment, floating point ALU 4122 and floating point move unit 4124 may execute floating point, MMX, SIMD, AVX and SSE, or other operations. In at least one embodiment, floating point ALU 4122 may include, without limitation, a 64-bit by 64-bit floating point divider to execute divide, square root, and remainder micro ops. In at least one embodiment, instructions involving a floating point value may be handled with floating point hardware. In at least one embodiment, ALU operations may be passed to fast ALUs 4116, 4118. In at least one embodiment, fast ALUS 4116, 4118 may execute fast operations with an effective latency of half a clock cycle. In at least one embodiment, most complex integer operations go to slow ALU 4120 as slow ALU 4120 may include, without limitation, integer execution hardware for long-latency type of operations, such as a multiplier, shifts, flag logic, and branch processing. In at least one embodiment, memory load/store operations may be executed by AGUs 4112, 4114. In at least one embodiment, fast ALU 4116, fast ALU 4118, and slow ALU 4120 may perform integer operations on 64-bit data operands. In at least one embodiment, fast ALU 4116, fast ALU 4118, and slow ALU 4120 may be implemented to support a variety of data bit sizes including sixteen, thirty-two, 128, 256, etc. In at least one embodiment, floating point ALU 4122 and floating point move unit 4124 may be implemented to support a range of operands having bits of various widths. In at least one embodiment, floating point ALU 4122 and floating point move unit 4124 may operate on 128-bit wide packed data operands in conjunction with SIMD and multimedia instructions.

[0513] In at least one embodiment, uop schedulers 4102, 4104, 4106 dispatch dependent operations before parent load has finished executing. In at least one embodiment, as uops may be speculatively scheduled and executed in processor 4100, processor 4100 may also include logic to handle memory misses. In at least one embodiment, if a data load misses in a data cache, there may be dependent operations in flight in pipeline that have left a scheduler with temporarily incorrect data. In at least one embodiment, a replay mechanism tracks and re-executes instructions that use incorrect data. In at least one embodiment, dependent operations might need to be replayed and independent ones may be allowed to complete. In at least one embodiment, schedulers and replay mechanisms of at least one embodiment of a processor may also be designed to catch instruction sequences for text string comparison operations.

[0514] In at least one embodiment, the term “registers” may refer to on-board processor storage locations that may be used as part of instructions to identify operands. In at least one embodiment, registers may be those that may be usable from outside of a processor (from a programmer's perspective). In at least one embodiment, registers might not be limited to a particular type of circuit. Rather, in at least one embodiment, a register may store data, provide data, and perform functions described herein. In at least one embodiment, registers described herein may be implemented by circuitry within a processor using any number of different techniques, such as dedicated physical registers, dynamically allocated physical registers using register renaming, combinations of dedicated and dynamically allocated physical registers, etc. In at least one embodiment, integer registers store 32-bit integer data. A register file of at least one embodiment also contains eight multimedia SIMD registers for packed data.

[0515] In at least one embodiment, at least one component shown or described with respect to FIG. 41 is utilized to implement techniques and/or functions described in connection with FIGS. 1-27. In at least one embodiment, at least one component of FIG. 41 is used to identify, generate, remove, process, and/or modify one or more graph dependencies. In at least one embodiment, at least one component of FIG. 41 performs at least one aspect described with respect to graph 102, edge information 110, edge information 112, graph create 120 and/or graph create 122 of FIG. 1, node dependencies 300 of FIG. 3, dependency edge information 400 of FIG. 4, edge information 500 of FIG. 5, operations 600-2600 of FIGS. 6-26, and/or processor 2700 of FIG. 27.

[0516] FIG. 42 illustrates a processor 4200, in accordance with at least one embodiment. In at least one embodiment, processor 4200 includes, without limitation, one or more processor cores (“cores”) 4202A-4202N, an integrated memory controller 4214, and an integrated graphics processor 4208. In at least one embodiment, processor 4200 can include additional cores up to and including additional processor core 4202N represented by dashed lined boxes. In at least one embodiment, each of processor cores 4202A-4202N includes one or more internal cache units 4204A-4204N. In at least one embodiment, each processor core also has access to one or more shared cached units 4206. In at least one embodiment, one or more processor cores 4202A-4202N are referred to as one or more compute units or computing units.

[0517] In at least one embodiment, internal cache units 4204A-4204N and shared cache units 4206 represent a cache memory hierarchy within processor 4200. In at least one embodiment, cache memory units 4204A-4204N may include at least one level of instruction and data cache within each processor core and one or more levels of shared mid-level cache, such as an L2, L3, Level 4 (“L4”), or other levels of cache, where a highest level of cache before external memory is classified as an LLC. In at least one embodiment, cache coherency logic maintains coherency between various cache units 4206 and 4204A-4204N.

[0518] In at least one embodiment, processor 4200 may also include a set of one or more bus controller units 4216 and a system agent core 4210. In at least one embodiment, one or more bus controller units 4216 manage a set of peripheral buses, such as one or more PCI or PCI express buses. In at least one embodiment, system agent core 4210 provides management functionality for various processor components. In at least one embodiment, system agent core 4210 includes one or more integrated memory controllers 4214 to manage access to various external memory devices (not shown).

[0519] In at least one embodiment, one or more of processor cores 4202A-4202N include support for simultaneous multi-threading. In at least one embodiment, system agent core 4210 includes components for coordinating and operating processor cores 4202A-4202N during multi-threaded processing. In at least one embodiment, system agent core 4210 may additionally include a power control unit (“PCU”), which includes logic and components to regulate one or more power states of processor cores 4202A-4202N and graphics processor 4208.

[0520] In at least one embodiment, processor 4200 additionally includes graphics processor 4208 to execute graphics processing operations. In at least one embodiment, graphics processor 4208 couples with shared cache units 4206, and system agent core 4210, including one or more integrated memory controllers 4214. In at least one embodiment, system agent core 4210 also includes a display controller 4211 to drive graphics processor output to one or more coupled displays. In at least one embodiment, display controller 4211 may also be a separate module coupled with graphics processor 4208 via at least one interconnect, or may be integrated within graphics processor 4208.

[0521] In at least one embodiment, a ring based interconnect unit 4212 is used to couple internal components of processor 4200. In at least one embodiment, an alternative interconnect unit may be used, such as a point-to-point interconnect, a switched interconnect, or other techniques. In at least one embodiment, graphics processor 4208 couples with ring interconnect 4212 via an I/O link 4213.

[0522] In at least one embodiment, I/O link 4213 represents at least one of multiple varieties of I/O interconnects, including an on package I/O interconnect which facilitates communication between various processor components and a high-performance embedded memory module 4218, such as an eDRAM module. In at least one embodiment, each of processor cores 4202A-4202N and graphics processor 4208 use embedded memory modules 4218 as a shared LLC.

[0523] In at least one embodiment, processor cores 4202A-4202N are homogeneous cores executing a common instruction set architecture. In at least one embodiment, processor cores 4202A-4202N are heterogeneous in terms of ISA, where one or more of processor cores 4202A-4202N execute a common instruction set, while one or more other cores of processor cores 4202A-42-02N executes a subset of a common instruction set or a different instruction set. In at least one embodiment, processor cores 4202A-4202N are heterogeneous in terms of microarchitecture, where one or more cores having a relatively higher power consumption couple with one or more cores having a lower power consumption. In at least one embodiment, processor 4200 can be implemented on one or more chips or as an SoC integrated circuit.