nt: Wednesday, April 10, 2019 1:34 PM
> To: dev@mxnet.incubator.apache.org
> Subject: Re: [MXNET 2.0 Wishlist] [DISCUSS] Refine the InferStorageType and
> memory planning pass
>
> Agreed with Tianqi that we could have better implementation once we have
> better tvm nnvm v2 integ
why I sent out
> > this proposal to get more ideas from the community.
> >
> >
> > -tao
> >
> > -Original Message-
> > From: Skalicky, Sam [mailto:sska...@amazon.com.INVALID]
> > Sent: Wednesday, April 10, 2019 2:24 AM
> > To: dev@m
r` to a `default` backend on CPU. And I totally
> > agree with you that we need think more about the software architecture
> for
> > maintainability, testability and readability - that's why I sent out this
> > proposal to get more ideas from the community.
> >
> &g
cture for
> maintainability, testability and readability - that's why I sent out this
> proposal to get more ideas from the community.
>
>
> -tao
>
> -Original Message-
> From: Skalicky, Sam [mailto:sska...@amazon.com.INVALID]
> Sent: Wednesday, April 10, 2
esday, April 10, 2019 11:03 AM
> > To: dev@mxnet.incubator.apache.org
> > Subject: RE: [MXNET 2.0 Wishlist] [DISCUSS] Refine the InferStorageType
> and
> > memory planning pass
> >
> >
> > Thank you Tianqi and Sam for the kind suggestions.
> >
>
ainability, testability and readability - that's why I sent out this
> proposal
> to get more ideas from the community.
>
>
> -tao
>
> -Original Message-
> From: Skalicky, Sam [mailto:sska...@amazon.com.INVALID]
> Sent: Wednesday, April 10, 2019 2:24 AM
&
2019 2:24 AM
To: dev@mxnet.incubator.apache.org
Subject: Re: [MXNET 2.0 Wishlist] [DISCUSS] Refine the InferStorageType and
memory planning pass
I agree with Tianqi. We should let MKLDNN partitipate in memory planning by
first having a separate NNVM pass and then using that info in the regular
memory
I agree with Tianqi. We should let MKLDNN partitipate in memory planning by
first having a separate NNVM pass and then using that info in the regular
memory planning phase.
Its starting to sound like MKLDNN should be treated like an accelerator rather
than an operator library. As it has explici
The layout transformation should really be a separate optimization pass
rather than memory planning. As is done in the TVM stack. If we want to do
a clean slate solution, I would recommend looking into that instead.
TIanqi
On Tue, Apr 9, 2019 at 1:46 AM Lv, Tao A wrote:
>
>
> Hi dev,
>
>
>
> As