-
Notifications
You must be signed in to change notification settings - Fork 699
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] Adding RuntimeTypes.h #2161
Changes from all commits
d1ad7ea
f00f8fa
2078cf6
514a459
e35408b
4f5acea
a7bfe84
b796396
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,67 @@ | ||
/** | ||
* Copyright (c) 2017-present, Facebook, Inc. | ||
* | ||
* Licensed under the Apache License, Version 2.0 (the "License"); | ||
* you may not use this file except in compliance with the License. | ||
* You may obtain a copy of the License at | ||
* | ||
* http://www.apache.org/licenses/LICENSE-2.0 | ||
* | ||
* Unless required by applicable law or agreed to in writing, software | ||
* distributed under the License is distributed on an "AS IS" BASIS, | ||
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | ||
* See the License for the specific language governing permissions and | ||
* limitations under the License. | ||
*/ | ||
#ifndef GLOW_RUNTIME_RUNTIMETYPES_H | ||
#define GLOW_RUNTIME_RUNTIMETYPES_H | ||
|
||
#include "glow/Backends/BackendUtils.h" | ||
#include "glow/Graph/Graph.h" | ||
|
||
#include <string> | ||
#include <unordered_map> | ||
#include <vector> | ||
|
||
namespace glow { | ||
namespace runtime { | ||
|
||
using NetworkIDty = size_t; | ||
using DeviceIDty = size_t; | ||
|
||
/// Enum to communicate results when communicating with device at initialization | ||
/// and runtime. | ||
enum ResultCode { READY, EXECUTED, FAILED, CANCELLED }; | ||
|
||
/// Data structure that contains device constraint information for each device. | ||
/// Used to communicate memory constraints and later costs to the Partitioner. | ||
struct DeviceInfo { | ||
/// Available memory on device in bytes. | ||
uint64_t availableMemory; | ||
}; | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For Partitioner, we need the DeviceInfo contains: memory, number of devices, later the communication constraints. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Would the communication contraints be at a system level or device level? The thought here is the Partitioner would be given a vector of these DeviceInfo objects, one per device. Number of devices would be the length of the vector. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. "Would the communication contraints be at a system level or device level?" There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You are correct, we don't need availableMemory right now for Partitioner, but it could be used for provisioner and potentially later in Partitioner. |
||
/// Individual Node in the DAG for a given network. This contains all the | ||
/// information needed to run the sub-network at inference time. | ||
struct DAGNode { | ||
/// The children of this node, these are nodes that depend on the current | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So, after graph partitioning, each function should have a DAGNode, right? Please correct me if I misunderstand something... If so, we should have some field in this struct to point the function ? or the "name" in DAGNode is the function name? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You are correct, name in the DAGNode is the function name. |
||
/// node. | ||
std::vector<DAGNode> children; | ||
/// Pointers to the parents of this node. This is used by the executor for | ||
/// determining if a given node has all dependencies met. | ||
std::vector<DAGNode *> parents; | ||
/// ID of the deviceManager that this network is assigned to. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The "children" is with the type of "std::vector" and "parents" is with the type of "std::vector<DAGNode*>". Actually, this would cause some complexity when creating the DAGNode. For each DAGNode of each sub-function, if we declare it as a local var, we have no idea how to push_back its pointer to its children's "parents" filed. If we new a DAGNode for each function, the "children" field is improper. After discussed with @gcatron , can we use "std::vector<DAGNode*> children;" instead of "std::vector children;", and add an Destructor of DAGNode? @nickgg |
||
DeviceIDty deviceID; | ||
/// The logicalDevice is an output of the Partitioner to indicate that two | ||
/// networks should be assigned to the same device. | ||
DeviceIDty logicalDevice; | ||
/// Name assigned to the sub-network, this is the id that will be passed to | ||
/// the DeviceManager when requesting a run of the network. | ||
std::string name; | ||
/// Runtime bundle containing all the symbol information for this network at | ||
/// runtime. | ||
RuntimeBundle runtimeBundle; | ||
}; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Each module contains its placeholder and constants. So what the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. They are for runtime, at runtime the modules are no longer around but the executor will need to know how to pass inputs and outputs when executing the network. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Removed from DependencyDAG, they will by generated by the HM and added to the executionDAG. |
||
|
||
} // namespace runtime | ||
} // namespace glow | ||
#endif // GLOW_RUNTIME_RUNTIMETYPES_H |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please run "format.sh fix"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Format.sh fix didn't change anything? Is it the indentation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I would like the indentation should be the consistent with the rest of file.