Every operator has many kernels because there are multiple data types, places, data layout that Fluid supports. We use the `KernelType` to describe kernel types that operators can hold.
Every operator has many kernels because there are multiple data types, places, data layout, library type that Fluid supports. We use the `OpKernelType ` to describe kernel types that operators can hold.
The `KernelType` is as follows.
The `OpKernelType ` is as follows:
```
struct KernelType {
```cpp
struct OpKernelType {
Place place_;
DataType data_type_;
LayoutType layout_;
DataLayout data_layout_;
LibraryType library_type_;
};
```
The `place_` is a descriptor of the device and the computational library, e.g., `MKLDNNPlace`, `CUDAPlace`.
- The `place_` is a descriptor of the device, e.g., CPUPlace, CUDAPlace.
The `data_type_` is the data type that this kernel performs on, e.g., `FP32`, `INT64`. Note that one kernel may have inputs with different data types. However, it will be a major `data_type`. For example, the `cross_entropy` takes `int64` as it label, and `double`/`float` as its input logit and output cost. The major `data_type` of `cross_entropy` is `float`/`double`.
- The `data_type_` is the data type that this kernel performs on, e.g., `FP32`, `INT64`. Note that one kernel may have inputs with different data types. However, it will be a major `data_type`. For example, the `cross_entropy` takes `int64` as it label, and `double`/`float` as its input logit and output cost. The major `data_type` of `cross_entropy` is `float` or `double`.
The `layout` is useful for some computational library. One example is that MKLDNN uses many kinds of layout, such as `nChw8c`. Each kind of layout will invoke the different kernel.
- The `data_layout_ ` is useful for some computational library. One example is that MKLDNN uses many kinds of layout, such as `nChw8c`. Each kind of layout will invoke the different kernel.
- The `library_type_` describes the computational library, e.g., `MKLDNN`, `CUDNN`.
## Problem
...
...
@@ -25,42 +28,72 @@ We register a kernel for every operator and every kernel type ideally. However,
2. Some operators will take too many memory. It is better to force them into CPU. However, the rest of operators in this neural network will be performed on GPU, i.e., model parallel problem.
3. Some layout and place are particular. One example is that MKLDNN uses `nChw8` and there is no other library uses `nChw8c`.
Problems under these situations are similar. We can formalise this problem as follow.
We register kernels with types $KT = \{kt_1, kt_2, kt_3, ...\}$ for one operator. The inputs of this operator should be run on kernel type $kt_{?}$, which the $kt_{?} \notin KT$. How to cast the input of this operator from $kt_{?}$ to any of kernel type in $KT$.
Take one situation to give a detailed explanation, if we have two Operators: OP1 and OP2, OP1 has one output `op1_to_op2`, and `op1_to_op2` is the input of OP2.
## Solution
If OP1 and OP2 run on the same place(for example CPUPlace), then `op1_2_op2` can be used directly by OP2.
It is clearly that transforming inputs of an operator toadapt another kernel type is not related to the particular operator. So we should register these transformation methods as global methods.
```
OP1(CPUPlace)
|
op1_2_op2
|
OP2(CPUPlace)
```
We can infer a kernel type from the inputs of an operators. We let this kernel type as `actual kernel type`, which means this kernel type is the actually kernel type that operator should be performed.
If OP1 and OP2 run one different place, then OP2 cannot `use op1_2_op2` directly.
We can get a kernel type by 1) The configuration of operator description. (Users may want to force use `MKL` for `conv` operator). 2) The place of the current executor. (Executor is running on GPU). This kernel type is what we expect the operator will be performed on. We let this kernel type as `expect kernel type`.
Problems under these situations are similar. We can formalize this problem as follow.
We transform the input data from `actual` to `expect` if the expect kernel type is not as same as actual kernel type.
We register kernels with types $KT = \{kt_1, kt_2, kt_3, ...\}$ for one operator. The inputs of this operator should be run on kernel type $kt_{?}$, which the $kt_{?} \notin KT$. How to cast the input of this operator from $kt_{?}$ to any of kernel type in $KT$.
The algorithm is described as follow
## Solution: data transform
```cpp
using DataTransformationFN = std::function<void(const Tensor& in, Tensor* out)>;
using KernelTypePair = std::pair<KernelType, KernelType>;
It is clear that transforming inputs of an operator to adapt another kernel type is not related to the particular operator. So we should register these transformation methods as global methods.
We can infer kernel type for each input of an operator. We let this kernel type as `actual kernel type for var`, which means this kernel type is the kernel type that can process this input variable.
void OpWithKernel::Run() {
vec<Tensor> inputs = ...
auto actual_kernel_type = GetActualKernelType(inputs);
We can get a kernel type by 1) The configuration of operator description. (Users may want to force use `MKL` for `conv` operator). 2) The place of the current executor. (Executor is running on GPU). This kernel type is what we expect the operator will be performed on. We let this kernel type as `expect kernel type`.
// The expected kernel type is related to actual kernel type.
// For the most operators, the expected kernel type is as same as
// actual kernel type.
//
// So we pass `actual_kernel_type` as a parameter of
// GetExpectedKernelType
auto expect_kernel_type = GetExpectedKernelType(actual_kernel_type);
We transform the input data from `actual` to `expect` if the actual kernel type is not as same as expect kernel type.
auto trans = g_data_transformation_[{actual_kernel_type, expect_kernel_type}];
The algorithm is described as following
kernel.run(trans(inputs));
```cpp
void OperatorWithKernel::Run(
const Scope& scope,
const platform::Place& place) const {
ExecutionContext ctx(...);
auto expected_kernel_key = this->GetExpectedKernelType(ctx);
Scope& new_scope = scope.NewScope();
for (auto& var_name : this->Inputs()) {
auto* tensor_in = GetTensor(var_name);
auto kernel_type_for_var = this->GetKernelTypeForVar(...);
if (kernel_type_for_var.place_ != expected_kernel_key.place_) {
auto* trans_var = new_scope.Var(var_name);
auto* out = DataTransform(expected_kernel_key,
kernel_type_for_var,
*tensor_in);
CopyVariableWithTensor(...);
}
}
auto kernel = kernels.find(expected_kernel_key);
kernel->Compute(ExecutionContext(...));
}
```
then the actual process for the multi-device above will be:
<spanid="background"></span><h1>Background<aclass="headerlink"href="#background"title="Permalink to this headline">¶</a></h1>
<p>Every operator has many kernels because there are multiple data types, places, data layout that Fluid supports. We use the <codeclass="docutils literal"><spanclass="pre">KernelType</span></code> to describe kernel types that operators can hold.</p>
<p>The <codeclass="docutils literal"><spanclass="pre">KernelType</span></code> is as follows.</p>
<p>Every operator has many kernels because there are multiple data types, places, data layout, library type that Fluid supports. We use the <codeclass="docutils literal"><spanclass="pre">OpKernelType</span></code> to describe kernel types that operators can hold.</p>
<p>The <codeclass="docutils literal"><spanclass="pre">OpKernelType</span></code> is as follows:</p>
<p>The <codeclass="docutils literal"><spanclass="pre">place_</span></code> is a descriptor of the device and the computational library, e.g., <codeclass="docutils literal"><spanclass="pre">MKLDNNPlace</span></code>, <codeclass="docutils literal"><spanclass="pre">CUDAPlace</span></code>.</p>
<p>The <codeclass="docutils literal"><spanclass="pre">data_type_</span></code> is the data type that this kernel performs on, e.g., <codeclass="docutils literal"><spanclass="pre">FP32</span></code>, <codeclass="docutils literal"><spanclass="pre">INT64</span></code>. Note that one kernel may have inputs with different data types. However, it will be a major <codeclass="docutils literal"><spanclass="pre">data_type</span></code>. For example, the <codeclass="docutils literal"><spanclass="pre">cross_entropy</span></code> takes <codeclass="docutils literal"><spanclass="pre">int64</span></code> as it label, and <codeclass="docutils literal"><spanclass="pre">double</span></code>/<codeclass="docutils literal"><spanclass="pre">float</span></code> as its input logit and output cost. The major <codeclass="docutils literal"><spanclass="pre">data_type</span></code> of <codeclass="docutils literal"><spanclass="pre">cross_entropy</span></code> is <codeclass="docutils literal"><spanclass="pre">float</span></code>/<codeclass="docutils literal"><spanclass="pre">double</span></code>.</p>
<p>The <codeclass="docutils literal"><spanclass="pre">layout</span></code> is useful for some computational library. One example is that MKLDNN uses many kinds of layout, such as <codeclass="docutils literal"><spanclass="pre">nChw8c</span></code>. Each kind of layout will invoke the different kernel.</p>
<ulclass="simple">
<li>The <codeclass="docutils literal"><spanclass="pre">place_</span></code> is a descriptor of the device, e.g., CPUPlace, CUDAPlace.</li>
<li>The <codeclass="docutils literal"><spanclass="pre">data_type_</span></code> is the data type that this kernel performs on, e.g., <codeclass="docutils literal"><spanclass="pre">FP32</span></code>, <codeclass="docutils literal"><spanclass="pre">INT64</span></code>. Note that one kernel may have inputs with different data types. However, it will be a major <codeclass="docutils literal"><spanclass="pre">data_type</span></code>. For example, the <codeclass="docutils literal"><spanclass="pre">cross_entropy</span></code> takes <codeclass="docutils literal"><spanclass="pre">int64</span></code> as it label, and <codeclass="docutils literal"><spanclass="pre">double</span></code>/<codeclass="docutils literal"><spanclass="pre">float</span></code> as its input logit and output cost. The major <codeclass="docutils literal"><spanclass="pre">data_type</span></code> of <codeclass="docutils literal"><spanclass="pre">cross_entropy</span></code> is <codeclass="docutils literal"><spanclass="pre">float</span></code> or <codeclass="docutils literal"><spanclass="pre">double</span></code>.</li>
<li>The <codeclass="docutils literal"><spanclass="pre">data_layout_</span></code> is useful for some computational library. One example is that MKLDNN uses many kinds of layout, such as <codeclass="docutils literal"><spanclass="pre">nChw8c</span></code>. Each kind of layout will invoke the different kernel.</li>
<spanid="problem"></span><h1>Problem<aclass="headerlink"href="#problem"title="Permalink to this headline">¶</a></h1>
...
...
@@ -232,39 +236,63 @@
<li>Some operators will take too many memory. It is better to force them into CPU. However, the rest of operators in this neural network will be performed on GPU, i.e., model parallel problem.</li>
<li>Some layout and place are particular. One example is that MKLDNN uses <codeclass="docutils literal"><spanclass="pre">nChw8</span></code> and there is no other library uses <codeclass="docutils literal"><spanclass="pre">nChw8c</span></code>.</li>
</ol>
<p>Problems under these situations are similar. We can formalise this problem as follow.</p>
<p>Take one situation to give a detailed explanation, if we have two Operators: OP1 and OP2, OP1 has one output <codeclass="docutils literal"><spanclass="pre">op1_to_op2</span></code>, and <codeclass="docutils literal"><spanclass="pre">op1_to_op2</span></code> is the input of OP2.</p>
<p>If OP1 and OP2 run on the same place(for example CPUPlace), then <codeclass="docutils literal"><spanclass="pre">op1_2_op2</span></code> can be used directly by OP2.</p>
<p>If OP1 and OP2 run one different place, then OP2 cannot <codeclass="docutils literal"><spanclass="pre">use</span><spanclass="pre">op1_2_op2</span></code> directly.</p>
<p>Problems under these situations are similar. We can formalize this problem as follow.</p>
<p>We register kernels with types $KT = {kt_1, kt_2, kt_3, ...}$ for one operator. The inputs of this operator should be run on kernel type $kt_{?}$, which the $kt_{?} \notin KT$. How to cast the input of this operator from $kt_{?}$ to any of kernel type in $KT$.</p>
</div>
<divclass="section"id="solution">
<spanid="solution"></span><h1>Solution<aclass="headerlink"href="#solution"title="Permalink to this headline">¶</a></h1>
<p>It is clearly that transforming inputs of an operator toadapt another kernel type is not related to the particular operator. So we should register these transformation methods as global methods.</p>
<p>We can infer a kernel type from the inputs of an operators. We let this kernel type as <codeclass="docutils literal"><spanclass="pre">actual</span><spanclass="pre">kernel</span><spanclass="pre">type</span></code>, which means this kernel type is the actually kernel type that operator should be performed.</p>
<divclass="section"id="solution-data-transform">
<spanid="solution-data-transform"></span><h1>Solution: data transform<aclass="headerlink"href="#solution-data-transform"title="Permalink to this headline">¶</a></h1>
<p>It is clear that transforming inputs of an operator to adapt another kernel type is not related to the particular operator. So we should register these transformation methods as global methods.</p>
<p>We can infer kernel type for each input of an operator. We let this kernel type as <codeclass="docutils literal"><spanclass="pre">actual</span><spanclass="pre">kernel</span><spanclass="pre">type</span><spanclass="pre">for</span><spanclass="pre">var</span></code>, which means this kernel type is the kernel type that can process this input variable.</p>
<p>We can get a kernel type by 1) The configuration of operator description. (Users may want to force use <codeclass="docutils literal"><spanclass="pre">MKL</span></code> for <codeclass="docutils literal"><spanclass="pre">conv</span></code> operator). 2) The place of the current executor. (Executor is running on GPU). This kernel type is what we expect the operator will be performed on. We let this kernel type as <codeclass="docutils literal"><spanclass="pre">expect</span><spanclass="pre">kernel</span><spanclass="pre">type</span></code>.</p>
<p>We transform the input data from <codeclass="docutils literal"><spanclass="pre">actual</span></code> to <codeclass="docutils literal"><spanclass="pre">expect</span></code> if the expect kernel type is not as same as actual kernel type.</p>
<p>We transform the input data from <codeclass="docutils literal"><spanclass="pre">actual</span></code> to <codeclass="docutils literal"><spanclass="pre">expect</span></code> if the actual kernel type is not as same as expect kernel type.</p>
Every operator has many kernels because there are multiple data types, places, data layout that Fluid supports. We use the `KernelType` to describe kernel types that operators can hold.
Every operator has many kernels because there are multiple data types, places, data layout, library type that Fluid supports. We use the `OpKernelType ` to describe kernel types that operators can hold.
The `KernelType` is as follows.
The `OpKernelType ` is as follows:
```
struct KernelType {
```cpp
struct OpKernelType {
Place place_;
DataType data_type_;
LayoutType layout_;
DataLayout data_layout_;
LibraryType library_type_;
};
```
The `place_` is a descriptor of the device and the computational library, e.g., `MKLDNNPlace`, `CUDAPlace`.
- The `place_` is a descriptor of the device, e.g., CPUPlace, CUDAPlace.
The `data_type_` is the data type that this kernel performs on, e.g., `FP32`, `INT64`. Note that one kernel may have inputs with different data types. However, it will be a major `data_type`. For example, the `cross_entropy` takes `int64` as it label, and `double`/`float` as its input logit and output cost. The major `data_type` of `cross_entropy` is `float`/`double`.
- The `data_type_` is the data type that this kernel performs on, e.g., `FP32`, `INT64`. Note that one kernel may have inputs with different data types. However, it will be a major `data_type`. For example, the `cross_entropy` takes `int64` as it label, and `double`/`float` as its input logit and output cost. The major `data_type` of `cross_entropy` is `float` or `double`.
The `layout` is useful for some computational library. One example is that MKLDNN uses many kinds of layout, such as `nChw8c`. Each kind of layout will invoke the different kernel.
- The `data_layout_ ` is useful for some computational library. One example is that MKLDNN uses many kinds of layout, such as `nChw8c`. Each kind of layout will invoke the different kernel.
- The `library_type_` describes the computational library, e.g., `MKLDNN`, `CUDNN`.
## Problem
...
...
@@ -25,42 +28,72 @@ We register a kernel for every operator and every kernel type ideally. However,
2. Some operators will take too many memory. It is better to force them into CPU. However, the rest of operators in this neural network will be performed on GPU, i.e., model parallel problem.
3. Some layout and place are particular. One example is that MKLDNN uses `nChw8` and there is no other library uses `nChw8c`.
Problems under these situations are similar. We can formalise this problem as follow.
We register kernels with types $KT = \{kt_1, kt_2, kt_3, ...\}$ for one operator. The inputs of this operator should be run on kernel type $kt_{?}$, which the $kt_{?} \notin KT$. How to cast the input of this operator from $kt_{?}$ to any of kernel type in $KT$.
Take one situation to give a detailed explanation, if we have two Operators: OP1 and OP2, OP1 has one output `op1_to_op2`, and `op1_to_op2` is the input of OP2.
## Solution
If OP1 and OP2 run on the same place(for example CPUPlace), then `op1_2_op2` can be used directly by OP2.
It is clearly that transforming inputs of an operator toadapt another kernel type is not related to the particular operator. So we should register these transformation methods as global methods.
```
OP1(CPUPlace)
|
op1_2_op2
|
OP2(CPUPlace)
```
We can infer a kernel type from the inputs of an operators. We let this kernel type as `actual kernel type`, which means this kernel type is the actually kernel type that operator should be performed.
If OP1 and OP2 run one different place, then OP2 cannot `use op1_2_op2` directly.
We can get a kernel type by 1) The configuration of operator description. (Users may want to force use `MKL` for `conv` operator). 2) The place of the current executor. (Executor is running on GPU). This kernel type is what we expect the operator will be performed on. We let this kernel type as `expect kernel type`.
Problems under these situations are similar. We can formalize this problem as follow.
We transform the input data from `actual` to `expect` if the expect kernel type is not as same as actual kernel type.
We register kernels with types $KT = \{kt_1, kt_2, kt_3, ...\}$ for one operator. The inputs of this operator should be run on kernel type $kt_{?}$, which the $kt_{?} \notin KT$. How to cast the input of this operator from $kt_{?}$ to any of kernel type in $KT$.
The algorithm is described as follow
## Solution: data transform
```cpp
using DataTransformationFN = std::function<void(const Tensor& in, Tensor* out)>;
using KernelTypePair = std::pair<KernelType, KernelType>;
It is clear that transforming inputs of an operator to adapt another kernel type is not related to the particular operator. So we should register these transformation methods as global methods.
We can infer kernel type for each input of an operator. We let this kernel type as `actual kernel type for var`, which means this kernel type is the kernel type that can process this input variable.
void OpWithKernel::Run() {
vec<Tensor> inputs = ...
auto actual_kernel_type = GetActualKernelType(inputs);
We can get a kernel type by 1) The configuration of operator description. (Users may want to force use `MKL` for `conv` operator). 2) The place of the current executor. (Executor is running on GPU). This kernel type is what we expect the operator will be performed on. We let this kernel type as `expect kernel type`.
// The expected kernel type is related to actual kernel type.
// For the most operators, the expected kernel type is as same as
// actual kernel type.
//
// So we pass `actual_kernel_type` as a parameter of
// GetExpectedKernelType
auto expect_kernel_type = GetExpectedKernelType(actual_kernel_type);
We transform the input data from `actual` to `expect` if the actual kernel type is not as same as expect kernel type.
auto trans = g_data_transformation_[{actual_kernel_type, expect_kernel_type}];
The algorithm is described as following
kernel.run(trans(inputs));
```cpp
void OperatorWithKernel::Run(
const Scope& scope,
const platform::Place& place) const {
ExecutionContext ctx(...);
auto expected_kernel_key = this->GetExpectedKernelType(ctx);
Scope& new_scope = scope.NewScope();
for (auto& var_name : this->Inputs()) {
auto* tensor_in = GetTensor(var_name);
auto kernel_type_for_var = this->GetKernelTypeForVar(...);
if (kernel_type_for_var.place_ != expected_kernel_key.place_) {
auto* trans_var = new_scope.Var(var_name);
auto* out = DataTransform(expected_kernel_key,
kernel_type_for_var,
*tensor_in);
CopyVariableWithTensor(...);
}
}
auto kernel = kernels.find(expected_kernel_key);
kernel->Compute(ExecutionContext(...));
}
```
then the actual process for the multi-device above will be:
<p>Every operator has many kernels because there are multiple data types, places, data layout that Fluid supports. We use the <codeclass="docutils literal"><spanclass="pre">KernelType</span></code> to describe kernel types that operators can hold.</p>
<p>The <codeclass="docutils literal"><spanclass="pre">KernelType</span></code> is as follows.</p>
<p>Every operator has many kernels because there are multiple data types, places, data layout, library type that Fluid supports. We use the <codeclass="docutils literal"><spanclass="pre">OpKernelType</span></code> to describe kernel types that operators can hold.</p>
<p>The <codeclass="docutils literal"><spanclass="pre">OpKernelType</span></code> is as follows:</p>
<p>The <codeclass="docutils literal"><spanclass="pre">place_</span></code> is a descriptor of the device and the computational library, e.g., <codeclass="docutils literal"><spanclass="pre">MKLDNNPlace</span></code>, <codeclass="docutils literal"><spanclass="pre">CUDAPlace</span></code>.</p>
<p>The <codeclass="docutils literal"><spanclass="pre">data_type_</span></code> is the data type that this kernel performs on, e.g., <codeclass="docutils literal"><spanclass="pre">FP32</span></code>, <codeclass="docutils literal"><spanclass="pre">INT64</span></code>. Note that one kernel may have inputs with different data types. However, it will be a major <codeclass="docutils literal"><spanclass="pre">data_type</span></code>. For example, the <codeclass="docutils literal"><spanclass="pre">cross_entropy</span></code> takes <codeclass="docutils literal"><spanclass="pre">int64</span></code> as it label, and <codeclass="docutils literal"><spanclass="pre">double</span></code>/<codeclass="docutils literal"><spanclass="pre">float</span></code> as its input logit and output cost. The major <codeclass="docutils literal"><spanclass="pre">data_type</span></code> of <codeclass="docutils literal"><spanclass="pre">cross_entropy</span></code> is <codeclass="docutils literal"><spanclass="pre">float</span></code>/<codeclass="docutils literal"><spanclass="pre">double</span></code>.</p>
<p>The <codeclass="docutils literal"><spanclass="pre">layout</span></code> is useful for some computational library. One example is that MKLDNN uses many kinds of layout, such as <codeclass="docutils literal"><spanclass="pre">nChw8c</span></code>. Each kind of layout will invoke the different kernel.</p>
<ulclass="simple">
<li>The <codeclass="docutils literal"><spanclass="pre">place_</span></code> is a descriptor of the device, e.g., CPUPlace, CUDAPlace.</li>
<li>The <codeclass="docutils literal"><spanclass="pre">data_type_</span></code> is the data type that this kernel performs on, e.g., <codeclass="docutils literal"><spanclass="pre">FP32</span></code>, <codeclass="docutils literal"><spanclass="pre">INT64</span></code>. Note that one kernel may have inputs with different data types. However, it will be a major <codeclass="docutils literal"><spanclass="pre">data_type</span></code>. For example, the <codeclass="docutils literal"><spanclass="pre">cross_entropy</span></code> takes <codeclass="docutils literal"><spanclass="pre">int64</span></code> as it label, and <codeclass="docutils literal"><spanclass="pre">double</span></code>/<codeclass="docutils literal"><spanclass="pre">float</span></code> as its input logit and output cost. The major <codeclass="docutils literal"><spanclass="pre">data_type</span></code> of <codeclass="docutils literal"><spanclass="pre">cross_entropy</span></code> is <codeclass="docutils literal"><spanclass="pre">float</span></code> or <codeclass="docutils literal"><spanclass="pre">double</span></code>.</li>
<li>The <codeclass="docutils literal"><spanclass="pre">data_layout_</span></code> is useful for some computational library. One example is that MKLDNN uses many kinds of layout, such as <codeclass="docutils literal"><spanclass="pre">nChw8c</span></code>. Each kind of layout will invoke the different kernel.</li>
<li>Some operators will take too many memory. It is better to force them into CPU. However, the rest of operators in this neural network will be performed on GPU, i.e., model parallel problem.</li>
<li>Some layout and place are particular. One example is that MKLDNN uses <codeclass="docutils literal"><spanclass="pre">nChw8</span></code> and there is no other library uses <codeclass="docutils literal"><spanclass="pre">nChw8c</span></code>.</li>
</ol>
<p>Problems under these situations are similar. We can formalise this problem as follow.</p>
<p>Take one situation to give a detailed explanation, if we have two Operators: OP1 and OP2, OP1 has one output <codeclass="docutils literal"><spanclass="pre">op1_to_op2</span></code>, and <codeclass="docutils literal"><spanclass="pre">op1_to_op2</span></code> is the input of OP2.</p>
<p>If OP1 and OP2 run on the same place(for example CPUPlace), then <codeclass="docutils literal"><spanclass="pre">op1_2_op2</span></code> can be used directly by OP2.</p>
<p>If OP1 and OP2 run one different place, then OP2 cannot <codeclass="docutils literal"><spanclass="pre">use</span><spanclass="pre">op1_2_op2</span></code> directly.</p>
<p>Problems under these situations are similar. We can formalize this problem as follow.</p>
<p>We register kernels with types $KT = {kt_1, kt_2, kt_3, ...}$ for one operator. The inputs of this operator should be run on kernel type $kt_{?}$, which the $kt_{?} \notin KT$. How to cast the input of this operator from $kt_{?}$ to any of kernel type in $KT$.</p>
<p>It is clearly that transforming inputs of an operator toadapt another kernel type is not related to the particular operator. So we should register these transformation methods as global methods.</p>
<p>We can infer a kernel type from the inputs of an operators. We let this kernel type as <codeclass="docutils literal"><spanclass="pre">actual</span><spanclass="pre">kernel</span><spanclass="pre">type</span></code>, which means this kernel type is the actually kernel type that operator should be performed.</p>
<divclass="section"id="solution-data-transform">
<spanid="solution-data-transform"></span><h1>Solution: data transform<aclass="headerlink"href="#solution-data-transform"title="永久链接至标题">¶</a></h1>
<p>It is clear that transforming inputs of an operator to adapt another kernel type is not related to the particular operator. So we should register these transformation methods as global methods.</p>
<p>We can infer kernel type for each input of an operator. We let this kernel type as <codeclass="docutils literal"><spanclass="pre">actual</span><spanclass="pre">kernel</span><spanclass="pre">type</span><spanclass="pre">for</span><spanclass="pre">var</span></code>, which means this kernel type is the kernel type that can process this input variable.</p>
<p>We can get a kernel type by 1) The configuration of operator description. (Users may want to force use <codeclass="docutils literal"><spanclass="pre">MKL</span></code> for <codeclass="docutils literal"><spanclass="pre">conv</span></code> operator). 2) The place of the current executor. (Executor is running on GPU). This kernel type is what we expect the operator will be performed on. We let this kernel type as <codeclass="docutils literal"><spanclass="pre">expect</span><spanclass="pre">kernel</span><spanclass="pre">type</span></code>.</p>
<p>We transform the input data from <codeclass="docutils literal"><spanclass="pre">actual</span></code> to <codeclass="docutils literal"><spanclass="pre">expect</span></code> if the expect kernel type is not as same as actual kernel type.</p>
<p>We transform the input data from <codeclass="docutils literal"><spanclass="pre">actual</span></code> to <codeclass="docutils literal"><spanclass="pre">expect</span></code> if the actual kernel type is not as same as expect kernel type.</p>
