-
Notifications
You must be signed in to change notification settings - Fork 5.6k
Intel Open Questions
-
Is it possible to create PR to PaddlePaddle repo without using a fork?
- Yes, but for contributors who have the write permission. According to Github's permission management rules, if a user could create a PR without forking, it assumes that the user has the write permission to the main repo, thus s/he could git push his/her feature branch into the main repo. However, as the number of contributors of PaddlePaddle grows, we have to formalize the permission management process -- new contributors start from the read permission only, after several rounds of PRs, they could get the write permission if a number of committers endorse his/her work.
-
What is kAnyLayout. How should we treat tensor in such layout when we want to transform it to some other layout, let say the MKLDNN one?
- kAnyLayout means fluid need not to care about the layout, some model does not need to handle layout. For a model that need Layout, the layout should be set, process and passed along with tensor. We will add related interface like InferLayout or ShareLayout soon.
-
Why only convolution and pooling have “use_cudnn” flag both in paddle v2 and fluid? Does it make sense to allow user to choose if cudnn has to be used only for these two OPs?
- Yes, Only these two OPs have cudnn implementation.
- Fluid will provide Priority mechanism, so user need not configure the preferred device one by one.
-
How does Python executes C++ code? Particularly, how C++ operations are registered to be available in Python
- We use pybind to register C++ OPs.
-
We're going to add new DataLayout enum like kMKLDNN in paddle to avoid unnecessary transformations to MKLDNN format, which is required for this library to work efficiently. Are you OK with that?
- Yes, you can add new layout type.
- Fluid will provide InferLayout/ShareLayout to set/pass layout alone with Tensor.
- Fluid will add a registry for registering layout transformation functions to the framework. Intel can use it to register data layout transformation function, and the framework will call it automatically.
-
Should we use both global use_mkldnn flag and per-OP use_ mkldnn flag as it is in paddle v2?
- In fluid, we should use MKLDNNPlace instead of use_mkldnn flag. For examples ,
place = fluid.CUDAPlace(0). - Fluid will provide Priority mechanism and a better configuration interface.
- In fluid, we should use MKLDNNPlace instead of use_mkldnn flag. For examples ,
-
In paddle v2 there are c++UTs for operators. In fluid it seems that there are only python UTs. Should we apply to that and create UTs for MKLDNN OPs in python?
- Yes, and you should modify the
if core.is_compiled_with_cuda() and core.op_support_gpu(self.op_type): places.append(core.CUDAPlace(0)), adding MKLDNNPlace to ensure the UTs. - Python UT actually call c++ core to do computation.
- Yes, and you should modify the
-
Can you define “Intel” label and use it with issues you find we (Intel) team should look at?
- Yes, we can. But how about "MKLDNN" label instead of "Intel" label?