NNPACK is currently only supported in the Makefile build
(https://github.com/apache/incubator-mxnet/issues/15974), which will be
removed. I think oneDNN (mkldnn) replaced it and we can remove it. Any concerns?
--
You are receiving this because you authored the thread.
Reply to this email
Drop the following loss operators since they are used with Module API:
- mx.symbol.LinearRegressionOutput
- mx.symbol.MAERegressionOutput
- mx.symbol.LogisticRegressionOutput
- mx.symbol.SVMOutput
- mx.symbol.SoftmaxOutput
--
You are receiving this because you authored the thread.
Reply to this
> the main function you listed will all be available in 2.x.
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-639266219
@yifeim module API will continue to be supported in 1.x and users are free to
stay on that version. For 2.x, we will only support numpy/npx API so users who
adopt those API will have to reimplement the model anyway. the main function
you listed will all be available in 2.x.
--
You are
Hi there, I am too a little concerned about dropping module support. Since a
large percent of the user based started with module APIs, dropping that support
could alienate the user base.
I got familiar around mxnet-1.3. The main functions I appreciate are:
1. sparse vector symbols - which are
mxnet.rnn module should be deprecated and removed too given it's designed for
interacting with symbol API.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@zhreshold thanks for bringing this up. Currently the test for that is the
longest running one too, so if there's no objection I hope that we could move
forward in removing it soon
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
In the long run, gluon vision model zoo will be maintained in GluonCV and
therefore mxnet.gluon.vision.model_zoo should be deprecated to avoid duplicate
maintenance efforts in 2.0
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
caffe usage is very low now and let's deprecate caffe converter too.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-613546835
> @lanking520 @zachgk @terrytangyuan @aaronmarkham could one of you start a
> discussion in a new issue on the JVM ecosystem support in 2.0? This topic
> seems to require extended discussion.
I created one here https://github.com/apache/incubator-mxnet/issues/17783
--
You are receiving this
@lanking520 @zachgk @terrytangyuan @aaronmarkham could one of you start a
discussion in a new issue on the JVM ecosystem support in 2.0? This topic seems
to require extended discussion.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it
Good question. I don't know. There wasn't a new release then. 路♀
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-595885111
> Thanks @zachgk - I took a couple of screenshots so I could share here
>
> Here is the Scala package
> 
>
> and here is the Clojure package
>
I vote for "upgrade/rewrite Scala API and bring up MXNet 2.0 features" as
it took us a lot of efforts to bring MXNet to Scala originally and there
are already adopters of Scala API in industries.
On Fri, Mar 6, 2020 at 11:02 AM Wang Jiajun
wrote:
> > We may also drop ONNX in MXNet 2. I'm not
+1 for "upgrade/rewrite Scala API and bring up MXNet 2.0 features" as it took
us a lot of efforts to bring MXNet to Scala originally and there are already
adopters of Scala API in industries.
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on
I vote for "upgrade/rewrite Scala API and bring up MXNet 2.0 features" as
it took us a lot of efforts to bring MXNet to Scala originally and there
are already adopters of Scala API in industries.
On Fri, Mar 6, 2020 at 11:02 AM Wang Jiajun
wrote:
> > We may also drop ONNX in MXNet 2. I'm not
> We may also drop ONNX in MXNet 2. I'm not aware of anyone working on ONNX in
> MXNet and TVM can be used as a replacement.
+1 for keeping ONNX support. Although it has a lot of small problems, but I've
converted a lot of pytorch models to mxnet for deploying with the following
pipeline:
Thanks @zachgk - I took a couple of screenshots so I could share here
Here is the Scala package
and here is the Clojure package
@gigasquid Yeah, you can view the download statistics from
https://repository.apache.org/#central-stat.
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-595522607
Is there anyway to get the stats on downloads of the maven central
scala/clojure jars to see how much current use there is? If the numbers are
high or low and what trend is can help shape the decision
--
You are receiving this because you authored the thread.
Reply to this email directly or
@gigasquid @zachgk Since the Scala API are built a while ago, I can see some of
the deprecated sections: Module, DataparallelGroup, Symbol ... Most of the
training component would be invalid. There can be three approaches:
- upgrade/rewrite Scala API and bring up MXNet 2.0 features.
- drop Scala
Further thinking this through - since the Scala language binding currently
provides the base for both Java and Clojure, I would be nice to know what the
future plans for the Scala language binding is. Whether or not that path is
supported will determine the other JVM langs.
--
You are
If I understand this correctly, since the Scala, Java, and Clojure bindings use
symbol and ndarray exclusively, this will also mean that they will be
effectively deprecated as well.
This is fine if what the community decides upon, but it should be called out
explicitly.
cc @lanking520 @nswamy
@TaoLv the search result shows API in the following categories:
- operator (these will be deprecated and the newest version should be covered
in https://github.com/apache/incubator-mxnet/issues/17096)
- gluon blocks (e.g. Con**v1**D). they are not legacy ops and will be kept
- io (these will be
We have `v1` and `v2` APIs like:
https://mxnet.incubator.apache.org/api/python/docs/search.html?q=v1
https://mxnet.incubator.apache.org/api/python/docs/search.html?q=v2
Do we need cover them in the RFC? How to deprecate or unify these APIs?
--
You are receiving this because you authored the
I am generally in favor of those deprecations. The scariest part is the removal
of `mx.module` API, so definitely `Gluon is on par with module in terms of
functionality and performance` is very important for this to be successful.
--
You are receiving this because you authored the thread.
TensorRT support is currently using ONNX to convert from NNVM:
TensorRT support is currently using ONNX to convert from NNVM:
I think we should keep ONNX APIs, since it is able to export many basic models,
although it is not perfect. Users will train their models in MXNet 2.0, and
export ONNX model, then use the ONNX model in their deployment frameworks.
(http://onnx.ai/supported-tools).
It is useful to attract
We may also drop ONNX in MXNet 2. I'm not aware of anyone working on ONNX in
MXNet and TVM can be used as a replacement.
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
What about those v1, v2 APIs?
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-591754890
cc @apache/mxnet-committers
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-591743914
As the MXNet community is working on the next major version of MXNet as
described in #16167, this RFC seeks to clarify the scope of API deprecation, to
inform the community of the replacement API design, and to ensure informed
consensus.
Thanks to the long history of MXNet and the accumulated
33 matches
Mail list logo
