Re: [apache/incubator-mxnet] [RFC] Custom Operator Part 2 (#17006)

[JackieWu]

@larroy Users may need matrix operators and DNN Op(e.g. ReLU, Conv) when 
writing a custom Op. Although they can implement it by third-party libraries, 
it is more convenient to use the built-in functions in MXNet.

-- 
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/17006#issuecomment-569467244

Re: [VOTE] Release Apache MXNet (incubating) version 1.6.0.rc0

[Lausen, Leonard]

When including the OMP fixes in 1.6, Chris's fix for a race condition should be
included as well. So it's 3 PRs:

https://github.com/apache/incubator-mxnet/pull/17012
https://github.com/apache/incubator-mxnet/pull/17039
https://github.com/apache/incubator-mxnet/pull/17098

While all of these don't affect the binary Python builds that will be
distributed for 1.6 release, they do affect any users building the 1.6 release
from source with cmake. So it's beneficial to backport the 3 PRs.

On Fri, 2019-12-27 at 11:24 -0800, Pedro Larroy wrote:
> Agree with Sheng, I think it would be good to have the nice fixes that
> Leonard has done for 1.6 and not delay them to further releases since they
> are beneficial to users and developers. Thanks Leonard for helping fix
> these long standing issues.
> 
> On Fri, Dec 27, 2019 at 11:03 AM Lin Yuan  wrote:
> 
> > No, I just wanted to call it out because the title of the issue says
> > "Failed
> > OpenMP assertion when loading MXNet compiled with DEBUG=1
> > ;".
> > If this is considered a release blocker, I think we should backport it to
> > 1.6.
> > 
> > Thanks,
> > Lin
> > 
> > On Fri, Dec 27, 2019 at 10:47 AM Sheng Zha  wrote:
> > 
> > > Reading these issues it’s pretty clear to me that these are fixes for
> > > broken builds. I think we do consider broken builds to be release
> > blockers.
> > > Lin, am I missing something on which you base your suggestion for
> > delaying
> > > these changes?
> > > 
> > > -sz
> > > 
> > > > On Dec 27, 2019, at 10:30 AM, Lin Yuan  wrote:
> > > > 
> > > > Are these release blocker? It's very risky to make such last-minute
> > big
> > > > change after code freeze.
> > > > 
> > > > Can we do this in the next release?
> > > > 
> > > > Lin
> > > > 
> > > > > On Fri, Dec 27, 2019 at 7:37 AM Lausen, Leonard
> > > 
> > > > > wrote:
> > > > > 
> > > > > In case of backporting #17012, also
> > > > > https://github.com/apache/incubator-mxnet/pull/17098 must be
> > > backported.
> > > > > The
> > > > > updated OpenMP added a new target which is not used by MXNet but
> > breaks
> > > the
> > > > > build on some systems with nvptx. #17098 disables building this unused
> > > and
> > > > > broken feature.
> > > > > 
> > > > > > On Thu, 2019-12-26 at 12:55 -0800, Pedro Larroy wrote:
> > > > > > https://github.com/apache/incubator-mxnet/pull/17012  should be also
> > > > > ported
> > > > > > to the release branch.
> > > > > > 
> > > > > > On Fri, Dec 20, 2019 at 1:39 PM Przemysław Trędak <
> > ptre...@apache.org>
> > > > > > wrote:
> > > > > > 
> > > > > > > That issue is now fixed in master, I am in the process of
> > > > > cherry-picking
> > > > > > > the fix to v1.6.x branch. I will prepare the RC1 once that is
> > > > > > > ready.
> > > > > > > 
> > > > > > > Thanks
> > > > > > > Przemek
> > > > > > > 
> > > > > > > On 2019/12/20 20:07:36, Lin Yuan  wrote:
> > > > > > > > What's the next step for the release? Should we continue testing
> > > > > this and
> > > > > > > > vote or wait until the
> > > > > > > > https://github.com/apache/incubator-mxnet/issues/17105 is fixed?
> > > > > > > > 
> > > > > > > > Thanks!
> > > > > > > > 
> > > > > > > > Lin
> > > > > > > > 
> > > > > > > > On Wed, Dec 18, 2019 at 12:55 AM Lausen, Leonard
> > > > > > > 
> > > > > > > > wrote:
> > > > > > > > 
> > > > > > > > > Thanks Przemysław for managing this release and everyone who
> > > > > > > contributed
> > > > > > > > > to it.
> > > > > > > > > 
> > > > > > > > > Unfortunately Zechen Wang just discovered another issue with
> > > > > > > > > GPU
> > > > > > > Pointwise
> > > > > > > > > Fusion: https://github.com/apache/incubator-mxnet/issues/17105
> > > > > > > > > 
> > > > > > > > > Thus, -1.
> > > > > > > > > 
> > > > > > > > > Unfortunately, as the nightly release pipeline was broken
> > > > > > > > > until
> > > > > > > recently
> > > > > > > > > (and
> > > > > > > > > still isn't re-set up completely yet), the issue hasn't been
> > > > > discovered
> > > > > > > > > earlier.
> > > > > > > > > 
> > > > > > > > > Przemysław may have a quick fix for the issue. Another option
> > > > > would be
> > > > > > > to
> > > > > > > > > release 1.6 with MXNET_USE_FUSION default to 0.
> > > > > > > > > 
> > > > > > > > > Best regards
> > > > > > > > > Leonard
> > > > > > > > > 
> > > > > > > > > On Wed, 2019-12-18 at 05:30 +, Chen, Ciyong wrote:
> > > > > > > > > > Appreciate Tredak to push out voting for 1.6 release.
> > > > > > > > > > 
> > > > > > > > > > +1 as we've done lots of tests with expected performance in
> > > > > > > > > > many
> > > > > > > > > different
> > > > > > > > > > scenarios including both single-node and multi-node (horovod
> > > > > based),
> > > > > > > > > both FP32
> > > > > > > > > > and INT8 precision on many topologies.
> > > > > > > > > > 
> > > > > > > > > > -Ciyong
> > > > > > > > > > 
> > > > > > > > > > -Original Message-
> > > > > > > > > > From: Zhao, Patric 
> > > 

Re: [apache/incubator-mxnet] [RFC] Custom Operator Part 2 (#17006)

[Sam Skalicky]

We should create a namespace for the stuff in the lib_api.h file as suggested 
by @larroy:
https://github.com/apache/incubator-mxnet/pull/15760/files#r311756416

-- 
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/17006#issuecomment-569422074