Great!! Yes, please share!
On Fri, Mar 9, 2018 at 7:29 PM Can Balioglu wrote:
> We found a rather "hacky" way to dynamically inject our operators and data
> iterators during runtime. I can share the details if you are interested. We
> also plan to send out a design proposal for a proper exte
We found a rather "hacky" way to dynamically inject our operators and data
iterators during runtime. I can share the details if you are interested. We
also plan to send out a design proposal for a proper extensibility framework
similar to TensorFlow's plugin API.
-Can
On Wed, Mar 7, 2018, at 0
One potential problem is with libstdc++. Specifically with vectors. Our
operator interface uses vectors, which breaks when core lib and extension are
compiled with different compiler version
On 2018/03/06 22:45:16, Chris Olivier wrote:
> The static init of your module should register your oper
I also don't see any reason it wouldn't work.
I wonder if we could do this and then offer a convenient pip package with
operators in separated .SOs, each linked against various libs. For example
all versions of blas libs, all versions of cuda. We could then detected
the user's environment at run
The static init of your module should register your operator just as it
does for the operators in mxnet (NNVM_REGISTER_OP). While I haven't done
it personally, I see no reason why it wouldn't work like any other operator
at that point.
On Tue, Mar 6, 2018 at 1:28 PM, Barber, Christopher <
christo
There are two separate issues: how to compile against the MXNet source and how
to dynamically load external dynamic libraries. While it would be nice to have
all necessary headers in the same place, it doesn't really matter that much if
people building extensions have to have access to the entir
This was discussed in the past and so far, it seems possible for Unix
builds, although it’s going to be messy since the compile would generally
need access to all a large portion of the headers in the source tree, since
the “things needed to create your own op” aren’t necessarily all contained
in t
Could we actually just define a mechanism so the libs could register their
ops at runtime? No linking required?
On Tue, Mar 6, 2018, 8:36 PM Pedro Larroy
wrote:
> This is a good point. What additional blockers would there be for linking
> against a user provided library with custom operators?
>
This is a good point. What additional blockers would there be for linking
against a user provided library with custom operators?
On Tue, Mar 6, 2018 at 5:16 PM, Barber, Christopher <
christopher.bar...@analog.com> wrote:
> To avoid this kind of problem, you really need to support features that
To avoid this kind of problem, you really need to support features that allow
MXNet to be extended without having to resort to forking. There is currently no
way to add C++ custom operators without forking, and no way to share such
operators across projects. This creates a perverse incentive to
Maybe we could gather items our users would like to have before we cut the
release and make sure that they are included? This would show them that
we're genuinely interest in their demands and avoids problems like this at
the same time.
There are two reasons CI is not running older branches:
1. Th
I think its important to understand someone's day_job's customer is also a
user of MXNet. Right now MXNet project needs to put effort in helping users
and bringing them on-board. I don't think its a good idea to ask the
customer to come back after a new release is made or ask to use a fork.
With r
12 matches
Mail list logo