[GitHub] [incubator-mxnet] Alicia1529 opened a new pull request #17524: add np.random.chisquare
Alicia1529 opened a new pull request #17524: add np.random.chisquare URL: https://github.com/apache/incubator-mxnet/pull/17524 ## Description ## add chisquare distribution and fix gamma doc This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] michiboo opened a new pull request #17523: remove -mf15c flag for andriod build
michiboo opened a new pull request #17523: remove -mf15c flag for andriod build URL: https://github.com/apache/incubator-mxnet/pull/17523 ## Description ## Removed unused -mf16c compiler flag in android build ## Checklist ## ### Essentials ### Please feel free to remove inapplicable items for your PR. - [x ] Changes are complete (i.e. I finished coding on this PR) - [x ] All changes have test coverage: - Unit tests are added for small changes to verify correctness (e.g. adding a new operator) - Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore) - Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL) - [ x] To the best of my knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] haojin2 commented on a change in pull request #17328: [numpy] add op pad
haojin2 commented on a change in pull request #17328: [numpy] add op pad
URL: https://github.com/apache/incubator-mxnet/pull/17328#discussion_r375087832
##
File path: python/mxnet/ndarray/numpy/_op.py
##
@@ -6476,3 +6475,119 @@ def bincount(x, weights=None, minlength=0):
if weights is None:
return _npi.bincount(x, minlength=minlength, has_weights=False)
return _npi.bincount(x, weights=weights, minlength=minlength,
has_weights=True)
+
+
+@set_module('mxnet.ndarray.numpy')
+def pad(array, pad_width=None, mode="constant", reflect_type="even",
constant_values=0):
+"""
+Pad an array.
+
+Parameters
+--
+array : array_like of rank N
+The array to pad.
+pad_width : {sequence, array_like, int}
+Number of values padded to the edges of each axis.
+((before_1, after_1), ... (before_N, after_N)) unique pad widths
+for each axis.
+((before, after),) yields same before and after pad for each axis.
+(pad,) or int is a shortcut for before = after = pad width for all
+axes.
+mode : str or function, optional
+One of the following string values or a user supplied function.
+'constant' (default)
+Pads with a constant value.
+'edge'
+Pads with the edge values of array.
+'linear_ramp'
+not supported yet
+'maximum'
+Pads with the maximum value of all of the
+vector along each axis.
+'mean'
+not supported yet
+'median'
+ not supported yet
+'minimum'
+Pads with the minimum value of all of the
+vector along each axis.
+'reflect'
+Pads with the reflection of the vector mirrored on
+the first and last values of the vector along each
+axis.
+'symmetric'
+Pads with the reflection of the vector mirrored
+along the edge of the array.
+'wrap'
+not supported yet
+'empty'
+Pads with undefined values.
+.. versionadded:: 1.17
+
+Padding function, see Notes.
+stat_length : not supported yet
+constant_values : scalar, optional
+Used in 'constant'. The values to set the padded values for each
+axis.
+Default is 0.
+
+end_values : not supported yet
+reflect_type : {'even', 'odd'}, optional
+only support even now
+
+Returns
+---
+pad : ndarray
+Padded array of rank equal to `array` with shape increased
+according to `pad_width`.
+
+Examples
+
+>>> a = [1, 2, 3, 4, 5]
+>>> np.pad(a, (2, 3), 'edge')
+array([1, 1, 1, ..., 5, 5, 5])
+>>> np.pad(a, (2, 2), 'maximum')
+array([5, 5, 1, 2, 3, 4, 5, 5, 5])
+>>> np.pad(a, (2, 2), 'mean')
+array([3, 3, 1, 2, 3, 4, 5, 3, 3])
+>>> a = [[1, 2], [3, 4]]
+>>> np.pad(a, ((3, 2), (2, 3)), 'minimum')
+array([[1, 1, 1, 2, 1, 1, 1],
+ [1, 1, 1, 2, 1, 1, 1],
+ [1, 1, 1, 2, 1, 1, 1],
+ [1, 1, 1, 2, 1, 1, 1],
+ [3, 3, 3, 4, 3, 3, 3],
+ [1, 1, 1, 2, 1, 1, 1],
+ [1, 1, 1, 2, 1, 1, 1]])
+>>> a = [1, 2, 3, 4, 5]
+>>> np.pad(a, (2, 3), 'reflect')
+array([3, 2, 1, 2, 3, 4, 5, 4, 3, 2])
+>>> np.pad(a, (2, 3), 'symmetric')
+array([2, 1, 1, 2, 3, 4, 5, 5, 4, 3])
+>>> a = np.arange(6)
+>>> a = a.reshape((2, 3))
+>>> np.pad(a, ((2, 2), (2, 2)), pad_with)
+array([[10, 10, 10, 10, 10, 10, 10],
+ [10, 10, 10, 10, 10, 10, 10],
+ [10, 10, 0, 1, 2, 10, 10],
+ [10, 10, 3, 4, 5, 10, 10],
+ [10, 10, 10, 10, 10, 10, 10],
+ [10, 10, 10, 10, 10, 10, 10]])
+"""
+
+if not isinstance(array, NDArray):
+raise TypeError("Input data should be NDarray")
+if mode == "constant":
+return _npi.pad(array, pad_width, 1, reflect_type, constant_values)
+elif mode == "symmetric" and reflect_type == "even":
+return _npi.pad(array, pad_width, 2, "even", constant_values)
+elif mode == "edge":
+return _npi.pad(array, pad_width, 3, reflect_type, constant_values)
+elif mode == "reflect" and reflect_type == "even":
+return _npi.pad(array, pad_width, 4, "even", constant_values)
+elif mode == "maximum":
+return _npi.pad(array, pad_width, 5, "even", constant_values)
+elif mode == "minimum":
+return _npi.pad(array, pad_width, 6, "even", constant_values)
+else:
+raise ValueError("didn't support these modes and reflect_types.")
Review comment:
same here, give a more meaningful error message.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this
[GitHub] [incubator-mxnet] haojin2 commented on a change in pull request #17328: [numpy] add op pad
haojin2 commented on a change in pull request #17328: [numpy] add op pad
URL: https://github.com/apache/incubator-mxnet/pull/17328#discussion_r375087669
##
File path: python/mxnet/symbol/numpy/_symbol.py
##
@@ -5866,4 +5866,83 @@ def bincount(x, weights=None, minlength=0):
return _npi.bincount(x, weights=weights, minlength=minlength,
has_weights=True)
+@set_module('mxnet.symbol.numpy')
+def pad(array, pad_width=None, mode="constant", reflect_type="even",
constant_values=0):
+"""
+Pad an array.
+
+Parameters
+--
+array : array_like of rank N
+The array to pad.
+pad_width : {sequence, array_like, int}
+Number of values padded to the edges of each axis.
+((before_1, after_1), ... (before_N, after_N)) unique pad widths
+for each axis.
+((before, after),) yields same before and after pad for each axis.
+(pad,) or int is a shortcut for before = after = pad width for all
+axes.
+mode : str or function, optional
+One of the following string values or a user supplied function.
+'constant' (default)
+Pads with a constant value.
+'edge'
+Pads with the edge values of array.
+'linear_ramp'
+not supported yet
+'maximum'
+Pads with the maximum value of all of the
+vector along each axis.
+'mean'
+not supported yet
+'median'
+ not supported yet
+'minimum'
+Pads with the minimum value of all of the
+vector along each axis.
+'reflect'
+Pads with the reflection of the vector mirrored on
+the first and last values of the vector along each
+axis.
+'symmetric'
+Pads with the reflection of the vector mirrored
+along the edge of the array.
+'wrap'
+not supported yet
+'empty'
+Pads with undefined values.
+.. versionadded:: 1.17
+
+Padding function, see Notes.
+stat_length : not supported yet
+constant_values : scalar, optional
+Used in 'constant'. The values to set the padded values for each
+axis.
+Default is 0.
+
+end_values : not supported yet
+reflect_type : {'even', 'odd'}, optional
+only support even now
+
+Returns
+---
+pad : ndarray
+Padded array of rank equal to `array` with shape increased
+according to `pad_width`.
+"""
+if mode == "constant":
+return _npi.pad(array, pad_width, 1, reflect_type, constant_values)
+elif mode == "symmetric" and reflect_type == "even":
+return _npi.pad(array, pad_width, 2, "even", constant_values)
+elif mode == "edge":
+return _npi.pad(array, pad_width, 3, reflect_type, constant_values)
+elif mode == "reflect" and reflect_type == "even":
+return _npi.pad(array, pad_width, 4, "even", constant_values)
+elif mode == "maximum":
+return _npi.pad(array, pad_width, 5, "even", constant_values)
+elif mode == "minimum":
+return _npi.pad(array, pad_width, 6, "even", constant_values)
+else:
+raise ValueError("didn't support these modes and reflect_types.")
Review comment:
give more specific error messages about the exact inputs which are not
supported.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [incubator-mxnet] haojin2 commented on a change in pull request #17517: [WIP][numpy] Add np.random.pareto and np.random.power
haojin2 commented on a change in pull request #17517: [WIP][numpy] Add np.random.pareto and np.random.power URL: https://github.com/apache/incubator-mxnet/pull/17517#discussion_r375085235 ## File path: python/mxnet/symbol/numpy/random.py ## @@ -523,6 +523,91 @@ def weibull(a, size): else: return _npi.weibull(a=a, size=size) +def pareto(a, size): Review comment: one more blank line above. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] haojin2 commented on a change in pull request #17401: [numpy]implement exponential backward
haojin2 commented on a change in pull request #17401: [numpy]implement exponential backward URL: https://github.com/apache/incubator-mxnet/pull/17401#discussion_r375083283 ## File path: src/operator/numpy/random/np_exponential_op.h ## @@ -140,6 +144,60 @@ void NumpyExponentialForward(const nnvm::NodeAttrs &attrs, } } +template +inline void ScalarExponentialReparamBackwardImpl(const OpContext& ctx, +const std::vector& inputs, Review comment: alignment This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] haojin2 commented on a change in pull request #17401: [numpy]implement exponential backward
haojin2 commented on a change in pull request #17401: [numpy]implement
exponential backward
URL: https://github.com/apache/incubator-mxnet/pull/17401#discussion_r375083320
##
File path: src/operator/numpy/random/np_exponential_op.h
##
@@ -140,6 +144,60 @@ void NumpyExponentialForward(const nnvm::NodeAttrs &attrs,
}
}
+template
+inline void ScalarExponentialReparamBackwardImpl(const OpContext& ctx,
+const std::vector& inputs,
+const std::vector& req,
+const std::vector& outputs,
+const mxnet::TShape& new_ishape,
+const mxnet::TShape& new_oshape) {
+ using namespace mshadow;
+ using namespace mshadow::expr;
+ using namespace broadcast;
+ Stream *s = ctx.get_stream();
+ const TBlob igrad = outputs[0].reshape(new_ishape);
+ // inputs: [grad_from_samples, grad_from_noise(invisible), input_tensor,
+ // samples, noise]
+ const TBlob ograd = inputs[0].reshape(new_oshape);
+ const TBlob itensor = inputs[2].reshape(new_ishape);
+ const TBlob samples = inputs[3].reshape(new_oshape);
+ const TBlob noise = inputs[4].reshape(new_oshape);
+ size_t workspace_size =
+ ReduceWorkspaceSize(s, igrad.shape_, req[0], ograd.shape_);
+ Tensor workspace =
+ ctx.requested[0].get_space_typed(Shape1(workspace_size),
s);
+ Reduce(
+ s, igrad, req[0], workspace, ograd, noise, noise);
+}
+
+template
+void ExponentialReparamBackward(const nnvm::NodeAttrs& attrs,
+ const OpContext& ctx,
Review comment:
alignment
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[incubator-mxnet-site] branch asf-site updated: Bump the publish timestamp.
This is an automated email from the ASF dual-hosted git repository. aaronmarkham pushed a commit to branch asf-site in repository https://gitbox.apache.org/repos/asf/incubator-mxnet-site.git The following commit(s) were added to refs/heads/asf-site by this push: new 8e30ef4 Bump the publish timestamp. 8e30ef4 is described below commit 8e30ef498bbc666362b39c183bdde292bbe3f5b7 Author: mxnet-ci AuthorDate: Wed Feb 5 06:42:12 2020 + Bump the publish timestamp. --- date.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/date.txt b/date.txt new file mode 100644 index 000..db50e50 --- /dev/null +++ b/date.txt @@ -0,0 +1 @@ +Wed Feb 5 06:42:12 UTC 2020
[GitHub] [incubator-mxnet] hzfan commented on a change in pull request #17387: [TVM][Windows] TVM Ops windows build
hzfan commented on a change in pull request #17387: [TVM][Windows] TVM Ops windows build URL: https://github.com/apache/incubator-mxnet/pull/17387#discussion_r375078376 ## File path: python/mxnet/space.py ## @@ -1 +1,214 @@ -../../contrib/tvmop/space.py Review comment: @vexilligera Could you try adding `python/mxnet/space.py` to `Jenkins_steps.groovy`, so that it will be copied from compilation phase to testing phase This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support
samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support URL: https://github.com/apache/incubator-mxnet/pull/17486#discussion_r375060298 ## File path: example/extensions/lib_custom_op/README.md ## @@ -146,21 +186,160 @@ Let’s take a closer look at those registry functions: * **inferShape**: This function is similar to the `inferType` function, except it is used for populating the output data shapes. You need to figure out the shapes of each output tensors for this computation. For example, if the inputs are images with shape (224,224,3) and you write a padding operator to make 10px borders for the images, then your output shape will be (234,234,3). -* **forward**: This function executes the main forward computation. It takes four arguments. The 1st argument is the attributes. The 2nd argument is the input `MXTensors` which stores all data and info of input ndarrays. The 3rd argument is the output `MXTensors`. The 4th argument is the `OpResource` object for memory allocation and other utilities. Additionally, you can use a `dltensor` tensor structure stored in the `MXTensor` as a more standardized data structure for computing. +* **forward**: This function executes the main forward computation. It takes four arguments. The 1st argument is the attributes. The 2nd argument is the input `MXTensors` which stores all data and info of input ndarrays. The 3rd argument is the output `MXTensors`. The 4th argument is the `OpResource` object for memory allocation and other utilities. The details of `OpResource` are covered in the below section. +Additionally, you can use a `dltensor` tensor structure stored in the `MXTensor` as a more standardized data structure for computing. * **backward**: This function is doing the backward gradient computation. It will be similar to the forward function. And you need to figure out the formula of the backward gradient computation. * **mutateInputs**: This function is for marking mutable inputs. It takes two arguments. The 1st argument is the attributes. The 2nd argument is a list of input indices that are mutable among all input tensors. It is useful when some inputs are auxiliary model parameters and might be altered during forward/backward computation. Remember, the index number of `input_indices` should not exceed the number of inputs. -### Writing Stateful Custom Operator: +### Writing Stateful Custom Operator A stateful custom operator is useful when a forward/backward call needs some data or ‘state’ from previous forward/backward calls. Normally we create a class, and make instance variables store the states used for computing or caching. Most of the building blocks for making a stateful custom operator is the same as regular custom operator, except it’ll register `createOpState` instead of a `forward` function for the computation. * [createOpState](./gemm_lib.cc#L204) - Create stateful operator instance: * This function takes two arguments. The 1st argument is attributes. The 2nd argument is a placeholder for `CustomStatefulOp` object. You must [define a class that inherits CustomStatefulOp](./gemm_lib.cc#L178) and override the forward function (optionally the backward function). Then you need to create an instance of your class and assign it to the placeholder. In this way, all of the forward/backward calls will use the same methods in that instance, and the instance is able to keep the state of the operator. +```c++ +MXReturnValue createOpState( +std::map attrs, +CustomStatefulOp** op_inst) +``` + +* The operator registering function will look like this: +```c++ +REGISTER_OP(my_state_op) +... +.setCreateOpState(createOpState, "cpu"); +``` + +## Writing A Custom GPU Operator Library + +Most of the building blocks for registering GPU custom operators are the exactly same as CPU ones, except you need to specify the `"gpu"` context name when registering `forward`, `backward` or `createOpState` function. + +### Run A GPU Example + +For illustration purposes, we provided a `ReLU` (Rectified Linear Unit) activation operator that can run on GPU. Make sure you have installed a CUDA compatible MXNet build. Go to `lib_custom_op` directory and follow these steps: + +1. Run `make relu_lib`. The Makefile will invoke `NVCC` compiler to compile the CUDA kernel along with regular custom operator functions from `relu_lib.cu` to generate `librelu_lib.so` library. +2. Run `python test_relu.py`. It’ll register the GPU `ReLU` operator in the MXNet backend, then invoke the operator by feeding an `NDArray` input with GPU context, and output the result tensor with GPU context. + +### Writing A Regular GPU Custom Operator + +Since most of the building blocks for registering GPU custom operators are the exactly same as CPU ones, the registering function for an operator supporting both GPU and CPU will look like this: + +`
[GitHub] [incubator-mxnet] leezu closed issue #17514: C++-Package examples broken
leezu closed issue #17514: C++-Package examples broken URL: https://github.com/apache/incubator-mxnet/issues/17514 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] wkcn commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support
wkcn commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support URL: https://github.com/apache/incubator-mxnet/pull/17486#discussion_r375044803 ## File path: example/extensions/lib_custom_op/README.md ## @@ -146,21 +186,160 @@ Let’s take a closer look at those registry functions: * **inferShape**: This function is similar to the `inferType` function, except it is used for populating the output data shapes. You need to figure out the shapes of each output tensors for this computation. For example, if the inputs are images with shape (224,224,3) and you write a padding operator to make 10px borders for the images, then your output shape will be (234,234,3). -* **forward**: This function executes the main forward computation. It takes four arguments. The 1st argument is the attributes. The 2nd argument is the input `MXTensors` which stores all data and info of input ndarrays. The 3rd argument is the output `MXTensors`. The 4th argument is the `OpResource` object for memory allocation and other utilities. Additionally, you can use a `dltensor` tensor structure stored in the `MXTensor` as a more standardized data structure for computing. +* **forward**: This function executes the main forward computation. It takes four arguments. The 1st argument is the attributes. The 2nd argument is the input `MXTensors` which stores all data and info of input ndarrays. The 3rd argument is the output `MXTensors`. The 4th argument is the `OpResource` object for memory allocation and other utilities. The details of `OpResource` are covered in the below section. +Additionally, you can use a `dltensor` tensor structure stored in the `MXTensor` as a more standardized data structure for computing. * **backward**: This function is doing the backward gradient computation. It will be similar to the forward function. And you need to figure out the formula of the backward gradient computation. * **mutateInputs**: This function is for marking mutable inputs. It takes two arguments. The 1st argument is the attributes. The 2nd argument is a list of input indices that are mutable among all input tensors. It is useful when some inputs are auxiliary model parameters and might be altered during forward/backward computation. Remember, the index number of `input_indices` should not exceed the number of inputs. -### Writing Stateful Custom Operator: +### Writing Stateful Custom Operator A stateful custom operator is useful when a forward/backward call needs some data or ‘state’ from previous forward/backward calls. Normally we create a class, and make instance variables store the states used for computing or caching. Most of the building blocks for making a stateful custom operator is the same as regular custom operator, except it’ll register `createOpState` instead of a `forward` function for the computation. * [createOpState](./gemm_lib.cc#L204) - Create stateful operator instance: * This function takes two arguments. The 1st argument is attributes. The 2nd argument is a placeholder for `CustomStatefulOp` object. You must [define a class that inherits CustomStatefulOp](./gemm_lib.cc#L178) and override the forward function (optionally the backward function). Then you need to create an instance of your class and assign it to the placeholder. In this way, all of the forward/backward calls will use the same methods in that instance, and the instance is able to keep the state of the operator. +```c++ +MXReturnValue createOpState( +std::map attrs, +CustomStatefulOp** op_inst) +``` + +* The operator registering function will look like this: +```c++ +REGISTER_OP(my_state_op) +... +.setCreateOpState(createOpState, "cpu"); +``` + +## Writing A Custom GPU Operator Library + +Most of the building blocks for registering GPU custom operators are the exactly same as CPU ones, except you need to specify the `"gpu"` context name when registering `forward`, `backward` or `createOpState` function. + +### Run A GPU Example + +For illustration purposes, we provided a `ReLU` (Rectified Linear Unit) activation operator that can run on GPU. Make sure you have installed a CUDA compatible MXNet build. Go to `lib_custom_op` directory and follow these steps: + +1. Run `make relu_lib`. The Makefile will invoke `NVCC` compiler to compile the CUDA kernel along with regular custom operator functions from `relu_lib.cu` to generate `librelu_lib.so` library. +2. Run `python test_relu.py`. It’ll register the GPU `ReLU` operator in the MXNet backend, then invoke the operator by feeding an `NDArray` input with GPU context, and output the result tensor with GPU context. + +### Writing A Regular GPU Custom Operator + +Since most of the building blocks for registering GPU custom operators are the exactly same as CPU ones, the registering function for an operator supporting both GPU and CPU will look like this: + +```c++ +
[GitHub] [incubator-mxnet] wkcn commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support
wkcn commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support URL: https://github.com/apache/incubator-mxnet/pull/17486#discussion_r375044803 ## File path: example/extensions/lib_custom_op/README.md ## @@ -146,21 +186,160 @@ Let’s take a closer look at those registry functions: * **inferShape**: This function is similar to the `inferType` function, except it is used for populating the output data shapes. You need to figure out the shapes of each output tensors for this computation. For example, if the inputs are images with shape (224,224,3) and you write a padding operator to make 10px borders for the images, then your output shape will be (234,234,3). -* **forward**: This function executes the main forward computation. It takes four arguments. The 1st argument is the attributes. The 2nd argument is the input `MXTensors` which stores all data and info of input ndarrays. The 3rd argument is the output `MXTensors`. The 4th argument is the `OpResource` object for memory allocation and other utilities. Additionally, you can use a `dltensor` tensor structure stored in the `MXTensor` as a more standardized data structure for computing. +* **forward**: This function executes the main forward computation. It takes four arguments. The 1st argument is the attributes. The 2nd argument is the input `MXTensors` which stores all data and info of input ndarrays. The 3rd argument is the output `MXTensors`. The 4th argument is the `OpResource` object for memory allocation and other utilities. The details of `OpResource` are covered in the below section. +Additionally, you can use a `dltensor` tensor structure stored in the `MXTensor` as a more standardized data structure for computing. * **backward**: This function is doing the backward gradient computation. It will be similar to the forward function. And you need to figure out the formula of the backward gradient computation. * **mutateInputs**: This function is for marking mutable inputs. It takes two arguments. The 1st argument is the attributes. The 2nd argument is a list of input indices that are mutable among all input tensors. It is useful when some inputs are auxiliary model parameters and might be altered during forward/backward computation. Remember, the index number of `input_indices` should not exceed the number of inputs. -### Writing Stateful Custom Operator: +### Writing Stateful Custom Operator A stateful custom operator is useful when a forward/backward call needs some data or ‘state’ from previous forward/backward calls. Normally we create a class, and make instance variables store the states used for computing or caching. Most of the building blocks for making a stateful custom operator is the same as regular custom operator, except it’ll register `createOpState` instead of a `forward` function for the computation. * [createOpState](./gemm_lib.cc#L204) - Create stateful operator instance: * This function takes two arguments. The 1st argument is attributes. The 2nd argument is a placeholder for `CustomStatefulOp` object. You must [define a class that inherits CustomStatefulOp](./gemm_lib.cc#L178) and override the forward function (optionally the backward function). Then you need to create an instance of your class and assign it to the placeholder. In this way, all of the forward/backward calls will use the same methods in that instance, and the instance is able to keep the state of the operator. +```c++ +MXReturnValue createOpState( +std::map attrs, +CustomStatefulOp** op_inst) +``` + +* The operator registering function will look like this: +```c++ +REGISTER_OP(my_state_op) +... +.setCreateOpState(createOpState, "cpu"); +``` + +## Writing A Custom GPU Operator Library + +Most of the building blocks for registering GPU custom operators are the exactly same as CPU ones, except you need to specify the `"gpu"` context name when registering `forward`, `backward` or `createOpState` function. + +### Run A GPU Example + +For illustration purposes, we provided a `ReLU` (Rectified Linear Unit) activation operator that can run on GPU. Make sure you have installed a CUDA compatible MXNet build. Go to `lib_custom_op` directory and follow these steps: + +1. Run `make relu_lib`. The Makefile will invoke `NVCC` compiler to compile the CUDA kernel along with regular custom operator functions from `relu_lib.cu` to generate `librelu_lib.so` library. +2. Run `python test_relu.py`. It’ll register the GPU `ReLU` operator in the MXNet backend, then invoke the operator by feeding an `NDArray` input with GPU context, and output the result tensor with GPU context. + +### Writing A Regular GPU Custom Operator + +Since most of the building blocks for registering GPU custom operators are the exactly same as CPU ones, the registering function for an operator supporting both GPU and CPU will look like this: + +```c++ +
[GitHub] [incubator-mxnet] wkcn commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support
wkcn commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support URL: https://github.com/apache/incubator-mxnet/pull/17486#discussion_r375044803 ## File path: example/extensions/lib_custom_op/README.md ## @@ -146,21 +186,160 @@ Let’s take a closer look at those registry functions: * **inferShape**: This function is similar to the `inferType` function, except it is used for populating the output data shapes. You need to figure out the shapes of each output tensors for this computation. For example, if the inputs are images with shape (224,224,3) and you write a padding operator to make 10px borders for the images, then your output shape will be (234,234,3). -* **forward**: This function executes the main forward computation. It takes four arguments. The 1st argument is the attributes. The 2nd argument is the input `MXTensors` which stores all data and info of input ndarrays. The 3rd argument is the output `MXTensors`. The 4th argument is the `OpResource` object for memory allocation and other utilities. Additionally, you can use a `dltensor` tensor structure stored in the `MXTensor` as a more standardized data structure for computing. +* **forward**: This function executes the main forward computation. It takes four arguments. The 1st argument is the attributes. The 2nd argument is the input `MXTensors` which stores all data and info of input ndarrays. The 3rd argument is the output `MXTensors`. The 4th argument is the `OpResource` object for memory allocation and other utilities. The details of `OpResource` are covered in the below section. +Additionally, you can use a `dltensor` tensor structure stored in the `MXTensor` as a more standardized data structure for computing. * **backward**: This function is doing the backward gradient computation. It will be similar to the forward function. And you need to figure out the formula of the backward gradient computation. * **mutateInputs**: This function is for marking mutable inputs. It takes two arguments. The 1st argument is the attributes. The 2nd argument is a list of input indices that are mutable among all input tensors. It is useful when some inputs are auxiliary model parameters and might be altered during forward/backward computation. Remember, the index number of `input_indices` should not exceed the number of inputs. -### Writing Stateful Custom Operator: +### Writing Stateful Custom Operator A stateful custom operator is useful when a forward/backward call needs some data or ‘state’ from previous forward/backward calls. Normally we create a class, and make instance variables store the states used for computing or caching. Most of the building blocks for making a stateful custom operator is the same as regular custom operator, except it’ll register `createOpState` instead of a `forward` function for the computation. * [createOpState](./gemm_lib.cc#L204) - Create stateful operator instance: * This function takes two arguments. The 1st argument is attributes. The 2nd argument is a placeholder for `CustomStatefulOp` object. You must [define a class that inherits CustomStatefulOp](./gemm_lib.cc#L178) and override the forward function (optionally the backward function). Then you need to create an instance of your class and assign it to the placeholder. In this way, all of the forward/backward calls will use the same methods in that instance, and the instance is able to keep the state of the operator. +```c++ +MXReturnValue createOpState( +std::map attrs, +CustomStatefulOp** op_inst) +``` + +* The operator registering function will look like this: +```c++ +REGISTER_OP(my_state_op) +... +.setCreateOpState(createOpState, "cpu"); +``` + +## Writing A Custom GPU Operator Library + +Most of the building blocks for registering GPU custom operators are the exactly same as CPU ones, except you need to specify the `"gpu"` context name when registering `forward`, `backward` or `createOpState` function. + +### Run A GPU Example + +For illustration purposes, we provided a `ReLU` (Rectified Linear Unit) activation operator that can run on GPU. Make sure you have installed a CUDA compatible MXNet build. Go to `lib_custom_op` directory and follow these steps: + +1. Run `make relu_lib`. The Makefile will invoke `NVCC` compiler to compile the CUDA kernel along with regular custom operator functions from `relu_lib.cu` to generate `librelu_lib.so` library. +2. Run `python test_relu.py`. It’ll register the GPU `ReLU` operator in the MXNet backend, then invoke the operator by feeding an `NDArray` input with GPU context, and output the result tensor with GPU context. + +### Writing A Regular GPU Custom Operator + +Since most of the building blocks for registering GPU custom operators are the exactly same as CPU ones, the registering function for an operator supporting both GPU and CPU will look like this: + +```c++ +
[incubator-mxnet] branch master updated: Add dependency for cpp tests (#17520)
This is an automated email from the ASF dual-hosted git repository.
anirudh2290 pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-mxnet.git
The following commit(s) were added to refs/heads/master by this push:
new be89d20 Add dependency for cpp tests (#17520)
be89d20 is described below
commit be89d2017441ec023ec868f4e733f04eb573f4bc
Author: Anirudh Subramanian
AuthorDate: Tue Feb 4 19:20:21 2020 -0800
Add dependency for cpp tests (#17520)
---
tests/CMakeLists.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tests/CMakeLists.txt b/tests/CMakeLists.txt
index e1e8884..745251e 100644
--- a/tests/CMakeLists.txt
+++ b/tests/CMakeLists.txt
@@ -37,6 +37,9 @@ if(GTEST_FOUND AND NOT MSVC)
add_executable(${PROJECT_NAME}_unit_tests ${UNIT_TEST_SOURCE})
set_property(TARGET ${PROJECT_NAME}_unit_tests
PROPERTY RUNTIME_OUTPUT_DIRECTORY ${PRIVATE_RUNTIME_DIR})
+ if (USE_CPP_PACKAGE)
+add_dependencies(${PROJECT_NAME}_unit_tests cpp_package_op_h)
+ endif()
if(UNITTEST_STATIC_LINK)
target_link_libraries(${PROJECT_NAME}_unit_tests
[GitHub] [incubator-mxnet] anirudh2290 merged pull request #17520: Fix CMake CPP tests dependency issue
anirudh2290 merged pull request #17520: Fix CMake CPP tests dependency issue URL: https://github.com/apache/incubator-mxnet/pull/17520 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] leezu opened a new issue #17522: Custom error type doesn't always work
leezu opened a new issue #17522: Custom error type doesn't always work URL: https://github.com/apache/incubator-mxnet/issues/17522 ## Description `CHECK(!Imperative::DCInfo::IsNone(*ndoutput)) << "ValueError: Test"` confuses the https://github.com/apache/incubator-mxnet/pull/17128/ logic. It will throw `MXNetError` instead of `ValueError`. (I made this observation https://github.com/apache/incubator-mxnet/pull/17509 branch. Without https://github.com/apache/incubator-mxnet/pull/17509 abort would be called.) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[incubator-mxnet] branch master updated (a0506ab -> 68af49a)
This is an automated email from the ASF dual-hosted git repository. reminisce pushed a change to branch master in repository https://gitbox.apache.org/repos/asf/incubator-mxnet.git. from a0506ab Fix typo in ubuntu_setup.md (#17496) add 68af49a Remove dilation restriction for conv3d (#17491) No new revisions were added by this update. Summary of changes: src/operator/nn/convolution.cc | 4 tests/python/unittest/test_operator.py | 4 2 files changed, 4 insertions(+), 4 deletions(-)
[incubator-mxnet] branch master updated (a0506ab -> 68af49a)
This is an automated email from the ASF dual-hosted git repository. reminisce pushed a change to branch master in repository https://gitbox.apache.org/repos/asf/incubator-mxnet.git. from a0506ab Fix typo in ubuntu_setup.md (#17496) add 68af49a Remove dilation restriction for conv3d (#17491) No new revisions were added by this update. Summary of changes: src/operator/nn/convolution.cc | 4 tests/python/unittest/test_operator.py | 4 2 files changed, 4 insertions(+), 4 deletions(-)
[GitHub] [incubator-mxnet] reminisce merged pull request #17491: Remove dilation restriction for conv3d
reminisce merged pull request #17491: Remove dilation restriction for conv3d URL: https://github.com/apache/incubator-mxnet/pull/17491 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] TaoLv commented on issue #17500: [OpPerf] Implement remaining nn_conv ops in opperf
TaoLv commented on issue #17500: [OpPerf] Implement remaining nn_conv ops in opperf URL: https://github.com/apache/incubator-mxnet/pull/17500#issuecomment-582211724 @ChaiBapchya Thank you for the quick turn around. It looks good to me. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support
samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support URL: https://github.com/apache/incubator-mxnet/pull/17486#discussion_r375027292 ## File path: example/extensions/lib_custom_op/README.md ## @@ -146,21 +186,160 @@ Let’s take a closer look at those registry functions: * **inferShape**: This function is similar to the `inferType` function, except it is used for populating the output data shapes. You need to figure out the shapes of each output tensors for this computation. For example, if the inputs are images with shape (224,224,3) and you write a padding operator to make 10px borders for the images, then your output shape will be (234,234,3). -* **forward**: This function executes the main forward computation. It takes four arguments. The 1st argument is the attributes. The 2nd argument is the input `MXTensors` which stores all data and info of input ndarrays. The 3rd argument is the output `MXTensors`. The 4th argument is the `OpResource` object for memory allocation and other utilities. Additionally, you can use a `dltensor` tensor structure stored in the `MXTensor` as a more standardized data structure for computing. +* **forward**: This function executes the main forward computation. It takes four arguments. The 1st argument is the attributes. The 2nd argument is the input `MXTensors` which stores all data and info of input ndarrays. The 3rd argument is the output `MXTensors`. The 4th argument is the `OpResource` object for memory allocation and other utilities. The details of `OpResource` are covered in the below section. +Additionally, you can use a `dltensor` tensor structure stored in the `MXTensor` as a more standardized data structure for computing. * **backward**: This function is doing the backward gradient computation. It will be similar to the forward function. And you need to figure out the formula of the backward gradient computation. * **mutateInputs**: This function is for marking mutable inputs. It takes two arguments. The 1st argument is the attributes. The 2nd argument is a list of input indices that are mutable among all input tensors. It is useful when some inputs are auxiliary model parameters and might be altered during forward/backward computation. Remember, the index number of `input_indices` should not exceed the number of inputs. -### Writing Stateful Custom Operator: +### Writing Stateful Custom Operator A stateful custom operator is useful when a forward/backward call needs some data or ‘state’ from previous forward/backward calls. Normally we create a class, and make instance variables store the states used for computing or caching. Most of the building blocks for making a stateful custom operator is the same as regular custom operator, except it’ll register `createOpState` instead of a `forward` function for the computation. * [createOpState](./gemm_lib.cc#L204) - Create stateful operator instance: * This function takes two arguments. The 1st argument is attributes. The 2nd argument is a placeholder for `CustomStatefulOp` object. You must [define a class that inherits CustomStatefulOp](./gemm_lib.cc#L178) and override the forward function (optionally the backward function). Then you need to create an instance of your class and assign it to the placeholder. In this way, all of the forward/backward calls will use the same methods in that instance, and the instance is able to keep the state of the operator. +```c++ +MXReturnValue createOpState( +std::map attrs, +CustomStatefulOp** op_inst) +``` + +* The operator registering function will look like this: +```c++ +REGISTER_OP(my_state_op) +... +.setCreateOpState(createOpState, "cpu"); +``` + +## Writing A Custom GPU Operator Library + +Most of the building blocks for registering GPU custom operators are the exactly same as CPU ones, except you need to specify the `"gpu"` context name when registering `forward`, `backward` or `createOpState` function. + +### Run A GPU Example + +For illustration purposes, we provided a `ReLU` (Rectified Linear Unit) activation operator that can run on GPU. Make sure you have installed a CUDA compatible MXNet build. Go to `lib_custom_op` directory and follow these steps: + +1. Run `make relu_lib`. The Makefile will invoke `NVCC` compiler to compile the CUDA kernel along with regular custom operator functions from `relu_lib.cu` to generate `librelu_lib.so` library. +2. Run `python test_relu.py`. It’ll register the GPU `ReLU` operator in the MXNet backend, then invoke the operator by feeding an `NDArray` input with GPU context, and output the result tensor with GPU context. + +### Writing A Regular GPU Custom Operator + +Since most of the building blocks for registering GPU custom operators are the exactly same as CPU ones, the registering function for an operator supporting both GPU and CPU will look like this: + +`
[GitHub] [incubator-mxnet] samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support
samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support URL: https://github.com/apache/incubator-mxnet/pull/17486#discussion_r375027065 ## File path: example/extensions/lib_custom_op/README.md ## @@ -146,21 +186,160 @@ Let’s take a closer look at those registry functions: * **inferShape**: This function is similar to the `inferType` function, except it is used for populating the output data shapes. You need to figure out the shapes of each output tensors for this computation. For example, if the inputs are images with shape (224,224,3) and you write a padding operator to make 10px borders for the images, then your output shape will be (234,234,3). -* **forward**: This function executes the main forward computation. It takes four arguments. The 1st argument is the attributes. The 2nd argument is the input `MXTensors` which stores all data and info of input ndarrays. The 3rd argument is the output `MXTensors`. The 4th argument is the `OpResource` object for memory allocation and other utilities. Additionally, you can use a `dltensor` tensor structure stored in the `MXTensor` as a more standardized data structure for computing. +* **forward**: This function executes the main forward computation. It takes four arguments. The 1st argument is the attributes. The 2nd argument is the input `MXTensors` which stores all data and info of input ndarrays. The 3rd argument is the output `MXTensors`. The 4th argument is the `OpResource` object for memory allocation and other utilities. The details of `OpResource` are covered in the below section. +Additionally, you can use a `dltensor` tensor structure stored in the `MXTensor` as a more standardized data structure for computing. * **backward**: This function is doing the backward gradient computation. It will be similar to the forward function. And you need to figure out the formula of the backward gradient computation. * **mutateInputs**: This function is for marking mutable inputs. It takes two arguments. The 1st argument is the attributes. The 2nd argument is a list of input indices that are mutable among all input tensors. It is useful when some inputs are auxiliary model parameters and might be altered during forward/backward computation. Remember, the index number of `input_indices` should not exceed the number of inputs. -### Writing Stateful Custom Operator: +### Writing Stateful Custom Operator A stateful custom operator is useful when a forward/backward call needs some data or ‘state’ from previous forward/backward calls. Normally we create a class, and make instance variables store the states used for computing or caching. Most of the building blocks for making a stateful custom operator is the same as regular custom operator, except it’ll register `createOpState` instead of a `forward` function for the computation. * [createOpState](./gemm_lib.cc#L204) - Create stateful operator instance: * This function takes two arguments. The 1st argument is attributes. The 2nd argument is a placeholder for `CustomStatefulOp` object. You must [define a class that inherits CustomStatefulOp](./gemm_lib.cc#L178) and override the forward function (optionally the backward function). Then you need to create an instance of your class and assign it to the placeholder. In this way, all of the forward/backward calls will use the same methods in that instance, and the instance is able to keep the state of the operator. +```c++ +MXReturnValue createOpState( +std::map attrs, +CustomStatefulOp** op_inst) +``` + +* The operator registering function will look like this: +```c++ +REGISTER_OP(my_state_op) +... +.setCreateOpState(createOpState, "cpu"); +``` + +## Writing A Custom GPU Operator Library + +Most of the building blocks for registering GPU custom operators are the exactly same as CPU ones, except you need to specify the `"gpu"` context name when registering `forward`, `backward` or `createOpState` function. + +### Run A GPU Example + +For illustration purposes, we provided a `ReLU` (Rectified Linear Unit) activation operator that can run on GPU. Make sure you have installed a CUDA compatible MXNet build. Go to `lib_custom_op` directory and follow these steps: + +1. Run `make relu_lib`. The Makefile will invoke `NVCC` compiler to compile the CUDA kernel along with regular custom operator functions from `relu_lib.cu` to generate `librelu_lib.so` library. +2. Run `python test_relu.py`. It’ll register the GPU `ReLU` operator in the MXNet backend, then invoke the operator by feeding an `NDArray` input with GPU context, and output the result tensor with GPU context. + +### Writing A Regular GPU Custom Operator + +Since most of the building blocks for registering GPU custom operators are the exactly same as CPU ones, the registering function for an operator supporting both GPU and CPU will look like this: + +`
[GitHub] [incubator-mxnet] samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support
samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support URL: https://github.com/apache/incubator-mxnet/pull/17486#discussion_r375025679 ## File path: example/extensions/lib_custom_op/README.md ## @@ -146,21 +186,160 @@ Let’s take a closer look at those registry functions: * **inferShape**: This function is similar to the `inferType` function, except it is used for populating the output data shapes. You need to figure out the shapes of each output tensors for this computation. For example, if the inputs are images with shape (224,224,3) and you write a padding operator to make 10px borders for the images, then your output shape will be (234,234,3). -* **forward**: This function executes the main forward computation. It takes four arguments. The 1st argument is the attributes. The 2nd argument is the input `MXTensors` which stores all data and info of input ndarrays. The 3rd argument is the output `MXTensors`. The 4th argument is the `OpResource` object for memory allocation and other utilities. Additionally, you can use a `dltensor` tensor structure stored in the `MXTensor` as a more standardized data structure for computing. +* **forward**: This function executes the main forward computation. It takes four arguments. The 1st argument is the attributes. The 2nd argument is the input `MXTensors` which stores all data and info of input ndarrays. The 3rd argument is the output `MXTensors`. The 4th argument is the `OpResource` object for memory allocation and other utilities. The details of `OpResource` are covered in the below section. +Additionally, you can use a `dltensor` tensor structure stored in the `MXTensor` as a more standardized data structure for computing. * **backward**: This function is doing the backward gradient computation. It will be similar to the forward function. And you need to figure out the formula of the backward gradient computation. * **mutateInputs**: This function is for marking mutable inputs. It takes two arguments. The 1st argument is the attributes. The 2nd argument is a list of input indices that are mutable among all input tensors. It is useful when some inputs are auxiliary model parameters and might be altered during forward/backward computation. Remember, the index number of `input_indices` should not exceed the number of inputs. -### Writing Stateful Custom Operator: +### Writing Stateful Custom Operator A stateful custom operator is useful when a forward/backward call needs some data or ‘state’ from previous forward/backward calls. Normally we create a class, and make instance variables store the states used for computing or caching. Most of the building blocks for making a stateful custom operator is the same as regular custom operator, except it’ll register `createOpState` instead of a `forward` function for the computation. * [createOpState](./gemm_lib.cc#L204) - Create stateful operator instance: * This function takes two arguments. The 1st argument is attributes. The 2nd argument is a placeholder for `CustomStatefulOp` object. You must [define a class that inherits CustomStatefulOp](./gemm_lib.cc#L178) and override the forward function (optionally the backward function). Then you need to create an instance of your class and assign it to the placeholder. In this way, all of the forward/backward calls will use the same methods in that instance, and the instance is able to keep the state of the operator. +```c++ +MXReturnValue createOpState( +std::map attrs, +CustomStatefulOp** op_inst) +``` + +* The operator registering function will look like this: +```c++ +REGISTER_OP(my_state_op) +... +.setCreateOpState(createOpState, "cpu"); +``` + +## Writing A Custom GPU Operator Library + +Most of the building blocks for registering GPU custom operators are the exactly same as CPU ones, except you need to specify the `"gpu"` context name when registering `forward`, `backward` or `createOpState` function. + +### Run A GPU Example + +For illustration purposes, we provided a `ReLU` (Rectified Linear Unit) activation operator that can run on GPU. Make sure you have installed a CUDA compatible MXNet build. Go to `lib_custom_op` directory and follow these steps: + +1. Run `make relu_lib`. The Makefile will invoke `NVCC` compiler to compile the CUDA kernel along with regular custom operator functions from `relu_lib.cu` to generate `librelu_lib.so` library. +2. Run `python test_relu.py`. It’ll register the GPU `ReLU` operator in the MXNet backend, then invoke the operator by feeding an `NDArray` input with GPU context, and output the result tensor with GPU context. + +### Writing A Regular GPU Custom Operator + +Since most of the building blocks for registering GPU custom operators are the exactly same as CPU ones, the registering function for an operator supporting both GPU and CPU will look like this: + +`
[GitHub] [incubator-mxnet] samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support
samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support URL: https://github.com/apache/incubator-mxnet/pull/17486#discussion_r375025352 ## File path: example/extensions/lib_custom_op/README.md ## @@ -146,21 +186,160 @@ Let’s take a closer look at those registry functions: * **inferShape**: This function is similar to the `inferType` function, except it is used for populating the output data shapes. You need to figure out the shapes of each output tensors for this computation. For example, if the inputs are images with shape (224,224,3) and you write a padding operator to make 10px borders for the images, then your output shape will be (234,234,3). -* **forward**: This function executes the main forward computation. It takes four arguments. The 1st argument is the attributes. The 2nd argument is the input `MXTensors` which stores all data and info of input ndarrays. The 3rd argument is the output `MXTensors`. The 4th argument is the `OpResource` object for memory allocation and other utilities. Additionally, you can use a `dltensor` tensor structure stored in the `MXTensor` as a more standardized data structure for computing. +* **forward**: This function executes the main forward computation. It takes four arguments. The 1st argument is the attributes. The 2nd argument is the input `MXTensors` which stores all data and info of input ndarrays. The 3rd argument is the output `MXTensors`. The 4th argument is the `OpResource` object for memory allocation and other utilities. The details of `OpResource` are covered in the below section. +Additionally, you can use a `dltensor` tensor structure stored in the `MXTensor` as a more standardized data structure for computing. * **backward**: This function is doing the backward gradient computation. It will be similar to the forward function. And you need to figure out the formula of the backward gradient computation. * **mutateInputs**: This function is for marking mutable inputs. It takes two arguments. The 1st argument is the attributes. The 2nd argument is a list of input indices that are mutable among all input tensors. It is useful when some inputs are auxiliary model parameters and might be altered during forward/backward computation. Remember, the index number of `input_indices` should not exceed the number of inputs. -### Writing Stateful Custom Operator: +### Writing Stateful Custom Operator A stateful custom operator is useful when a forward/backward call needs some data or ‘state’ from previous forward/backward calls. Normally we create a class, and make instance variables store the states used for computing or caching. Most of the building blocks for making a stateful custom operator is the same as regular custom operator, except it’ll register `createOpState` instead of a `forward` function for the computation. * [createOpState](./gemm_lib.cc#L204) - Create stateful operator instance: * This function takes two arguments. The 1st argument is attributes. The 2nd argument is a placeholder for `CustomStatefulOp` object. You must [define a class that inherits CustomStatefulOp](./gemm_lib.cc#L178) and override the forward function (optionally the backward function). Then you need to create an instance of your class and assign it to the placeholder. In this way, all of the forward/backward calls will use the same methods in that instance, and the instance is able to keep the state of the operator. +```c++ +MXReturnValue createOpState( +std::map attrs, +CustomStatefulOp** op_inst) +``` + +* The operator registering function will look like this: +```c++ +REGISTER_OP(my_state_op) +... +.setCreateOpState(createOpState, "cpu"); +``` + +## Writing A Custom GPU Operator Library + +Most of the building blocks for registering GPU custom operators are the exactly same as CPU ones, except you need to specify the `"gpu"` context name when registering `forward`, `backward` or `createOpState` function. + +### Run A GPU Example + +For illustration purposes, we provided a `ReLU` (Rectified Linear Unit) activation operator that can run on GPU. Make sure you have installed a CUDA compatible MXNet build. Go to `lib_custom_op` directory and follow these steps: + +1. Run `make relu_lib`. The Makefile will invoke `NVCC` compiler to compile the CUDA kernel along with regular custom operator functions from `relu_lib.cu` to generate `librelu_lib.so` library. +2. Run `python test_relu.py`. It’ll register the GPU `ReLU` operator in the MXNet backend, then invoke the operator by feeding an `NDArray` input with GPU context, and output the result tensor with GPU context. + +### Writing A Regular GPU Custom Operator + +Since most of the building blocks for registering GPU custom operators are the exactly same as CPU ones, the registering function for an operator supporting both GPU and CPU will look like this: + +`
[GitHub] [incubator-mxnet] samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support
samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support URL: https://github.com/apache/incubator-mxnet/pull/17486#discussion_r375024885 ## File path: example/extensions/lib_custom_op/README.md ## @@ -146,21 +186,160 @@ Let’s take a closer look at those registry functions: * **inferShape**: This function is similar to the `inferType` function, except it is used for populating the output data shapes. You need to figure out the shapes of each output tensors for this computation. For example, if the inputs are images with shape (224,224,3) and you write a padding operator to make 10px borders for the images, then your output shape will be (234,234,3). -* **forward**: This function executes the main forward computation. It takes four arguments. The 1st argument is the attributes. The 2nd argument is the input `MXTensors` which stores all data and info of input ndarrays. The 3rd argument is the output `MXTensors`. The 4th argument is the `OpResource` object for memory allocation and other utilities. Additionally, you can use a `dltensor` tensor structure stored in the `MXTensor` as a more standardized data structure for computing. +* **forward**: This function executes the main forward computation. It takes four arguments. The 1st argument is the attributes. The 2nd argument is the input `MXTensors` which stores all data and info of input ndarrays. The 3rd argument is the output `MXTensors`. The 4th argument is the `OpResource` object for memory allocation and other utilities. The details of `OpResource` are covered in the below section. +Additionally, you can use a `dltensor` tensor structure stored in the `MXTensor` as a more standardized data structure for computing. * **backward**: This function is doing the backward gradient computation. It will be similar to the forward function. And you need to figure out the formula of the backward gradient computation. * **mutateInputs**: This function is for marking mutable inputs. It takes two arguments. The 1st argument is the attributes. The 2nd argument is a list of input indices that are mutable among all input tensors. It is useful when some inputs are auxiliary model parameters and might be altered during forward/backward computation. Remember, the index number of `input_indices` should not exceed the number of inputs. -### Writing Stateful Custom Operator: +### Writing Stateful Custom Operator A stateful custom operator is useful when a forward/backward call needs some data or ‘state’ from previous forward/backward calls. Normally we create a class, and make instance variables store the states used for computing or caching. Most of the building blocks for making a stateful custom operator is the same as regular custom operator, except it’ll register `createOpState` instead of a `forward` function for the computation. * [createOpState](./gemm_lib.cc#L204) - Create stateful operator instance: * This function takes two arguments. The 1st argument is attributes. The 2nd argument is a placeholder for `CustomStatefulOp` object. You must [define a class that inherits CustomStatefulOp](./gemm_lib.cc#L178) and override the forward function (optionally the backward function). Then you need to create an instance of your class and assign it to the placeholder. In this way, all of the forward/backward calls will use the same methods in that instance, and the instance is able to keep the state of the operator. +```c++ +MXReturnValue createOpState( +std::map attrs, +CustomStatefulOp** op_inst) +``` + +* The operator registering function will look like this: +```c++ +REGISTER_OP(my_state_op) +... +.setCreateOpState(createOpState, "cpu"); +``` + +## Writing A Custom GPU Operator Library + +Most of the building blocks for registering GPU custom operators are the exactly same as CPU ones, except you need to specify the `"gpu"` context name when registering `forward`, `backward` or `createOpState` function. + +### Run A GPU Example + +For illustration purposes, we provided a `ReLU` (Rectified Linear Unit) activation operator that can run on GPU. Make sure you have installed a CUDA compatible MXNet build. Go to `lib_custom_op` directory and follow these steps: + +1. Run `make relu_lib`. The Makefile will invoke `NVCC` compiler to compile the CUDA kernel along with regular custom operator functions from `relu_lib.cu` to generate `librelu_lib.so` library. +2. Run `python test_relu.py`. It’ll register the GPU `ReLU` operator in the MXNet backend, then invoke the operator by feeding an `NDArray` input with GPU context, and output the result tensor with GPU context. + +### Writing A Regular GPU Custom Operator + +Since most of the building blocks for registering GPU custom operators are the exactly same as CPU ones, the registering function for an operator supporting both GPU and CPU will look like this: + +`
[GitHub] [incubator-mxnet] samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support
samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support URL: https://github.com/apache/incubator-mxnet/pull/17486#discussion_r375024525 ## File path: example/extensions/lib_custom_op/README.md ## @@ -146,21 +186,160 @@ Let’s take a closer look at those registry functions: * **inferShape**: This function is similar to the `inferType` function, except it is used for populating the output data shapes. You need to figure out the shapes of each output tensors for this computation. For example, if the inputs are images with shape (224,224,3) and you write a padding operator to make 10px borders for the images, then your output shape will be (234,234,3). -* **forward**: This function executes the main forward computation. It takes four arguments. The 1st argument is the attributes. The 2nd argument is the input `MXTensors` which stores all data and info of input ndarrays. The 3rd argument is the output `MXTensors`. The 4th argument is the `OpResource` object for memory allocation and other utilities. Additionally, you can use a `dltensor` tensor structure stored in the `MXTensor` as a more standardized data structure for computing. +* **forward**: This function executes the main forward computation. It takes four arguments. The 1st argument is the attributes. The 2nd argument is the input `MXTensors` which stores all data and info of input ndarrays. The 3rd argument is the output `MXTensors`. The 4th argument is the `OpResource` object for memory allocation and other utilities. The details of `OpResource` are covered in the below section. +Additionally, you can use a `dltensor` tensor structure stored in the `MXTensor` as a more standardized data structure for computing. * **backward**: This function is doing the backward gradient computation. It will be similar to the forward function. And you need to figure out the formula of the backward gradient computation. * **mutateInputs**: This function is for marking mutable inputs. It takes two arguments. The 1st argument is the attributes. The 2nd argument is a list of input indices that are mutable among all input tensors. It is useful when some inputs are auxiliary model parameters and might be altered during forward/backward computation. Remember, the index number of `input_indices` should not exceed the number of inputs. -### Writing Stateful Custom Operator: +### Writing Stateful Custom Operator A stateful custom operator is useful when a forward/backward call needs some data or ‘state’ from previous forward/backward calls. Normally we create a class, and make instance variables store the states used for computing or caching. Most of the building blocks for making a stateful custom operator is the same as regular custom operator, except it’ll register `createOpState` instead of a `forward` function for the computation. * [createOpState](./gemm_lib.cc#L204) - Create stateful operator instance: * This function takes two arguments. The 1st argument is attributes. The 2nd argument is a placeholder for `CustomStatefulOp` object. You must [define a class that inherits CustomStatefulOp](./gemm_lib.cc#L178) and override the forward function (optionally the backward function). Then you need to create an instance of your class and assign it to the placeholder. In this way, all of the forward/backward calls will use the same methods in that instance, and the instance is able to keep the state of the operator. +```c++ +MXReturnValue createOpState( +std::map attrs, +CustomStatefulOp** op_inst) +``` + +* The operator registering function will look like this: +```c++ +REGISTER_OP(my_state_op) +... +.setCreateOpState(createOpState, "cpu"); +``` + +## Writing A Custom GPU Operator Library + +Most of the building blocks for registering GPU custom operators are the exactly same as CPU ones, except you need to specify the `"gpu"` context name when registering `forward`, `backward` or `createOpState` function. + +### Run A GPU Example + +For illustration purposes, we provided a `ReLU` (Rectified Linear Unit) activation operator that can run on GPU. Make sure you have installed a CUDA compatible MXNet build. Go to `lib_custom_op` directory and follow these steps: + +1. Run `make relu_lib`. The Makefile will invoke `NVCC` compiler to compile the CUDA kernel along with regular custom operator functions from `relu_lib.cu` to generate `librelu_lib.so` library. +2. Run `python test_relu.py`. It’ll register the GPU `ReLU` operator in the MXNet backend, then invoke the operator by feeding an `NDArray` input with GPU context, and output the result tensor with GPU context. + +### Writing A Regular GPU Custom Operator + +Since most of the building blocks for registering GPU custom operators are the exactly same as CPU ones, the registering function for an operator supporting both GPU and CPU will look like this: + +`
[GitHub] [incubator-mxnet] samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support
samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support URL: https://github.com/apache/incubator-mxnet/pull/17486#discussion_r375024388 ## File path: example/extensions/lib_custom_op/README.md ## @@ -146,21 +186,160 @@ Let’s take a closer look at those registry functions: * **inferShape**: This function is similar to the `inferType` function, except it is used for populating the output data shapes. You need to figure out the shapes of each output tensors for this computation. For example, if the inputs are images with shape (224,224,3) and you write a padding operator to make 10px borders for the images, then your output shape will be (234,234,3). -* **forward**: This function executes the main forward computation. It takes four arguments. The 1st argument is the attributes. The 2nd argument is the input `MXTensors` which stores all data and info of input ndarrays. The 3rd argument is the output `MXTensors`. The 4th argument is the `OpResource` object for memory allocation and other utilities. Additionally, you can use a `dltensor` tensor structure stored in the `MXTensor` as a more standardized data structure for computing. +* **forward**: This function executes the main forward computation. It takes four arguments. The 1st argument is the attributes. The 2nd argument is the input `MXTensors` which stores all data and info of input ndarrays. The 3rd argument is the output `MXTensors`. The 4th argument is the `OpResource` object for memory allocation and other utilities. The details of `OpResource` are covered in the below section. +Additionally, you can use a `dltensor` tensor structure stored in the `MXTensor` as a more standardized data structure for computing. * **backward**: This function is doing the backward gradient computation. It will be similar to the forward function. And you need to figure out the formula of the backward gradient computation. * **mutateInputs**: This function is for marking mutable inputs. It takes two arguments. The 1st argument is the attributes. The 2nd argument is a list of input indices that are mutable among all input tensors. It is useful when some inputs are auxiliary model parameters and might be altered during forward/backward computation. Remember, the index number of `input_indices` should not exceed the number of inputs. -### Writing Stateful Custom Operator: +### Writing Stateful Custom Operator A stateful custom operator is useful when a forward/backward call needs some data or ‘state’ from previous forward/backward calls. Normally we create a class, and make instance variables store the states used for computing or caching. Most of the building blocks for making a stateful custom operator is the same as regular custom operator, except it’ll register `createOpState` instead of a `forward` function for the computation. * [createOpState](./gemm_lib.cc#L204) - Create stateful operator instance: * This function takes two arguments. The 1st argument is attributes. The 2nd argument is a placeholder for `CustomStatefulOp` object. You must [define a class that inherits CustomStatefulOp](./gemm_lib.cc#L178) and override the forward function (optionally the backward function). Then you need to create an instance of your class and assign it to the placeholder. In this way, all of the forward/backward calls will use the same methods in that instance, and the instance is able to keep the state of the operator. +```c++ +MXReturnValue createOpState( +std::map attrs, +CustomStatefulOp** op_inst) +``` + +* The operator registering function will look like this: +```c++ +REGISTER_OP(my_state_op) +... +.setCreateOpState(createOpState, "cpu"); +``` + +## Writing A Custom GPU Operator Library + +Most of the building blocks for registering GPU custom operators are the exactly same as CPU ones, except you need to specify the `"gpu"` context name when registering `forward`, `backward` or `createOpState` function. + +### Run A GPU Example + +For illustration purposes, we provided a `ReLU` (Rectified Linear Unit) activation operator that can run on GPU. Make sure you have installed a CUDA compatible MXNet build. Go to `lib_custom_op` directory and follow these steps: + +1. Run `make relu_lib`. The Makefile will invoke `NVCC` compiler to compile the CUDA kernel along with regular custom operator functions from `relu_lib.cu` to generate `librelu_lib.so` library. +2. Run `python test_relu.py`. It’ll register the GPU `ReLU` operator in the MXNet backend, then invoke the operator by feeding an `NDArray` input with GPU context, and output the result tensor with GPU context. + +### Writing A Regular GPU Custom Operator + +Since most of the building blocks for registering GPU custom operators are the exactly same as CPU ones, the registering function for an operator supporting both GPU and CPU will look like this: + +`
[GitHub] [incubator-mxnet] samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support
samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support URL: https://github.com/apache/incubator-mxnet/pull/17486#discussion_r375023931 ## File path: example/extensions/lib_custom_op/README.md ## @@ -146,21 +186,160 @@ Let’s take a closer look at those registry functions: * **inferShape**: This function is similar to the `inferType` function, except it is used for populating the output data shapes. You need to figure out the shapes of each output tensors for this computation. For example, if the inputs are images with shape (224,224,3) and you write a padding operator to make 10px borders for the images, then your output shape will be (234,234,3). -* **forward**: This function executes the main forward computation. It takes four arguments. The 1st argument is the attributes. The 2nd argument is the input `MXTensors` which stores all data and info of input ndarrays. The 3rd argument is the output `MXTensors`. The 4th argument is the `OpResource` object for memory allocation and other utilities. Additionally, you can use a `dltensor` tensor structure stored in the `MXTensor` as a more standardized data structure for computing. +* **forward**: This function executes the main forward computation. It takes four arguments. The 1st argument is the attributes. The 2nd argument is the input `MXTensors` which stores all data and info of input ndarrays. The 3rd argument is the output `MXTensors`. The 4th argument is the `OpResource` object for memory allocation and other utilities. The details of `OpResource` are covered in the below section. +Additionally, you can use a `dltensor` tensor structure stored in the `MXTensor` as a more standardized data structure for computing. * **backward**: This function is doing the backward gradient computation. It will be similar to the forward function. And you need to figure out the formula of the backward gradient computation. * **mutateInputs**: This function is for marking mutable inputs. It takes two arguments. The 1st argument is the attributes. The 2nd argument is a list of input indices that are mutable among all input tensors. It is useful when some inputs are auxiliary model parameters and might be altered during forward/backward computation. Remember, the index number of `input_indices` should not exceed the number of inputs. -### Writing Stateful Custom Operator: +### Writing Stateful Custom Operator A stateful custom operator is useful when a forward/backward call needs some data or ‘state’ from previous forward/backward calls. Normally we create a class, and make instance variables store the states used for computing or caching. Most of the building blocks for making a stateful custom operator is the same as regular custom operator, except it’ll register `createOpState` instead of a `forward` function for the computation. * [createOpState](./gemm_lib.cc#L204) - Create stateful operator instance: * This function takes two arguments. The 1st argument is attributes. The 2nd argument is a placeholder for `CustomStatefulOp` object. You must [define a class that inherits CustomStatefulOp](./gemm_lib.cc#L178) and override the forward function (optionally the backward function). Then you need to create an instance of your class and assign it to the placeholder. In this way, all of the forward/backward calls will use the same methods in that instance, and the instance is able to keep the state of the operator. +```c++ +MXReturnValue createOpState( +std::map attrs, +CustomStatefulOp** op_inst) +``` + +* The operator registering function will look like this: +```c++ +REGISTER_OP(my_state_op) +... +.setCreateOpState(createOpState, "cpu"); +``` + +## Writing A Custom GPU Operator Library + +Most of the building blocks for registering GPU custom operators are the exactly same as CPU ones, except you need to specify the `"gpu"` context name when registering `forward`, `backward` or `createOpState` function. + +### Run A GPU Example + +For illustration purposes, we provided a `ReLU` (Rectified Linear Unit) activation operator that can run on GPU. Make sure you have installed a CUDA compatible MXNet build. Go to `lib_custom_op` directory and follow these steps: + +1. Run `make relu_lib`. The Makefile will invoke `NVCC` compiler to compile the CUDA kernel along with regular custom operator functions from `relu_lib.cu` to generate `librelu_lib.so` library. +2. Run `python test_relu.py`. It’ll register the GPU `ReLU` operator in the MXNet backend, then invoke the operator by feeding an `NDArray` input with GPU context, and output the result tensor with GPU context. Review comment: feeding --> passing NDArray --> MXTensor This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use
[GitHub] [incubator-mxnet] samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support
samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support URL: https://github.com/apache/incubator-mxnet/pull/17486#discussion_r375023931 ## File path: example/extensions/lib_custom_op/README.md ## @@ -146,21 +186,160 @@ Let’s take a closer look at those registry functions: * **inferShape**: This function is similar to the `inferType` function, except it is used for populating the output data shapes. You need to figure out the shapes of each output tensors for this computation. For example, if the inputs are images with shape (224,224,3) and you write a padding operator to make 10px borders for the images, then your output shape will be (234,234,3). -* **forward**: This function executes the main forward computation. It takes four arguments. The 1st argument is the attributes. The 2nd argument is the input `MXTensors` which stores all data and info of input ndarrays. The 3rd argument is the output `MXTensors`. The 4th argument is the `OpResource` object for memory allocation and other utilities. Additionally, you can use a `dltensor` tensor structure stored in the `MXTensor` as a more standardized data structure for computing. +* **forward**: This function executes the main forward computation. It takes four arguments. The 1st argument is the attributes. The 2nd argument is the input `MXTensors` which stores all data and info of input ndarrays. The 3rd argument is the output `MXTensors`. The 4th argument is the `OpResource` object for memory allocation and other utilities. The details of `OpResource` are covered in the below section. +Additionally, you can use a `dltensor` tensor structure stored in the `MXTensor` as a more standardized data structure for computing. * **backward**: This function is doing the backward gradient computation. It will be similar to the forward function. And you need to figure out the formula of the backward gradient computation. * **mutateInputs**: This function is for marking mutable inputs. It takes two arguments. The 1st argument is the attributes. The 2nd argument is a list of input indices that are mutable among all input tensors. It is useful when some inputs are auxiliary model parameters and might be altered during forward/backward computation. Remember, the index number of `input_indices` should not exceed the number of inputs. -### Writing Stateful Custom Operator: +### Writing Stateful Custom Operator A stateful custom operator is useful when a forward/backward call needs some data or ‘state’ from previous forward/backward calls. Normally we create a class, and make instance variables store the states used for computing or caching. Most of the building blocks for making a stateful custom operator is the same as regular custom operator, except it’ll register `createOpState` instead of a `forward` function for the computation. * [createOpState](./gemm_lib.cc#L204) - Create stateful operator instance: * This function takes two arguments. The 1st argument is attributes. The 2nd argument is a placeholder for `CustomStatefulOp` object. You must [define a class that inherits CustomStatefulOp](./gemm_lib.cc#L178) and override the forward function (optionally the backward function). Then you need to create an instance of your class and assign it to the placeholder. In this way, all of the forward/backward calls will use the same methods in that instance, and the instance is able to keep the state of the operator. +```c++ +MXReturnValue createOpState( +std::map attrs, +CustomStatefulOp** op_inst) +``` + +* The operator registering function will look like this: +```c++ +REGISTER_OP(my_state_op) +... +.setCreateOpState(createOpState, "cpu"); +``` + +## Writing A Custom GPU Operator Library + +Most of the building blocks for registering GPU custom operators are the exactly same as CPU ones, except you need to specify the `"gpu"` context name when registering `forward`, `backward` or `createOpState` function. + +### Run A GPU Example + +For illustration purposes, we provided a `ReLU` (Rectified Linear Unit) activation operator that can run on GPU. Make sure you have installed a CUDA compatible MXNet build. Go to `lib_custom_op` directory and follow these steps: + +1. Run `make relu_lib`. The Makefile will invoke `NVCC` compiler to compile the CUDA kernel along with regular custom operator functions from `relu_lib.cu` to generate `librelu_lib.so` library. +2. Run `python test_relu.py`. It’ll register the GPU `ReLU` operator in the MXNet backend, then invoke the operator by feeding an `NDArray` input with GPU context, and output the result tensor with GPU context. Review comment: feeding --> passing This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to t
[GitHub] [incubator-mxnet] samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support
samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support URL: https://github.com/apache/incubator-mxnet/pull/17486#discussion_r375023718 ## File path: example/extensions/lib_custom_op/README.md ## @@ -146,21 +186,160 @@ Let’s take a closer look at those registry functions: * **inferShape**: This function is similar to the `inferType` function, except it is used for populating the output data shapes. You need to figure out the shapes of each output tensors for this computation. For example, if the inputs are images with shape (224,224,3) and you write a padding operator to make 10px borders for the images, then your output shape will be (234,234,3). -* **forward**: This function executes the main forward computation. It takes four arguments. The 1st argument is the attributes. The 2nd argument is the input `MXTensors` which stores all data and info of input ndarrays. The 3rd argument is the output `MXTensors`. The 4th argument is the `OpResource` object for memory allocation and other utilities. Additionally, you can use a `dltensor` tensor structure stored in the `MXTensor` as a more standardized data structure for computing. +* **forward**: This function executes the main forward computation. It takes four arguments. The 1st argument is the attributes. The 2nd argument is the input `MXTensors` which stores all data and info of input ndarrays. The 3rd argument is the output `MXTensors`. The 4th argument is the `OpResource` object for memory allocation and other utilities. The details of `OpResource` are covered in the below section. +Additionally, you can use a `dltensor` tensor structure stored in the `MXTensor` as a more standardized data structure for computing. * **backward**: This function is doing the backward gradient computation. It will be similar to the forward function. And you need to figure out the formula of the backward gradient computation. * **mutateInputs**: This function is for marking mutable inputs. It takes two arguments. The 1st argument is the attributes. The 2nd argument is a list of input indices that are mutable among all input tensors. It is useful when some inputs are auxiliary model parameters and might be altered during forward/backward computation. Remember, the index number of `input_indices` should not exceed the number of inputs. -### Writing Stateful Custom Operator: +### Writing Stateful Custom Operator A stateful custom operator is useful when a forward/backward call needs some data or ‘state’ from previous forward/backward calls. Normally we create a class, and make instance variables store the states used for computing or caching. Most of the building blocks for making a stateful custom operator is the same as regular custom operator, except it’ll register `createOpState` instead of a `forward` function for the computation. * [createOpState](./gemm_lib.cc#L204) - Create stateful operator instance: * This function takes two arguments. The 1st argument is attributes. The 2nd argument is a placeholder for `CustomStatefulOp` object. You must [define a class that inherits CustomStatefulOp](./gemm_lib.cc#L178) and override the forward function (optionally the backward function). Then you need to create an instance of your class and assign it to the placeholder. In this way, all of the forward/backward calls will use the same methods in that instance, and the instance is able to keep the state of the operator. +```c++ +MXReturnValue createOpState( +std::map attrs, +CustomStatefulOp** op_inst) +``` + +* The operator registering function will look like this: +```c++ +REGISTER_OP(my_state_op) +... +.setCreateOpState(createOpState, "cpu"); +``` + Review comment: Notice that you will need to register each `createOpState` function specific for each context you operator will support. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support
samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support URL: https://github.com/apache/incubator-mxnet/pull/17486#discussion_r375023276 ## File path: example/extensions/lib_custom_op/README.md ## @@ -146,21 +186,160 @@ Let’s take a closer look at those registry functions: * **inferShape**: This function is similar to the `inferType` function, except it is used for populating the output data shapes. You need to figure out the shapes of each output tensors for this computation. For example, if the inputs are images with shape (224,224,3) and you write a padding operator to make 10px borders for the images, then your output shape will be (234,234,3). -* **forward**: This function executes the main forward computation. It takes four arguments. The 1st argument is the attributes. The 2nd argument is the input `MXTensors` which stores all data and info of input ndarrays. The 3rd argument is the output `MXTensors`. The 4th argument is the `OpResource` object for memory allocation and other utilities. Additionally, you can use a `dltensor` tensor structure stored in the `MXTensor` as a more standardized data structure for computing. +* **forward**: This function executes the main forward computation. It takes four arguments. The 1st argument is the attributes. The 2nd argument is the input `MXTensors` which stores all data and info of input ndarrays. The 3rd argument is the output `MXTensors`. The 4th argument is the `OpResource` object for memory allocation and other utilities. The details of `OpResource` are covered in the below section. Review comment: "in the below section" --> "in the section below" This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support
samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support URL: https://github.com/apache/incubator-mxnet/pull/17486#discussion_r375023372 ## File path: example/extensions/lib_custom_op/README.md ## @@ -146,21 +186,160 @@ Let’s take a closer look at those registry functions: * **inferShape**: This function is similar to the `inferType` function, except it is used for populating the output data shapes. You need to figure out the shapes of each output tensors for this computation. For example, if the inputs are images with shape (224,224,3) and you write a padding operator to make 10px borders for the images, then your output shape will be (234,234,3). -* **forward**: This function executes the main forward computation. It takes four arguments. The 1st argument is the attributes. The 2nd argument is the input `MXTensors` which stores all data and info of input ndarrays. The 3rd argument is the output `MXTensors`. The 4th argument is the `OpResource` object for memory allocation and other utilities. Additionally, you can use a `dltensor` tensor structure stored in the `MXTensor` as a more standardized data structure for computing. +* **forward**: This function executes the main forward computation. It takes four arguments. The 1st argument is the attributes. The 2nd argument is the input `MXTensors` which stores all data and info of input ndarrays. The 3rd argument is the output `MXTensors`. The 4th argument is the `OpResource` object for memory allocation and other utilities. The details of `OpResource` are covered in the below section. +Additionally, you can use a `dltensor` tensor structure stored in the `MXTensor` as a more standardized data structure for computing. * **backward**: This function is doing the backward gradient computation. It will be similar to the forward function. And you need to figure out the formula of the backward gradient computation. * **mutateInputs**: This function is for marking mutable inputs. It takes two arguments. The 1st argument is the attributes. The 2nd argument is a list of input indices that are mutable among all input tensors. It is useful when some inputs are auxiliary model parameters and might be altered during forward/backward computation. Remember, the index number of `input_indices` should not exceed the number of inputs. -### Writing Stateful Custom Operator: +### Writing Stateful Custom Operator Review comment: Writing A Stateful Custom Operator This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support
samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support URL: https://github.com/apache/incubator-mxnet/pull/17486#discussion_r375022979 ## File path: example/extensions/lib_custom_op/README.md ## @@ -56,87 +72,111 @@ For building a library containing your own custom operator, compose a C++ source - `forward` - Forward Computation (can be replace with `createOpState`, see below for details) Then compile it to `libmyop_lib.so` dynamic library using the following command: + ```bash g++ -shared -fPIC -std=c++11 myop_lib.cc -o libmyop_lib.so -I ../../../include/mxnet ``` +If you don't want to download MXNet source and choose only using `lib_api.h` header, you can copy the header over to the same folder of `myop_lib.cc` and run: + +```bash +g++ -shared -fPIC -std=c++11 myop_lib.cc -o libmyop_lib.so +``` + Finally, you can write a Python script to load the library and run your custom operator: + ```python import mxnet as mx mx.library.load(‘libmyop_lib.so’) mx.nd.my_op(...) ``` -### Writing Regular Custom Operator: +### Writing A Regular Custom Operator -There are several essential building blocks for making a (stateless) custom operator: +There are several essential building blocks for making a custom operator: * [initialize](./gemm_lib.cc#L227): * This function is the library initialization function necessary for any dynamic libraries. It checks if you are using a compatible version of MXNet. Note that this `version` parameter is passed from MXNet when library is loaded. -MXReturnValue initialize(int version) +```c++ +MXReturnValue initialize(int version) +``` * [parseAttrs](./gemm_lib.cc#L118): * This function specifies number of input and output tensors for the custom operator; also this is where a custom operator can validate the attributes (ie. options) specified by the user. -MXReturnValue parseAttrs( -std::map attrs, -int* num_in, -int* num_out) +```c++ +MXReturnValue parseAttrs( +std::map attrs, +int* num_in, +int* num_out) +``` * [inferType](./gemm_lib.cc#L124): * This function specifies how the custom operator infers output data types using input data types. -MXReturnValue inferType( -std::map attrs, -std::vector &intypes, -std::vector &outtypes) +```c++ +MXReturnValue inferType( +std::map attrs, +std::vector &intypes, +std::vector &outtypes) +``` * [inferShape](./gemm_lib.cc#L143): * This function specifies how the custom operator infers output tensor shape using input shape. -MXReturnValue inferShape( -std::map attrs, -std::vector> &inshapes, -std::vector> &outshapes) +```c++ +MXReturnValue inferShape( +std::map attrs, +std::vector> &inshapes, +std::vector> &outshapes) +``` * [forward](./gemm_lib.cc#L56): * This function specifies the computation of the forward pass of the operator. -MXReturnValue forward( -std::map attrs, -std::vector inputs, -std::vector outputs, -OpResource res) +```c++ +MXReturnValue forward( +std::map attrs, +std::vector inputs, +std::vector outputs, +OpResource res) +``` * [REGISTER_OP(my_op_name)](./gemm_lib.cc#L169): -* This macro registers the custom operator and its properties to MXNet NDArray and Symbol APIs by its name. - -REGISTER_OP(my_op_name) -.setForward(forward) -.setParseAttrs(parseAttrs) -.setInferType(inferType) -.setInferShape(inferShape); +* This macro registers the custom operator and its properties to MXNet NDArray and Symbol APIs by its name. Note that for operator running on CPU, you need pass the name of the context `"cpu"` when registering forward or backward function. +```c++ +REGISTER_OP(my_op_name) +.setForward(forward, "cpu") +.setBackward(backward, "cpu") Review comment: remove backward This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support
samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support URL: https://github.com/apache/incubator-mxnet/pull/17486#discussion_r375022066 ## File path: example/extensions/lib_custom_op/README.md ## @@ -56,87 +72,111 @@ For building a library containing your own custom operator, compose a C++ source - `forward` - Forward Computation (can be replace with `createOpState`, see below for details) Then compile it to `libmyop_lib.so` dynamic library using the following command: + ```bash g++ -shared -fPIC -std=c++11 myop_lib.cc -o libmyop_lib.so -I ../../../include/mxnet ``` +If you don't want to download MXNet source and choose only using `lib_api.h` header, you can copy the header over to the same folder of `myop_lib.cc` and run: + +```bash +g++ -shared -fPIC -std=c++11 myop_lib.cc -o libmyop_lib.so +``` + Finally, you can write a Python script to load the library and run your custom operator: + ```python import mxnet as mx mx.library.load(‘libmyop_lib.so’) mx.nd.my_op(...) ``` -### Writing Regular Custom Operator: +### Writing A Regular Custom Operator -There are several essential building blocks for making a (stateless) custom operator: +There are several essential building blocks for making a custom operator: * [initialize](./gemm_lib.cc#L227): * This function is the library initialization function necessary for any dynamic libraries. It checks if you are using a compatible version of MXNet. Note that this `version` parameter is passed from MXNet when library is loaded. -MXReturnValue initialize(int version) +```c++ +MXReturnValue initialize(int version) +``` * [parseAttrs](./gemm_lib.cc#L118): * This function specifies number of input and output tensors for the custom operator; also this is where a custom operator can validate the attributes (ie. options) specified by the user. -MXReturnValue parseAttrs( -std::map attrs, -int* num_in, -int* num_out) +```c++ +MXReturnValue parseAttrs( +std::map attrs, +int* num_in, +int* num_out) +``` * [inferType](./gemm_lib.cc#L124): * This function specifies how the custom operator infers output data types using input data types. -MXReturnValue inferType( -std::map attrs, -std::vector &intypes, -std::vector &outtypes) +```c++ +MXReturnValue inferType( +std::map attrs, +std::vector &intypes, +std::vector &outtypes) +``` * [inferShape](./gemm_lib.cc#L143): * This function specifies how the custom operator infers output tensor shape using input shape. -MXReturnValue inferShape( -std::map attrs, -std::vector> &inshapes, -std::vector> &outshapes) +```c++ +MXReturnValue inferShape( +std::map attrs, +std::vector> &inshapes, +std::vector> &outshapes) +``` * [forward](./gemm_lib.cc#L56): * This function specifies the computation of the forward pass of the operator. -MXReturnValue forward( -std::map attrs, -std::vector inputs, -std::vector outputs, -OpResource res) +```c++ +MXReturnValue forward( +std::map attrs, +std::vector inputs, +std::vector outputs, +OpResource res) +``` * [REGISTER_OP(my_op_name)](./gemm_lib.cc#L169): -* This macro registers the custom operator and its properties to MXNet NDArray and Symbol APIs by its name. - -REGISTER_OP(my_op_name) -.setForward(forward) -.setParseAttrs(parseAttrs) -.setInferType(inferType) -.setInferShape(inferShape); +* This macro registers the custom operator and its properties to MXNet NDArray and Symbol APIs by its name. Note that for operator running on CPU, you need pass the name of the context `"cpu"` when registering forward or backward function. Review comment: This macro registers the custom operator with MXNet. You can register additional functions with the operator too. Note that you register functions for each context for Forward and Backward, here we show an example for CPU. These are the minimum required functions, but you can specify more as needed. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support
samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support URL: https://github.com/apache/incubator-mxnet/pull/17486#discussion_r375022531 ## File path: example/extensions/lib_custom_op/README.md ## @@ -56,87 +72,111 @@ For building a library containing your own custom operator, compose a C++ source - `forward` - Forward Computation (can be replace with `createOpState`, see below for details) Then compile it to `libmyop_lib.so` dynamic library using the following command: + ```bash g++ -shared -fPIC -std=c++11 myop_lib.cc -o libmyop_lib.so -I ../../../include/mxnet ``` +If you don't want to download MXNet source and choose only using `lib_api.h` header, you can copy the header over to the same folder of `myop_lib.cc` and run: + +```bash +g++ -shared -fPIC -std=c++11 myop_lib.cc -o libmyop_lib.so +``` + Finally, you can write a Python script to load the library and run your custom operator: + ```python import mxnet as mx mx.library.load(‘libmyop_lib.so’) mx.nd.my_op(...) ``` -### Writing Regular Custom Operator: +### Writing A Regular Custom Operator -There are several essential building blocks for making a (stateless) custom operator: +There are several essential building blocks for making a custom operator: * [initialize](./gemm_lib.cc#L227): * This function is the library initialization function necessary for any dynamic libraries. It checks if you are using a compatible version of MXNet. Note that this `version` parameter is passed from MXNet when library is loaded. -MXReturnValue initialize(int version) +```c++ +MXReturnValue initialize(int version) +``` * [parseAttrs](./gemm_lib.cc#L118): * This function specifies number of input and output tensors for the custom operator; also this is where a custom operator can validate the attributes (ie. options) specified by the user. -MXReturnValue parseAttrs( -std::map attrs, -int* num_in, -int* num_out) +```c++ +MXReturnValue parseAttrs( +std::map attrs, +int* num_in, +int* num_out) +``` * [inferType](./gemm_lib.cc#L124): * This function specifies how the custom operator infers output data types using input data types. -MXReturnValue inferType( -std::map attrs, -std::vector &intypes, -std::vector &outtypes) +```c++ +MXReturnValue inferType( +std::map attrs, +std::vector &intypes, +std::vector &outtypes) +``` * [inferShape](./gemm_lib.cc#L143): * This function specifies how the custom operator infers output tensor shape using input shape. -MXReturnValue inferShape( -std::map attrs, -std::vector> &inshapes, -std::vector> &outshapes) +```c++ +MXReturnValue inferShape( +std::map attrs, +std::vector> &inshapes, +std::vector> &outshapes) +``` * [forward](./gemm_lib.cc#L56): * This function specifies the computation of the forward pass of the operator. -MXReturnValue forward( -std::map attrs, -std::vector inputs, -std::vector outputs, -OpResource res) +```c++ +MXReturnValue forward( +std::map attrs, +std::vector inputs, +std::vector outputs, +OpResource res) +``` * [REGISTER_OP(my_op_name)](./gemm_lib.cc#L169): -* This macro registers the custom operator and its properties to MXNet NDArray and Symbol APIs by its name. - -REGISTER_OP(my_op_name) -.setForward(forward) -.setParseAttrs(parseAttrs) -.setInferType(inferType) -.setInferShape(inferShape); +* This macro registers the custom operator and its properties to MXNet NDArray and Symbol APIs by its name. Note that for operator running on CPU, you need pass the name of the context `"cpu"` when registering forward or backward function. +```c++ +REGISTER_OP(my_op_name) +.setForward(forward, "cpu") +.setBackward(backward, "cpu") +.setParseAttrs(parseAttrs) +.setInferType(inferType) +.setInferShape(inferShape); +``` Also there are some optional functions you can specify: * [backward](./gemm_lib.cc#L90) - Backward gradient function: * This function specifies the computation of the backward pass of the operator. -MXReturnValue backward( -std::map attrs, -std::vector inputs, -std::vector outputs, -OpResource res) +```c++ +MXReturnValue backward( +std::map attrs, +std::vector inputs, +std::vector outputs, +OpResource res) +``` * [mutateInputs](./gemm_lib.cc#L214) - Specify mutable input: * This function allows you to mark some inputs to be mutable inputs.
[GitHub] [incubator-mxnet] samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support
samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support URL: https://github.com/apache/incubator-mxnet/pull/17486#discussion_r375022474 ## File path: example/extensions/lib_custom_op/README.md ## @@ -56,87 +72,111 @@ For building a library containing your own custom operator, compose a C++ source - `forward` - Forward Computation (can be replace with `createOpState`, see below for details) Then compile it to `libmyop_lib.so` dynamic library using the following command: + ```bash g++ -shared -fPIC -std=c++11 myop_lib.cc -o libmyop_lib.so -I ../../../include/mxnet ``` +If you don't want to download MXNet source and choose only using `lib_api.h` header, you can copy the header over to the same folder of `myop_lib.cc` and run: + +```bash +g++ -shared -fPIC -std=c++11 myop_lib.cc -o libmyop_lib.so +``` + Finally, you can write a Python script to load the library and run your custom operator: + ```python import mxnet as mx mx.library.load(‘libmyop_lib.so’) mx.nd.my_op(...) ``` -### Writing Regular Custom Operator: +### Writing A Regular Custom Operator -There are several essential building blocks for making a (stateless) custom operator: +There are several essential building blocks for making a custom operator: * [initialize](./gemm_lib.cc#L227): * This function is the library initialization function necessary for any dynamic libraries. It checks if you are using a compatible version of MXNet. Note that this `version` parameter is passed from MXNet when library is loaded. -MXReturnValue initialize(int version) +```c++ +MXReturnValue initialize(int version) +``` * [parseAttrs](./gemm_lib.cc#L118): * This function specifies number of input and output tensors for the custom operator; also this is where a custom operator can validate the attributes (ie. options) specified by the user. -MXReturnValue parseAttrs( -std::map attrs, -int* num_in, -int* num_out) +```c++ +MXReturnValue parseAttrs( +std::map attrs, +int* num_in, +int* num_out) +``` * [inferType](./gemm_lib.cc#L124): * This function specifies how the custom operator infers output data types using input data types. -MXReturnValue inferType( -std::map attrs, -std::vector &intypes, -std::vector &outtypes) +```c++ +MXReturnValue inferType( +std::map attrs, +std::vector &intypes, +std::vector &outtypes) +``` * [inferShape](./gemm_lib.cc#L143): * This function specifies how the custom operator infers output tensor shape using input shape. -MXReturnValue inferShape( -std::map attrs, -std::vector> &inshapes, -std::vector> &outshapes) +```c++ +MXReturnValue inferShape( +std::map attrs, +std::vector> &inshapes, +std::vector> &outshapes) +``` * [forward](./gemm_lib.cc#L56): * This function specifies the computation of the forward pass of the operator. -MXReturnValue forward( -std::map attrs, -std::vector inputs, -std::vector outputs, -OpResource res) +```c++ +MXReturnValue forward( +std::map attrs, +std::vector inputs, +std::vector outputs, +OpResource res) +``` * [REGISTER_OP(my_op_name)](./gemm_lib.cc#L169): -* This macro registers the custom operator and its properties to MXNet NDArray and Symbol APIs by its name. - -REGISTER_OP(my_op_name) -.setForward(forward) -.setParseAttrs(parseAttrs) -.setInferType(inferType) -.setInferShape(inferShape); +* This macro registers the custom operator and its properties to MXNet NDArray and Symbol APIs by its name. Note that for operator running on CPU, you need pass the name of the context `"cpu"` when registering forward or backward function. Review comment: lets move this to the end This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support
samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support URL: https://github.com/apache/incubator-mxnet/pull/17486#discussion_r375022066 ## File path: example/extensions/lib_custom_op/README.md ## @@ -56,87 +72,111 @@ For building a library containing your own custom operator, compose a C++ source - `forward` - Forward Computation (can be replace with `createOpState`, see below for details) Then compile it to `libmyop_lib.so` dynamic library using the following command: + ```bash g++ -shared -fPIC -std=c++11 myop_lib.cc -o libmyop_lib.so -I ../../../include/mxnet ``` +If you don't want to download MXNet source and choose only using `lib_api.h` header, you can copy the header over to the same folder of `myop_lib.cc` and run: + +```bash +g++ -shared -fPIC -std=c++11 myop_lib.cc -o libmyop_lib.so +``` + Finally, you can write a Python script to load the library and run your custom operator: + ```python import mxnet as mx mx.library.load(‘libmyop_lib.so’) mx.nd.my_op(...) ``` -### Writing Regular Custom Operator: +### Writing A Regular Custom Operator -There are several essential building blocks for making a (stateless) custom operator: +There are several essential building blocks for making a custom operator: * [initialize](./gemm_lib.cc#L227): * This function is the library initialization function necessary for any dynamic libraries. It checks if you are using a compatible version of MXNet. Note that this `version` parameter is passed from MXNet when library is loaded. -MXReturnValue initialize(int version) +```c++ +MXReturnValue initialize(int version) +``` * [parseAttrs](./gemm_lib.cc#L118): * This function specifies number of input and output tensors for the custom operator; also this is where a custom operator can validate the attributes (ie. options) specified by the user. -MXReturnValue parseAttrs( -std::map attrs, -int* num_in, -int* num_out) +```c++ +MXReturnValue parseAttrs( +std::map attrs, +int* num_in, +int* num_out) +``` * [inferType](./gemm_lib.cc#L124): * This function specifies how the custom operator infers output data types using input data types. -MXReturnValue inferType( -std::map attrs, -std::vector &intypes, -std::vector &outtypes) +```c++ +MXReturnValue inferType( +std::map attrs, +std::vector &intypes, +std::vector &outtypes) +``` * [inferShape](./gemm_lib.cc#L143): * This function specifies how the custom operator infers output tensor shape using input shape. -MXReturnValue inferShape( -std::map attrs, -std::vector> &inshapes, -std::vector> &outshapes) +```c++ +MXReturnValue inferShape( +std::map attrs, +std::vector> &inshapes, +std::vector> &outshapes) +``` * [forward](./gemm_lib.cc#L56): * This function specifies the computation of the forward pass of the operator. -MXReturnValue forward( -std::map attrs, -std::vector inputs, -std::vector outputs, -OpResource res) +```c++ +MXReturnValue forward( +std::map attrs, +std::vector inputs, +std::vector outputs, +OpResource res) +``` * [REGISTER_OP(my_op_name)](./gemm_lib.cc#L169): -* This macro registers the custom operator and its properties to MXNet NDArray and Symbol APIs by its name. - -REGISTER_OP(my_op_name) -.setForward(forward) -.setParseAttrs(parseAttrs) -.setInferType(inferType) -.setInferShape(inferShape); +* This macro registers the custom operator and its properties to MXNet NDArray and Symbol APIs by its name. Note that for operator running on CPU, you need pass the name of the context `"cpu"` when registering forward or backward function. Review comment: This macro registers the custom operator with MXNet. You can register additional functions with the operator too. Note that you register functions for each context for Forward and Backward, here we show an example for CPU. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support
samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support URL: https://github.com/apache/incubator-mxnet/pull/17486#discussion_r375020986 ## File path: example/extensions/lib_custom_op/README.md ## @@ -56,87 +72,111 @@ For building a library containing your own custom operator, compose a C++ source - `forward` - Forward Computation (can be replace with `createOpState`, see below for details) Then compile it to `libmyop_lib.so` dynamic library using the following command: + ```bash g++ -shared -fPIC -std=c++11 myop_lib.cc -o libmyop_lib.so -I ../../../include/mxnet ``` +If you don't want to download MXNet source and choose only using `lib_api.h` header, you can copy the header over to the same folder of `myop_lib.cc` and run: + +```bash +g++ -shared -fPIC -std=c++11 myop_lib.cc -o libmyop_lib.so +``` + Finally, you can write a Python script to load the library and run your custom operator: + ```python import mxnet as mx mx.library.load(‘libmyop_lib.so’) mx.nd.my_op(...) ``` -### Writing Regular Custom Operator: +### Writing A Regular Custom Operator -There are several essential building blocks for making a (stateless) custom operator: +There are several essential building blocks for making a custom operator: * [initialize](./gemm_lib.cc#L227): * This function is the library initialization function necessary for any dynamic libraries. It checks if you are using a compatible version of MXNet. Note that this `version` parameter is passed from MXNet when library is loaded. Review comment: The initialize function is called when MXNet first loads the library. MXNet passes its version to this function when called. This gives the library the ability to check which version of MXNet is being used. It also provides a place where library state can be initialized. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support
samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support URL: https://github.com/apache/incubator-mxnet/pull/17486#discussion_r375020986 ## File path: example/extensions/lib_custom_op/README.md ## @@ -56,87 +72,111 @@ For building a library containing your own custom operator, compose a C++ source - `forward` - Forward Computation (can be replace with `createOpState`, see below for details) Then compile it to `libmyop_lib.so` dynamic library using the following command: + ```bash g++ -shared -fPIC -std=c++11 myop_lib.cc -o libmyop_lib.so -I ../../../include/mxnet ``` +If you don't want to download MXNet source and choose only using `lib_api.h` header, you can copy the header over to the same folder of `myop_lib.cc` and run: + +```bash +g++ -shared -fPIC -std=c++11 myop_lib.cc -o libmyop_lib.so +``` + Finally, you can write a Python script to load the library and run your custom operator: + ```python import mxnet as mx mx.library.load(‘libmyop_lib.so’) mx.nd.my_op(...) ``` -### Writing Regular Custom Operator: +### Writing A Regular Custom Operator -There are several essential building blocks for making a (stateless) custom operator: +There are several essential building blocks for making a custom operator: * [initialize](./gemm_lib.cc#L227): * This function is the library initialization function necessary for any dynamic libraries. It checks if you are using a compatible version of MXNet. Note that this `version` parameter is passed from MXNet when library is loaded. Review comment: This function is called when MXNet first loads the library. MXNet passes its version to this function when called. This gives the library the ability to check which version of MXNet is being used. It also provides a place where library state can be initialized. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support
samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support URL: https://github.com/apache/incubator-mxnet/pull/17486#discussion_r375020328 ## File path: example/extensions/lib_custom_op/README.md ## @@ -56,87 +72,111 @@ For building a library containing your own custom operator, compose a C++ source - `forward` - Forward Computation (can be replace with `createOpState`, see below for details) Then compile it to `libmyop_lib.so` dynamic library using the following command: + ```bash g++ -shared -fPIC -std=c++11 myop_lib.cc -o libmyop_lib.so -I ../../../include/mxnet ``` +If you don't want to download MXNet source and choose only using `lib_api.h` header, you can copy the header over to the same folder of `myop_lib.cc` and run: + +```bash +g++ -shared -fPIC -std=c++11 myop_lib.cc -o libmyop_lib.so +``` + Finally, you can write a Python script to load the library and run your custom operator: Review comment: Finally, you can write some code to load the library and run your custom operator in any language binding. Heres an example in Python (but C Predict API and C++ APIs work too): This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support
samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support URL: https://github.com/apache/incubator-mxnet/pull/17486#discussion_r375020045 ## File path: example/extensions/lib_custom_op/README.md ## @@ -56,87 +72,111 @@ For building a library containing your own custom operator, compose a C++ source - `forward` - Forward Computation (can be replace with `createOpState`, see below for details) Then compile it to `libmyop_lib.so` dynamic library using the following command: + ```bash g++ -shared -fPIC -std=c++11 myop_lib.cc -o libmyop_lib.so -I ../../../include/mxnet ``` +If you don't want to download MXNet source and choose only using `lib_api.h` header, you can copy the header over to the same folder of `myop_lib.cc` and run: Review comment: "choose only using" --> "choose to only use" This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support
samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support URL: https://github.com/apache/incubator-mxnet/pull/17486#discussion_r375019792 ## File path: example/extensions/lib_custom_op/README.md ## @@ -56,87 +72,111 @@ For building a library containing your own custom operator, compose a C++ source - `forward` - Forward Computation (can be replace with `createOpState`, see below for details) Review comment: "can be replace" --> "can be replaced" This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support
samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support URL: https://github.com/apache/incubator-mxnet/pull/17486#discussion_r375019642 ## File path: example/extensions/lib_custom_op/README.md ## @@ -28,26 +28,42 @@ Custom operators (CustomOp) enable users to write new operators without compilin ### Have MXNet Ready -First you should install MXNet either from compiling from source code or download from nightly build. It doesn’t matter if the build comes with CUDA or MKLDNN. The custom operator doesn’t interact with the execution of other native MXNet operators. +Custom Operator support was merged (#15921, #17270) and is not available in versions of MXNet prior to v1.7.0. To access the feature now, please install MXNet by compiling from source using master or using the previously mentioned commits, downloading one of the nightly builds, or from a release of MXNet 1.7.0+. For running the following example, it doesn’t matter if it is a CUDA, MKLDNN or plain MXNet build; the custom operator doesn’t interact with the execution of other native MXNet operators. Note that if you want to run GPU examples and write your custom operators running on GPU, you still need an MXNet CUDA build. -### Run An Example: +### Run An Example -You can start getting familiar with custom operators by running some examples provided in the **example/extensions/lib_custom_op** directory. Start with a common linear algebra operator like `gemm` (Generalized Matrix Multiplication). Go to `lib_custom_op` directory and follow these steps: +You can start getting familiar with custom operators by running some examples provided in the `example/extensions/lib_custom_op` directory. Start with a common linear algebra operator like `gemm` (Generalized Matrix Multiplication). Go to `lib_custom_op` directory and follow these steps: 1. Run `make gemm_lib`. The Makefile will generate a dynamic library **libgemm_lib.so** compiled from `gemm_lib.cc`. This is the library you are going to load that contains everything for the custom gemm operator. -2. Run `python test_gemm.py`. It’ll first load the above .so library, find the operators, register them in the MXNet backend, print "Found x operators", then invoke the operator like a regular MXNet operator and output the result. +2. Run `python test_gemm.py`. It’ll first load the library compiled from step 1, find the operators, register them in the MXNet backend, then invoke the operator like a regular MXNet operator and output the result. -### Basic Files For Gemm Library: +``` +[19:22:02] ../src/c_api/c_api.cc:286: Found 2 operators in library +[19:22:02] ../src/c_api/c_api.cc:350: Op[0] my_gemm +[19:22:02] ../src/c_api/c_api.cc:350: Op[1] state_gemm +[19:22:02] ../src/c_api/c_api.cc:785: Found 0 partitioners in library +start ndarray compute- +[[ 50.] + [122.]] + +... +``` + +Note that you can safely ignore the `Found 0 partitioners` info as it is not related to the custom operator. + +### Basic Files For A GeMM Library * **lib_custom_op/gemm_lib.cc**: This file has a source code implementation of all required components of a custom operator, as well as the registration of the custom operator. -* **lib_custom_op/Makefile**: Compile source code to a dynamic shared library, with a header file `include/mxnet/lib_api.h` from MXNet source code. Currently the custom operator is compatible with C++11 onwards. +* **lib_custom_op/Makefile**: Compile `gemm_lib.cc` to a dynamic shared library named `libgemm_lib.so`, with a include path of the header file `include/mxnet/lib_api.h` from MXNet source code. Currently the custom operator is compatible with C++11 onwards. * **lib_custom_op/test_gemm.py**: This file calls `mx.library.load(‘libgemm_lib.so’)` to load the library containing the custom operator, invokes the operator using both NDArray and Symbol APIs, and prints outputs of the forward and backward passes. The outputs should be the same as the regular MXNet `gemm` operator. -## Writing Custom Operator Library: +* **include/mxnet/lib_api.h**: This file from MXNet source code is the one-stop header to include all necessary data types and function prototypes for writing a custom operator library. You can either specify the include path in `Makefile`, or copy the header file over to `example/extensions/lib_custom_op` folder for `gemm_lib.cc` to include. Note that apart from this header, the custom operator library is independent of MXNet source. -For building a library containing your own custom operator, compose a C++ source file like `myop_lib.cc`, include `lib_api.h` header file, and write your custom operator implementation with these essential functions: +## Writing A Custom CPU Operator Library + +For building your own library containing custom CPU operator, compose a C++ source file like `myop_lib.cc`, include `lib_api.h` header file, and write y
[GitHub] [incubator-mxnet] samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support
samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support URL: https://github.com/apache/incubator-mxnet/pull/17486#discussion_r375018587 ## File path: example/extensions/lib_custom_op/README.md ## @@ -28,26 +28,42 @@ Custom operators (CustomOp) enable users to write new operators without compilin ### Have MXNet Ready -First you should install MXNet either from compiling from source code or download from nightly build. It doesn’t matter if the build comes with CUDA or MKLDNN. The custom operator doesn’t interact with the execution of other native MXNet operators. +Custom Operator support was merged (#15921, #17270) and is not available in versions of MXNet prior to v1.7.0. To access the feature now, please install MXNet by compiling from source using master or using the previously mentioned commits, downloading one of the nightly builds, or from a release of MXNet 1.7.0+. For running the following example, it doesn’t matter if it is a CUDA, MKLDNN or plain MXNet build; the custom operator doesn’t interact with the execution of other native MXNet operators. Note that if you want to run GPU examples and write your custom operators running on GPU, you still need an MXNet CUDA build. -### Run An Example: +### Run An Example -You can start getting familiar with custom operators by running some examples provided in the **example/extensions/lib_custom_op** directory. Start with a common linear algebra operator like `gemm` (Generalized Matrix Multiplication). Go to `lib_custom_op` directory and follow these steps: +You can start getting familiar with custom operators by running some examples provided in the `example/extensions/lib_custom_op` directory. Start with a common linear algebra operator like `gemm` (Generalized Matrix Multiplication). Go to `lib_custom_op` directory and follow these steps: 1. Run `make gemm_lib`. The Makefile will generate a dynamic library **libgemm_lib.so** compiled from `gemm_lib.cc`. This is the library you are going to load that contains everything for the custom gemm operator. -2. Run `python test_gemm.py`. It’ll first load the above .so library, find the operators, register them in the MXNet backend, print "Found x operators", then invoke the operator like a regular MXNet operator and output the result. +2. Run `python test_gemm.py`. It’ll first load the library compiled from step 1, find the operators, register them in the MXNet backend, then invoke the operator like a regular MXNet operator and output the result. -### Basic Files For Gemm Library: +``` +[19:22:02] ../src/c_api/c_api.cc:286: Found 2 operators in library +[19:22:02] ../src/c_api/c_api.cc:350: Op[0] my_gemm +[19:22:02] ../src/c_api/c_api.cc:350: Op[1] state_gemm +[19:22:02] ../src/c_api/c_api.cc:785: Found 0 partitioners in library +start ndarray compute- +[[ 50.] + [122.]] + +... +``` + +Note that you can safely ignore the `Found 0 partitioners` info as it is not related to the custom operator. + +### Basic Files For A GeMM Library * **lib_custom_op/gemm_lib.cc**: This file has a source code implementation of all required components of a custom operator, as well as the registration of the custom operator. -* **lib_custom_op/Makefile**: Compile source code to a dynamic shared library, with a header file `include/mxnet/lib_api.h` from MXNet source code. Currently the custom operator is compatible with C++11 onwards. +* **lib_custom_op/Makefile**: Compile `gemm_lib.cc` to a dynamic shared library named `libgemm_lib.so`, with a include path of the header file `include/mxnet/lib_api.h` from MXNet source code. Currently the custom operator is compatible with C++11 onwards. * **lib_custom_op/test_gemm.py**: This file calls `mx.library.load(‘libgemm_lib.so’)` to load the library containing the custom operator, invokes the operator using both NDArray and Symbol APIs, and prints outputs of the forward and backward passes. The outputs should be the same as the regular MXNet `gemm` operator. -## Writing Custom Operator Library: +* **include/mxnet/lib_api.h**: This file from MXNet source code is the one-stop header to include all necessary data types and function prototypes for writing a custom operator library. You can either specify the include path in `Makefile`, or copy the header file over to `example/extensions/lib_custom_op` folder for `gemm_lib.cc` to include. Note that apart from this header, the custom operator library is independent of MXNet source. Review comment: "is the one-stop header to include all necessary" --> "is the single header file needed to include all necessary" "include path in `Makefile`" --> "include path in the `Makefile`" "`example/extensions/lib_custom_op` folder for `gemm_lib.cc` to include. " --> "`example/extensions/lib_custom_op` folder. " This is an auto
[GitHub] [incubator-mxnet] samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support
samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support URL: https://github.com/apache/incubator-mxnet/pull/17486#discussion_r375017581 ## File path: example/extensions/lib_custom_op/README.md ## @@ -28,26 +28,42 @@ Custom operators (CustomOp) enable users to write new operators without compilin ### Have MXNet Ready -First you should install MXNet either from compiling from source code or download from nightly build. It doesn’t matter if the build comes with CUDA or MKLDNN. The custom operator doesn’t interact with the execution of other native MXNet operators. +Custom Operator support was merged (#15921, #17270) and is not available in versions of MXNet prior to v1.7.0. To access the feature now, please install MXNet by compiling from source using master or using the previously mentioned commits, downloading one of the nightly builds, or from a release of MXNet 1.7.0+. For running the following example, it doesn’t matter if it is a CUDA, MKLDNN or plain MXNet build; the custom operator doesn’t interact with the execution of other native MXNet operators. Note that if you want to run GPU examples and write your custom operators running on GPU, you still need an MXNet CUDA build. -### Run An Example: +### Run An Example -You can start getting familiar with custom operators by running some examples provided in the **example/extensions/lib_custom_op** directory. Start with a common linear algebra operator like `gemm` (Generalized Matrix Multiplication). Go to `lib_custom_op` directory and follow these steps: +You can start getting familiar with custom operators by running some examples provided in the `example/extensions/lib_custom_op` directory. Start with a common linear algebra operator like `gemm` (Generalized Matrix Multiplication). Go to `lib_custom_op` directory and follow these steps: 1. Run `make gemm_lib`. The Makefile will generate a dynamic library **libgemm_lib.so** compiled from `gemm_lib.cc`. This is the library you are going to load that contains everything for the custom gemm operator. -2. Run `python test_gemm.py`. It’ll first load the above .so library, find the operators, register them in the MXNet backend, print "Found x operators", then invoke the operator like a regular MXNet operator and output the result. +2. Run `python test_gemm.py`. It’ll first load the library compiled from step 1, find the operators, register them in the MXNet backend, then invoke the operator like a regular MXNet operator and output the result. -### Basic Files For Gemm Library: +``` +[19:22:02] ../src/c_api/c_api.cc:286: Found 2 operators in library +[19:22:02] ../src/c_api/c_api.cc:350: Op[0] my_gemm +[19:22:02] ../src/c_api/c_api.cc:350: Op[1] state_gemm +[19:22:02] ../src/c_api/c_api.cc:785: Found 0 partitioners in library +start ndarray compute- +[[ 50.] + [122.]] + +... +``` + +Note that you can safely ignore the `Found 0 partitioners` info as it is not related to the custom operator. + +### Basic Files For A GeMM Library * **lib_custom_op/gemm_lib.cc**: This file has a source code implementation of all required components of a custom operator, as well as the registration of the custom operator. -* **lib_custom_op/Makefile**: Compile source code to a dynamic shared library, with a header file `include/mxnet/lib_api.h` from MXNet source code. Currently the custom operator is compatible with C++11 onwards. +* **lib_custom_op/Makefile**: Compile `gemm_lib.cc` to a dynamic shared library named `libgemm_lib.so`, with a include path of the header file `include/mxnet/lib_api.h` from MXNet source code. Currently the custom operator is compatible with C++11 onwards. Review comment: This file compiles `gemm_lib.cc` to a dynamic shared library named `libgemm_lib.so`. It includes the header file `include/mxnet/lib_api.h` from MXNet source code. Currently the custom operator APIs require C++11 onwards. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] leezu opened a new pull request #17521: cmake: don't build PTX and 3.5 arch if cuda arch detection fails
leezu opened a new pull request #17521: cmake: don't build PTX and 3.5 arch if cuda arch detection fails URL: https://github.com/apache/incubator-mxnet/pull/17521 ## Description ## Currently, if `USE_CUDA=ON` but architecture detection fails due to building on a machine without GPU, we will build for `3.0;3.5;5.0;5.2;6.0;6.1;7.0;7.0+PTX;7.5;7.5+PTX`. Thereby we create too large object files, triggering https://github.com/apache/incubator-mxnet/issues/16852. Thus, this PR introduces patched `select_compute_arch.cmake`, such that the fallback arches are `3.0;5.0;5.2;6.0;6.1;7.0;7.5`, ie. dropping PTX and 3.5 so that #16852 is not triggered. We don't need 3.5, because code compiled for 3.0 also runs on 3.5 hardware and 3.5 hardware is 7 years old. If someone really cares about performance on 3.5, they can still manually set `MXNET_CUDA_ARCH=3.5`. Upstream bug https://gitlab.kitware.com/cmake/cmake/issues/20275 ### Changes ### - [X] cmake: don't build PTX and 3.5 arch if cuda arch detection fails This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] larroy removed a comment on issue #17043: Segmentation fault: 11
larroy removed a comment on issue #17043: Segmentation fault: 11 URL: https://github.com/apache/incubator-mxnet/issues/17043#issuecomment-582195501 I would suggest to run fit with hyperparameter_tune=False I don't observe the crash with this, as it doesn't trigger multiprocessing. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] leezu edited a comment on issue #17043: Segmentation fault: 11
leezu edited a comment on issue #17043: Segmentation fault: 11 URL: https://github.com/apache/incubator-mxnet/issues/17043#issuecomment-582195991 For now we can't recommend compiling with jemalloc anyways. See the reasoning at https://github.com/apache/incubator-mxnet/pull/17324 > thanks, should we add a check of sorts to avoid this happening? Do you have more info about this incompatibility? No. It's just an empirical observation. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] leezu edited a comment on issue #17043: Segmentation fault: 11
leezu edited a comment on issue #17043: Segmentation fault: 11 URL: https://github.com/apache/incubator-mxnet/issues/17043#issuecomment-582195991 For now we can't recommend compiling with jemalloc anyways. See the reasoning at https://github.com/apache/incubator-mxnet/pull/17324 > Do you have more info about this incompatibility? No. It's just an empirical observation. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] leezu commented on issue #17043: Segmentation fault: 11
leezu commented on issue #17043: Segmentation fault: 11 URL: https://github.com/apache/incubator-mxnet/issues/17043#issuecomment-582195991 For now we can't recommend compiling with jemalloc anyways. See the reasoning at https://github.com/apache/incubator-mxnet/pull/17324 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] larroy commented on issue #17043: Segmentation fault: 11
larroy commented on issue #17043: Segmentation fault: 11 URL: https://github.com/apache/incubator-mxnet/issues/17043#issuecomment-582195501 I would suggest to run fit with hyperparameter_tune=False I don't observe the crash with this, as it doesn't trigger multiprocessing. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] larroy edited a comment on issue #17043: Segmentation fault: 11
larroy edited a comment on issue #17043: Segmentation fault: 11 URL: https://github.com/apache/incubator-mxnet/issues/17043#issuecomment-582194853 thanks, should we add a check of sorts to avoid this happening? Do you have more info about this incompatibility? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] larroy commented on issue #17043: Segmentation fault: 11
larroy commented on issue #17043: Segmentation fault: 11 URL: https://github.com/apache/incubator-mxnet/issues/17043#issuecomment-582194853 thanks, should we add a check of sorts to avoid this happening? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support
samskalicky commented on a change in pull request #17486: Update CustomOp doc with changes for GPU support URL: https://github.com/apache/incubator-mxnet/pull/17486#discussion_r375011251 ## File path: example/extensions/lib_custom_op/README.md ## @@ -28,26 +28,42 @@ Custom operators (CustomOp) enable users to write new operators without compilin ### Have MXNet Ready -First you should install MXNet either from compiling from source code or download from nightly build. It doesn’t matter if the build comes with CUDA or MKLDNN. The custom operator doesn’t interact with the execution of other native MXNet operators. +Custom Operator support was merged (#15921, #17270) and is not available in versions of MXNet prior to v1.7.0. To access the feature now, please install MXNet by compiling from source using master or using the previously mentioned commits, downloading one of the nightly builds, or from a release of MXNet 1.7.0+. For running the following example, it doesn’t matter if it is a CUDA, MKLDNN or plain MXNet build; the custom operator doesn’t interact with the execution of other native MXNet operators. Note that if you want to run GPU examples and write your custom operators running on GPU, you still need an MXNet CUDA build. -### Run An Example: +### Run An Example -You can start getting familiar with custom operators by running some examples provided in the **example/extensions/lib_custom_op** directory. Start with a common linear algebra operator like `gemm` (Generalized Matrix Multiplication). Go to `lib_custom_op` directory and follow these steps: +You can start getting familiar with custom operators by running some examples provided in the `example/extensions/lib_custom_op` directory. Start with a common linear algebra operator like `gemm` (Generalized Matrix Multiplication). Go to `lib_custom_op` directory and follow these steps: 1. Run `make gemm_lib`. The Makefile will generate a dynamic library **libgemm_lib.so** compiled from `gemm_lib.cc`. This is the library you are going to load that contains everything for the custom gemm operator. -2. Run `python test_gemm.py`. It’ll first load the above .so library, find the operators, register them in the MXNet backend, print "Found x operators", then invoke the operator like a regular MXNet operator and output the result. +2. Run `python test_gemm.py`. It’ll first load the library compiled from step 1, find the operators, register them in the MXNet backend, then invoke the operator like a regular MXNet operator and output the result. Review comment: This is good. Lets add another sentence introducing the log that is coming next. I suggest: "Below is the output when running the `python test_gemm.py` command. Notice that it loaded 2 operators: `my_gemm` and `state_gemm`. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[incubator-mxnet-site] branch asf-site updated: Bump the publish timestamp.
This is an automated email from the ASF dual-hosted git repository. aaronmarkham pushed a commit to branch asf-site in repository https://gitbox.apache.org/repos/asf/incubator-mxnet-site.git The following commit(s) were added to refs/heads/asf-site by this push: new cdf6fa4 Bump the publish timestamp. cdf6fa4 is described below commit cdf6fa4ed358091076e46ab5f9e04e98e9894dd1 Author: mxnet-ci AuthorDate: Wed Feb 5 00:44:04 2020 + Bump the publish timestamp. --- date.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/date.txt b/date.txt new file mode 100644 index 000..c208607 --- /dev/null +++ b/date.txt @@ -0,0 +1 @@ +Wed Feb 5 00:44:04 UTC 2020
[GitHub] [incubator-mxnet] samskalicky commented on issue #17382: document of lib_custom_op support gpu without rebuilding mxnet
samskalicky commented on issue #17382: document of lib_custom_op support gpu without rebuilding mxnet URL: https://github.com/apache/incubator-mxnet/issues/17382#issuecomment-582186654 @a550461053 The GPU support for customOps is finally ready thanks to all the hard work from @rondogency !!! Yay! You can get a nightly build or build from source with the latest master to try out the functionality. @rondogency is also working on the documentation updates for GPU support in #17486 too, so you can review the latest there an leave comments if there is something we can clarify. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] rondogency commented on issue #17486: Update CustomOp doc with changes for GPU support
rondogency commented on issue #17486: Update CustomOp doc with changes for GPU support URL: https://github.com/apache/incubator-mxnet/pull/17486#issuecomment-582185417 @samskalicky the fix is in #17516 and you can review it now This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] mseth10 commented on issue #15969: Partitioning Gluon HybridBlocks
mseth10 commented on issue #15969: Partitioning Gluon HybridBlocks URL: https://github.com/apache/incubator-mxnet/pull/15969#issuecomment-582176973 @leezu your comments have been addressed. can you please review again? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] anirudh2290 edited a comment on issue #17520: Fix CMake CPP tests dependency issue
anirudh2290 edited a comment on issue #17520: Fix CMake CPP tests dependency issue URL: https://github.com/apache/incubator-mxnet/pull/17520#issuecomment-582176631 @leezu I didn't dig into that, I am guessing its probably undefined behavior and somehow the CI always built the cpp package before the tests. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] anirudh2290 commented on issue #17520: Fix CMake CPP tests dependency issue
anirudh2290 commented on issue #17520: Fix CMake CPP tests dependency issue URL: https://github.com/apache/incubator-mxnet/pull/17520#issuecomment-582176631 @leezu I don't dig into that, I am guessing its probably undefined behavior and somehow the CI always built the cpp package before the tests. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] leezu commented on issue #17520: Fix CMake CPP tests dependency issue
leezu commented on issue #17520: Fix CMake CPP tests dependency issue URL: https://github.com/apache/incubator-mxnet/pull/17520#issuecomment-582176139 Thanks @anirudh2290. Do you know why did the CI not fail before? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] anirudh2290 opened a new pull request #17520: Fix CMake CPP tests dependency issue
anirudh2290 opened a new pull request #17520: Fix CMake CPP tests dependency issue URL: https://github.com/apache/incubator-mxnet/pull/17520 ## Description ## Fix one of the issues mentioned in: https://github.com/apache/incubator-mxnet/issues/17514. add_subdirectory ordering by itself is not enough to run cpp builds before tests. need to add add_dependency on the targets. @leezu ## Checklist ## ### Essentials ### Please feel free to remove inapplicable items for your PR. - [ ] The PR title starts with [MXNET-$JIRA_ID], where $JIRA_ID refers to the relevant [JIRA issue](https://issues.apache.org/jira/projects/MXNET/issues) created (except PRs with tiny changes) - [ ] Changes are complete (i.e. I finished coding on this PR) - [ ] All changes have test coverage: - Unit tests are added for small changes to verify correctness (e.g. adding a new operator) - Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore) - Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL) - [ ] Code is well-documented: - For user-facing API changes, API doc string has been updated. - For new C++ functions in header files, their functionalities and arguments are documented. - For new examples, README.md is added to explain the what the example does, the source of the dataset, expected performance on test set and reference to the original paper if applicable - Check the API doc at https://mxnet-ci-doc.s3-accelerate.dualstack.amazonaws.com/PR-$PR_ID/$BUILD_ID/index.html - [ ] To the best of my knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change ### Changes ### - [ ] Feature1, tests, (and when applicable, API doc) - [ ] Feature2, tests, (and when applicable, API doc) ## Comments ## - If this change is a backward incompatible change, why must this change be made. - Interesting edge cases to note here This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] yzhliu opened a new pull request #17519: [tvmop] use size_var for placeholder & compute to reduce size of codegen
yzhliu opened a new pull request #17519: [tvmop] use size_var for placeholder & compute to reduce size of codegen URL: https://github.com/apache/incubator-mxnet/pull/17519 It's a follow up of https://github.com/apache/incubator-mxnet/pull/17438 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] connorgoggins commented on a change in pull request #17500: [OpPerf] Implement remaining nn_conv ops in opperf
connorgoggins commented on a change in pull request #17500: [OpPerf] Implement remaining nn_conv ops in opperf URL: https://github.com/apache/incubator-mxnet/pull/17500#discussion_r374989898 ## File path: CMakeLists.txt ## @@ -314,6 +314,10 @@ if(USE_MKLDNN) set(INSTALL_MKLDNN ON) endif() +if(USE_CPP_PACKAGE) Review comment: Fixed. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] djaym7 edited a comment on issue #14875: MXNet to ONNX export bug
djaym7 edited a comment on issue #14875: MXNet to ONNX export bug
URL:
https://github.com/apache/incubator-mxnet/issues/14875#issuecomment-582171608
> I met the same problem.
> And I tried the solution in
PR[#14942](https://github.com/apache/incubator-mxnet/pull/14942), found a new
bug.
>
> > File
"D:\WorkingSoftware\Anaconda3\lib\site-packages\mxnet\contrib\onnx\mx2onnx\export_model.py",
line 83, in export_model
> > verbose=verbose)
> > File
"D:\WorkingSoftware\Anaconda3\lib\site-packages\mxnet\contrib\onnx\mx2onnx\export_onnx.py",
line 253, in create_onnx_graph_proto
> > idx=idx
> > File
"D:\WorkingSoftware\Anaconda3\lib\site-packages\mxnet\contrib\onnx\mx2onnx\export_onnx.py",
line 90, in convert_layer
> > raise AttributeError("No conversion function registered for op type %s
yet." % op)
> > AttributeError: No conversion function registered for op type _arange
yet.
Had same error on Nov 5, 2019.. tried to build make the operator but didnt
work..
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [incubator-mxnet] djaym7 commented on issue #14875: MXNet to ONNX export bug
djaym7 commented on issue #14875: MXNet to ONNX export bug
URL:
https://github.com/apache/incubator-mxnet/issues/14875#issuecomment-582171608
> I met the same problem.
> And I tried the solution in
PR[#14942](https://github.com/apache/incubator-mxnet/pull/14942), found a new
bug.
>
> > File
"D:\WorkingSoftware\Anaconda3\lib\site-packages\mxnet\contrib\onnx\mx2onnx\export_model.py",
line 83, in export_model
> > verbose=verbose)
> > File
"D:\WorkingSoftware\Anaconda3\lib\site-packages\mxnet\contrib\onnx\mx2onnx\export_onnx.py",
line 253, in create_onnx_graph_proto
> > idx=idx
> > File
"D:\WorkingSoftware\Anaconda3\lib\site-packages\mxnet\contrib\onnx\mx2onnx\export_onnx.py",
line 90, in convert_layer
> > raise AttributeError("No conversion function registered for op type %s
yet." % op)
> > AttributeError: No conversion function registered for op type _arange
yet.
Had same error on Nov 5, 2019 lol
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [incubator-mxnet] djaym7 opened a new issue #17518: MaskRCNN can't export -- solution attached
djaym7 opened a new issue #17518: MaskRCNN can't export -- solution attached
URL: https://github.com/apache/incubator-mxnet/issues/17518
## Description
Parameters normalizedperclassboxcenterencoder5_means and
normalizedperclassboxcenterencoder5_stds are used in training but not in
inference. This causes AssertionError while exporting symbol.
### Error Message
AssertionError "assert name in aux_names"
## To Reproduce
import gluoncv as gcv
import mxnet as mx
net = gcv.model_zoo.mask_rcnn_resnet101_v1d_coco(pretrained=True)
net.hybridize(static_shape=True,static_alloc=True)
_=net(mx.nd.random.randn(1,3,608,608))
net.export('instance') #returns error
### Steps to reproduce
RUN the code
## What have you tried to solve it?
1. Save the parameters manually excluding the two mentioned in description.
2. Generalized function shown below
## Environment
mxnet 1.6+
Solution :
from mxnet.util import is_np_array
def export_net(model,path)
sym = net._cached_graph[1]
sym.save('%s-symbol.json'%path, remove_amp_cast=True)
arg_names = set(sym.list_arguments())
aux_names = set(sym.list_auxiliary_states())
arg_dict = {}
for name, param in net.collect_params().items():
if name[:-7] in 'normalizedperclassboxcenterencoder':
continue
if name in arg_names:
arg_dict['arg:%s'%name] = param._reduce()
else:
assert name in aux_names
arg_dict['aux:%s'%name] = param._reduce()
save_fn = _mx_npx.save if is_np_array() else mx.nd.save
save_fn('%s-%04d.params'%(path, 0), arg_dict)
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [incubator-mxnet] leezu commented on issue #11434: add ignore_reinit to initialize to skip warnings
leezu commented on issue #11434: add ignore_reinit to initialize to skip warnings URL: https://github.com/apache/incubator-mxnet/pull/11434#issuecomment-582164980 @RuRo @zhreshold Yes, there may be use-cases where the regex is not sufficient. I just wonder how common they are and if https://docs.python.org/3/library/warnings.html#temporarily-suppressing-warnings could sufficiently address them. In either way, we can merge this PR if you think the use-cases are sufficiently important to introduce a new argument. I wouldn't mind. Just wanted to point out the downsides and the current workaround. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] leezu commented on issue #17514: C++-Package examples broken
leezu commented on issue #17514: C++-Package examples broken URL: https://github.com/apache/incubator-mxnet/issues/17514#issuecomment-582163801 > But I'm still wondering why compiling and linking with GCC-9.2/CUDA-10.2 + commit ffeebe4 as HEAD works but fails with 230ceee? You can see that https://github.com/apache/incubator-mxnet/commit/230ceee5d9e0e02e58be69dad1c4ffdadbaa1bd9 cleans up a lot of code, which probably affects the order in which libraries are linked. As you say, GCC 9.2 is unsupported by Cuda, so it's probably undefined behaviour and worked for some lucky reason with the old build script. Another reason could be that there is a bug in upstream GCC9.2 / linker. Feel free to investigate this further. If there's any bug in our build script, we're happy to update it. Also sorry to take over your issue to track the bug introduced by #16654 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] apeforest commented on a change in pull request #17444: [Large Tensor] Add LT support for NN optimizers and 1 activation function
apeforest commented on a change in pull request #17444: [Large Tensor] Add LT
support for NN optimizers and 1 activation function
URL: https://github.com/apache/incubator-mxnet/pull/17444#discussion_r374979974
##
File path: src/operator/optimizer_op-inl.h
##
@@ -225,7 +225,7 @@ struct MultiSGDKernelParam {
template
struct MultiSGDKernel {
template
- MSHADOW_XINLINE static void Map(int i, const MultiSGDKernelParam& param,
+ MSHADOW_XINLINE static void Map(index_t i, const MultiSGDKernelParam& param,
const OpReqType req) {
for (int index = 0; index < param.count; ++index) {
if ((size_t)i < param.sizes[index]) {
Review comment:
@access2rohit I think this is a problem for non 64-bit platform, not only to
this line of code. A better solution could be adding an assert in the front end
when tensor size/index is greater than int32 and platform is not 64-bit. What
do you think?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [incubator-mxnet] D-Roberts opened a new pull request #17517: [numpy] Add np.random.pareto and np.random.power
D-Roberts opened a new pull request #17517: [numpy] Add np.random.pareto and np.random.power URL: https://github.com/apache/incubator-mxnet/pull/17517 ## Description ## Add numpy.random.pareto and numpy.random.power. ## Checklist ## ### Essentials ### Please feel free to remove inapplicable items for your PR. - [ ] The PR title starts with [MXNET-$JIRA_ID], where $JIRA_ID refers to the relevant [JIRA issue](https://issues.apache.org/jira/projects/MXNET/issues) created (except PRs with tiny changes) - [ ] Changes are complete (i.e. I finished coding on this PR) - [ ] All changes have test coverage: - Unit tests are added for small changes to verify correctness (e.g. adding a new operator) - Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore) - Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL) - [ ] Code is well-documented: - For user-facing API changes, API doc string has been updated. - For new C++ functions in header files, their functionalities and arguments are documented. - For new examples, README.md is added to explain the what the example does, the source of the dataset, expected performance on test set and reference to the original paper if applicable - Check the API doc at https://mxnet-ci-doc.s3-accelerate.dualstack.amazonaws.com/PR-$PR_ID/$BUILD_ID/index.html - [ ] To the best of my knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change ### Changes ### - [ ] Feature1, tests, (and when applicable, API doc) - [ ] Feature2, tests, (and when applicable, API doc) ## Comments ## - If this change is a backward incompatible change, why must this change be made. - Interesting edge cases to note here This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] rondogency commented on a change in pull request #17270: Dynamic custom operator GPU support
rondogency commented on a change in pull request #17270: Dynamic custom
operator GPU support
URL: https://github.com/apache/incubator-mxnet/pull/17270#discussion_r374977594
##
File path: example/extensions/lib_custom_op/test_relu.py
##
@@ -0,0 +1,83 @@
+#!/usr/bin/env python3
+
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you 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.
+
+# coding: utf-8
+# pylint: disable=arguments-differ
+
+# This test checks dynamic loading of custom library into MXNet
+# and checks end to end compute of a simple 2D gemm custom op
+
+import mxnet as mx
+import os
+import time
+
+#load library
+if (os.name=='posix'):
+path = os.path.abspath('librelu_lib.so')
+mx.library.load(path)
+
+a = mx.nd.array([[-2,-1],[1,2]], ctx=mx.cpu())
+b = mx.nd.array([[-2,-1],[1,2]], ctx=mx.gpu())
+
+print("start ndarray compute-")
+print(mx.nd.my_relu(a))
+print(mx.nd.my_relu(b))
+print(mx.nd.my_state_relu(a))
+print(mx.nd.my_state_relu(b))
+
+print("start symbolic compute")
+c = mx.sym.Variable('c')
+d = mx.sym.Variable('d')
+e = mx.sym.my_relu(c)
+base = mx.sym.relu(d)
+in_grad = [mx.nd.empty((2,2), ctx=mx.gpu())]
+in_grad_base = [mx.nd.empty((2,2), ctx=mx.gpu())]
+exe = e.bind(ctx=mx.gpu(), args={'c':b}, args_grad=in_grad)
+exe_base = base.bind(ctx=mx.gpu(), args={'d':b}, args_grad=in_grad_base)
+out = exe.forward()
+out_base = exe_base.forward()
+print(out)
+print(out_base)
+
+print("start backward compute")
+out_grad = mx.nd.ones((2,2), ctx=mx.gpu())
+exe.backward([out_grad])
+exe_base.backward([out_grad])
+print(in_grad)
+print(in_grad_base)
+
+print("start testing larger ndarray-")
+a = mx.nd.uniform(shape=(100,100,100), ctx=mx.cpu())
+b = mx.nd.uniform(shape=(100,100,100), ctx=mx.gpu())
Review comment:
The fix is in #17516 along with one more fix
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [incubator-mxnet] rondogency commented on issue #17516: Fix custom op makefile and example test
rondogency commented on issue #17516: Fix custom op makefile and example test URL: https://github.com/apache/incubator-mxnet/pull/17516#issuecomment-582161403 @samskalicky @access2rohit fixing problems This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] rondogency opened a new pull request #17516: Fix custom op makefile and example test
rondogency opened a new pull request #17516: Fix custom op makefile and example test URL: https://github.com/apache/incubator-mxnet/pull/17516 ## Description ## - Fix Makefile problem that build directory may not be present when compiling custom operator sample libraries. - Fix inaccurate time measurement in test_relu.py example ## Checklist ## ### Essentials ### Please feel free to remove inapplicable items for your PR. - [ ] The PR title starts with [MXNET-$JIRA_ID], where $JIRA_ID refers to the relevant [JIRA issue](https://issues.apache.org/jira/projects/MXNET/issues) created (except PRs with tiny changes) - [ ] Changes are complete (i.e. I finished coding on this PR) - [ ] All changes have test coverage: - Unit tests are added for small changes to verify correctness (e.g. adding a new operator) - Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore) - Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL) - [ ] Code is well-documented: - For user-facing API changes, API doc string has been updated. - For new C++ functions in header files, their functionalities and arguments are documented. - For new examples, README.md is added to explain the what the example does, the source of the dataset, expected performance on test set and reference to the original paper if applicable - Check the API doc at https://mxnet-ci-doc.s3-accelerate.dualstack.amazonaws.com/PR-$PR_ID/$BUILD_ID/index.html - [ ] To the best of my knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change ### Changes ### - [ ] Feature1, tests, (and when applicable, API doc) - [ ] Feature2, tests, (and when applicable, API doc) ## Comments ## - If this change is a backward incompatible change, why must this change be made. - Interesting edge cases to note here This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[incubator-mxnet] branch master updated (513c365 -> a0506ab)
This is an automated email from the ASF dual-hosted git repository. lausen pushed a change to branch master in repository https://gitbox.apache.org/repos/asf/incubator-mxnet.git. from 513c365 [OpPerf] Fix markdown for native profile and add profile param in function desc (#17494) add a0506ab Fix typo in ubuntu_setup.md (#17496) No new revisions were added by this update. Summary of changes: docs/static_site/src/pages/get_started/ubuntu_setup.md | 5 - 1 file changed, 4 insertions(+), 1 deletion(-)
[incubator-mxnet] branch master updated (513c365 -> a0506ab)
This is an automated email from the ASF dual-hosted git repository. lausen pushed a change to branch master in repository https://gitbox.apache.org/repos/asf/incubator-mxnet.git. from 513c365 [OpPerf] Fix markdown for native profile and add profile param in function desc (#17494) add a0506ab Fix typo in ubuntu_setup.md (#17496) No new revisions were added by this update. Summary of changes: docs/static_site/src/pages/get_started/ubuntu_setup.md | 5 - 1 file changed, 4 insertions(+), 1 deletion(-)
[GitHub] [incubator-mxnet] leezu merged pull request #17496: Fix typo in ubuntu_setup.md
leezu merged pull request #17496: Fix typo in ubuntu_setup.md URL: https://github.com/apache/incubator-mxnet/pull/17496 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] leezu commented on issue #17043: Segmentation fault: 11
leezu commented on issue #17043: Segmentation fault: 11 URL: https://github.com/apache/incubator-mxnet/issues/17043#issuecomment-582153558 @larroy the issue you report is due to an incompatibility between the jemalloc version used and llvm openmp. Reproducer: ``` git clone --recursive https://github.com/apache/incubator-mxnet/ mxnet cd mxnet git checkout a726c406964b9cd17efa826738a662e09d973972 # workaround https://github.com/apache/incubator-mxnet/issues/17514 mkdir build; cd build; cmake -DUSE_CPP_PACKAGE=1 -DCMAKE_BUILD_TYPE=RelWithDebInfo -GNinja -DUSE_CUDA=OFF -DUSE_JEMALLOC=ON .. ninja ./cpp-package/example/test_regress_label # run a 2-3 times to reproduce ``` If you change the USE_JEMALLOC=OFF, it will work. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] ChaiBapchya opened a new issue #17515: [OpPerf] Regression test for OpPerf
ChaiBapchya opened a new issue #17515: [OpPerf] Regression test for OpPerf URL: https://github.com/apache/incubator-mxnet/issues/17515 ## Description Running regression test for OpPerf entails a. Updating the operator (API change) shouldn't break OpPerf utility b. API changes should be flagged by OpPerf c. Integration of OpPerf in CI/Dashboard (detailed discussion in existing open issue https://github.com/apache/incubator-mxnet/issues/15757 by @sandeep-krishnamurthy ) ## Motivation > Given that we are adding so many new op coverage thanks to your hard work, should we add regression tests to make sure the existing ops are not being negatively affected? https://github.com/apache/incubator-mxnet/pull/16253#pullrequestreview-352734340 Discussion in PR #16253 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] ChaiBapchya commented on issue #17487: [OpPerf] Consolidate array manipulation related operators
ChaiBapchya commented on issue #17487: [OpPerf] Consolidate array manipulation related operators URL: https://github.com/apache/incubator-mxnet/pull/17487#issuecomment-582144126 OpPerf for GPU : https://gist.github.com/ChaiBapchya/f2d6879b8ca7634773fb8c5b93367dae#file-mxnet_operator_benchmark_results_array_manipulation_gpu-md This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] RuRo edited a comment on issue #11434: add ignore_reinit to initialize to skip warnings
RuRo edited a comment on issue #11434: add ignore_reinit to initialize to skip warnings URL: https://github.com/apache/incubator-mxnet/pull/11434#issuecomment-582142854 @leezu, oh I didn't know, that `collect_params` accepted a regex. Nice. Yeah, in my case, I dynamically assemble models from bits and pieces, based on a huge config file, with some pretrained `gluon`/`gluoncv` model zoo fragments, some newly created Blocks and possibly some blocks from our custom, previously pretrained models. I guess, I could build some system around it, to keep track, which blocks need initialization or immediately initialize new blocks, when creating them, but just doing `model.initialize(ctx=ctx)` at the end is so much simpler and does exactly what I want it to do. Also, some models in `gluoncv.model_zoo` are returned partially initialized in different ways, depending on which `**kwargs` you passed to `get_model` and I really don't want to "support" all the various initialization configurations. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] RuRo commented on issue #11434: add ignore_reinit to initialize to skip warnings
RuRo commented on issue #11434: add ignore_reinit to initialize to skip warnings URL: https://github.com/apache/incubator-mxnet/pull/11434#issuecomment-582142854 @leezu, oh I didn't know, that `collect_params` accepted a regex. Nice. Yeah, in my case, I dynamically assemble models from bits and pieces, based on a huge config file, with some pretrained `gluon`/`gluoncv` model zoo fragments, some newly created Blocks and possibly some blocks from our custom, previously pretrained models. I guess, I could build some system around it, to keep track, which blocks need initialization or immediately initialize new blocks, when creating them, but just doing `model.initialize()` at the end is so much simpler and does exactly what I want it to do. Also, some models in `gluoncv.model_zoo` are returned partially initialized in different ways, depending on which `**kwargs` you passed to `get_model` and I really don't want to "support" all the various initialization configurations. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] olk edited a comment on issue #17514: C++-Package examples broken
olk edited a comment on issue #17514: C++-Package examples broken URL: https://github.com/apache/incubator-mxnet/issues/17514#issuecomment-582140073 The problem is that my dev machine runs Arch Linux(rolling releases). At the moment Arch Linux uses GCC-9.2 as default compiler + CUDA-10.2. But CUDA-10.2 supports only GCC-8.3 and the Arch Linux CUDA package is linked statically against GCC-8. After downgrading my system to the last version that uses the GCC-8.3 as the default (and CUDA-10.1 -> 2019/05/24) I could compile and link mxnet from github checkout. But I'm still wondering why compiling and linking with GCC-9.2/CUDA-10.2 + commit ffeebe4 as HEAD works but fails with 230ceee? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] olk edited a comment on issue #17514: C++-Package examples broken
olk edited a comment on issue #17514: C++-Package examples broken URL: https://github.com/apache/incubator-mxnet/issues/17514#issuecomment-582140073 The problem is that my dev machine runs Arch Linux(rolling releases). At the moment Arch Linux uses GCC-9.2 as default compiler + CUDA-10.2. But CUDA-10.2 supports only GCC-8.3 and the Arch Linux CUDA package links statically against GCC-8. After downgrading my system to the last version that uses the GCC-8.3 as the default (and CUDA-10.1 -> 2019/05/24) I could compile and link mxnet from github checkout. But I'm still wondering why compiling and linking with GCC-9.2/CUDA-10.2 + commit ffeebe4 as HEAD works but fails with 230ceee? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] olk commented on issue #17514: C++-Package examples broken
olk commented on issue #17514: C++-Package examples broken URL: https://github.com/apache/incubator-mxnet/issues/17514#issuecomment-582140073 The problem is that my dev machine runs Arch Linux(rolling releases). At the moment Arch linux uses GCC-9.2 as default compiler + CUDA-10.2. But CUDA-10.2 supports only GCC-8.3 and the Arch Linux CUDA package links statically against GCC-8. After downgrading my system to the last version that uses the GCC-8.3 as the default (and CUDA-10.1 -> 2019/05/24) I could compile and link mxnet from github checkout. But I'm still wondering why compiling and linking with GCC-9.2/CUDA-10.2 + commit ffeebe4 as HEAD works but fails with 230ceee? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] leezu commented on issue #17514: C++-Package examples broken
leezu commented on issue #17514: C++-Package examples broken URL: https://github.com/apache/incubator-mxnet/issues/17514#issuecomment-582139842 @olk, my point is that it's broken after a726c40. Try checking out a726c40 in a clean checkout and please rerun the build This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] ChaiBapchya commented on issue #16253: [OpPerf] Add Indexing ops
ChaiBapchya commented on issue #16253: [OpPerf] Add Indexing ops URL: https://github.com/apache/incubator-mxnet/pull/16253#issuecomment-582138893 > LGTM! just one comment about TODO. If it is then use the following format > # TODO(chaibapchya): @access2rohit Fair point. To prevent retriggering of CI, I will add this in the upcoming PRs. Thanks. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[incubator-mxnet] branch master updated (71a5c9e -> 513c365)
This is an automated email from the ASF dual-hosted git repository. apeforest pushed a change to branch master in repository https://gitbox.apache.org/repos/asf/incubator-mxnet.git. from 71a5c9e Fix Flaky Test Higher Order Grad (#17325) add 513c365 [OpPerf] Fix markdown for native profile and add profile param in function desc (#17494) No new revisions were added by this update. Summary of changes: benchmark/opperf/nd_operations/array_rearrange.py | 2 ++ benchmark/opperf/nd_operations/binary_operators.py| 4 benchmark/opperf/nd_operations/gemm_operators.py | 2 ++ benchmark/opperf/nd_operations/nn_optimizer_operators.py | 2 ++ benchmark/opperf/nd_operations/random_sampling_operators.py | 2 ++ benchmark/opperf/nd_operations/reduction_operators.py | 2 ++ benchmark/opperf/nd_operations/sorting_searching_operators.py | 2 ++ benchmark/opperf/nd_operations/unary_operators.py | 2 ++ benchmark/opperf/utils/common_utils.py| 3 ++- 9 files changed, 20 insertions(+), 1 deletion(-)
[GitHub] [incubator-mxnet] ChaiBapchya commented on a change in pull request #16253: [OpPerf] Add Indexing ops
ChaiBapchya commented on a change in pull request #16253: [OpPerf] Add Indexing
ops
URL: https://github.com/apache/incubator-mxnet/pull/16253#discussion_r374947810
##
File path: benchmark/opperf/utils/op_registry_utils.py
##
@@ -316,11 +318,37 @@ def get_all_rearrange_operators():
# Filter for Array Rearrange operators
rearrange_mx_operators = {}
-for op_name, op_params in mx_operators.items():
+for op_name, _ in mx_operators.items():
if op_name in rearrange_ops and op_name not in unique_ops:
rearrange_mx_operators[op_name] = mx_operators[op_name]
return rearrange_mx_operators
+
+def get_all_indexing_routines():
+"""Gets all indexing routines registered with MXNet.
+
+Returns
+---
+{"operator_name": {"has_backward", "nd_op_handle", "params"}}
+"""
+# @ChaiBapchya unravel_index errors out on certain inputs
Review comment:
It is an open issue whose link I have already added.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[incubator-mxnet] branch master updated (71a5c9e -> 513c365)
This is an automated email from the ASF dual-hosted git repository. apeforest pushed a change to branch master in repository https://gitbox.apache.org/repos/asf/incubator-mxnet.git. from 71a5c9e Fix Flaky Test Higher Order Grad (#17325) add 513c365 [OpPerf] Fix markdown for native profile and add profile param in function desc (#17494) No new revisions were added by this update. Summary of changes: benchmark/opperf/nd_operations/array_rearrange.py | 2 ++ benchmark/opperf/nd_operations/binary_operators.py| 4 benchmark/opperf/nd_operations/gemm_operators.py | 2 ++ benchmark/opperf/nd_operations/nn_optimizer_operators.py | 2 ++ benchmark/opperf/nd_operations/random_sampling_operators.py | 2 ++ benchmark/opperf/nd_operations/reduction_operators.py | 2 ++ benchmark/opperf/nd_operations/sorting_searching_operators.py | 2 ++ benchmark/opperf/nd_operations/unary_operators.py | 2 ++ benchmark/opperf/utils/common_utils.py| 3 ++- 9 files changed, 20 insertions(+), 1 deletion(-)
[GitHub] [incubator-mxnet] olk commented on issue #17514: C++-Package examples broken
olk commented on issue #17514: C++-Package examples broken URL: https://github.com/apache/incubator-mxnet/issues/17514#issuecomment-582136050 @leezu My HEAD points to 71a5c9e65 (a726c4069 is already in the commit history) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] apeforest merged pull request #17494: [OpPerf] Fix markdown for native profile and add profile param in function desc
apeforest merged pull request #17494: [OpPerf] Fix markdown for native profile and add profile param in function desc URL: https://github.com/apache/incubator-mxnet/pull/17494 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] guanxinq commented on a change in pull request #15969: Partitioning Gluon HybridBlocks
guanxinq commented on a change in pull request #15969: Partitioning Gluon
HybridBlocks
URL: https://github.com/apache/incubator-mxnet/pull/15969#discussion_r374945503
##
File path: python/mxnet/gluon/block.py
##
@@ -967,6 +968,27 @@ def _build_cache(self, *args):
self._cached_op_args.append((False, params[name]))
flags = [('data_indices', data_indices), ('param_indices',
param_indices)] + \
self._flags
+
+args, _ = _flatten(args, "input")
+args_without_none = [ele for ele in args if ele is not None]
+try:
+for is_arg, i in self._cached_op_args:
+if not is_arg:
+tmp = i.data()
Review comment:
Done.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [incubator-mxnet] guanxinq commented on a change in pull request #15969: Partitioning Gluon HybridBlocks
guanxinq commented on a change in pull request #15969: Partitioning Gluon
HybridBlocks
URL: https://github.com/apache/incubator-mxnet/pull/15969#discussion_r374945304
##
File path: python/mxnet/gluon/block.py
##
@@ -967,6 +968,27 @@ def _build_cache(self, *args):
self._cached_op_args.append((False, params[name]))
flags = [('data_indices', data_indices), ('param_indices',
param_indices)] + \
self._flags
+
+args, _ = _flatten(args, "input")
+args_without_none = [ele for ele in args if ele is not None]
Review comment:
Removed.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [incubator-mxnet] mseth10 commented on a change in pull request #15969: Partitioning Gluon HybridBlocks
mseth10 commented on a change in pull request #15969: Partitioning Gluon
HybridBlocks
URL: https://github.com/apache/incubator-mxnet/pull/15969#discussion_r374941692
##
File path: python/mxnet/gluon/block.py
##
@@ -967,6 +968,27 @@ def _build_cache(self, *args):
self._cached_op_args.append((False, params[name]))
flags = [('data_indices', data_indices), ('param_indices',
param_indices)] + \
self._flags
+
+args, _ = _flatten(args, "input")
+args_without_none = [ele for ele in args if ele is not None]
+try:
+for is_arg, i in self._cached_op_args:
+if not is_arg:
+tmp = i.data()
Review comment:
can we remove assignment and just call `i.data()`
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [incubator-mxnet] mseth10 commented on a change in pull request #15969: Partitioning Gluon HybridBlocks
mseth10 commented on a change in pull request #15969: Partitioning Gluon
HybridBlocks
URL: https://github.com/apache/incubator-mxnet/pull/15969#discussion_r374941339
##
File path: python/mxnet/gluon/block.py
##
@@ -967,6 +968,27 @@ def _build_cache(self, *args):
self._cached_op_args.append((False, params[name]))
flags = [('data_indices', data_indices), ('param_indices',
param_indices)] + \
self._flags
+
+args, _ = _flatten(args, "input")
+args_without_none = [ele for ele in args if ele is not None]
Review comment:
` args_without_none` unused, can be removed
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [incubator-mxnet] mseth10 commented on a change in pull request #15969: Partitioning Gluon HybridBlocks
mseth10 commented on a change in pull request #15969: Partitioning Gluon
HybridBlocks
URL: https://github.com/apache/incubator-mxnet/pull/15969#discussion_r374941339
##
File path: python/mxnet/gluon/block.py
##
@@ -967,6 +968,27 @@ def _build_cache(self, *args):
self._cached_op_args.append((False, params[name]))
flags = [('data_indices', data_indices), ('param_indices',
param_indices)] + \
self._flags
+
+args, _ = _flatten(args, "input")
+args_without_none = [ele for ele in args if ele is not None]
Review comment:
unused, can be removed
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [incubator-mxnet] ChaiBapchya commented on issue #17500: [OpPerf] Implement remaining nn_conv ops in opperf
ChaiBapchya commented on issue #17500: [OpPerf] Implement remaining nn_conv ops in opperf URL: https://github.com/apache/incubator-mxnet/pull/17500#issuecomment-582129467 > Thank you @ChaiBapchya > > > So if you print add_res you will see the details. > > It would be better to add `print(add_res)` explicitly to the code snippet in the README.md. > > > Yes, as it currently stands opperf utility can only be used after cloning the repo and setting the PYTHONPATH to the repo. > > Either explicitly document this requirement in the README or remove this requirement so the users can run benchmark directly after mxnet is pip installed. @TaoLv As requested, add the 2 changes to my existing PR - specifically this commit - https://github.com/apache/incubator-mxnet/pull/17487/commits/4228baac8dff5c987c64c49d66f954754291eb6c Does this help? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [incubator-mxnet] ChaiBapchya commented on issue #17487: [OpPerf] Consolidate array manipulation related operators
ChaiBapchya commented on issue #17487: [OpPerf] Consolidate array manipulation related operators URL: https://github.com/apache/incubator-mxnet/pull/17487#issuecomment-582128165 Entire OpPerf for CPU : https://gist.github.com/ChaiBapchya/f2d6879b8ca7634773fb8c5b93367dae#file-mxnet_operator_benchmark_results_array_manipulation_cpu-md This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
