是否应该移除对device_id的假设，以及类似use_gpu这样的bool变量

[shijiaxin]

Paddle中的变量device_id，在-1的时候表示CPU，在大于等于0的时候表示GPU，这样带来很大的限制，就是很难再支持除了Nvidia GPU和CPU之外的其他设备，也难以支持不同的实现方式。而且这样的需求还是很多的，比如让Paddle支持FPGA，ASIC芯片，AMD的GPU。

现在已经被merge的关于intel-mkldnn的代码也碰到了类似的问题，它的数据存储格式与CPU的格式不一样，因此需要实现一个MKLDNNMatrix.h，device_id类型使用-2，这显然不大合理。

如果需要加入其它的设备如FPGA，有一个基本的需求是占用多个device_id，而0以上的device_id已经被假设为GPU了，很难再分配出多个device_id，（难道用-3到-xxx？）。

另一个问题也类似，就是Paddle假设设备除了CPU，就是Nvidia的GPU，因此使用了use_gpu这样的bool变量，而不是用一个枚举类型来表示设备类型，添加新的设备支持就会变得十分困难。

重构中的代码有DeviceContext这样的类型，看起来比较容易支持新的Device，但到了具体实现的时候仍会有bool类型的判断，代码如下，如果一个CPU的Place和一个FPGA的Place判断，就会被判定为相等：

bool places_are_same_class(const Place &p1, const Place &p2) {
  return is_gpu_place(p1) == is_gpu_place(p2);
}

[typhoonzero]

这的确是个问题，实现多种设备支持，而且每种设备可能存在多个的时候，按照目前的方式的确比较困难和费解，而且要同时考虑新的设备的支持需要不影响已有的功能。

@luotao1 @Xreki @tensor-tang 麻烦一起看下？

[QiJune]

@shijiaxin 在重构的代码中，Place表示是在什么设备上，DeviceContext负责对应设备上的资源管理。

class FPGAPlace {};
typedef boost::variant<GPUPlace, CPUPlace, FPGAPlace> Place;

class FPGADeviceContext : DeviceContext {};

在实现该Place的Operator Kernel时

template <typename Place, typename T>
OperatorKernel {};

这样就可以了。当然对应的判断Place类型的某些函数需要修改，因为目前确实只考虑了两种Place，CPUPlace和GPUPlace

[shijiaxin]

如果我们打算在当前版本添加对FPGA的支持的话，是不是只需要添加FPGAPlace，FPGADeviceContext，再实现对应的Operator Kernel？ @QiJune

[QiJune]

@shijiaxin paddle现在正在重构代码，重构部分的代码会更加清晰，更加灵活。我们目前正在大规模的移植之前的layer到新框架中。欢迎给重构的代码加入fpga支持，重构工作应该会在10月份左右完成。

[QingshuChen]

@QiJune

paddle现在正在重构代码，重构部分的代码会更加清晰，更加灵活。我们目前正在大规模的移植之前的layer到新框架中。欢迎给重构的代码加入fpga支持，重构工作应该会在10月份左右完成。

移植layer到新框架指的是layer的实现都调用Operator，还是layer的概念会去掉？

[QiJune]

@QingshuChen layer会是一个python端的概念，在C++端重构后只有operator