[Pten] Adjust the design of the pten main directory

[chenwhql]

PR types

Function optimization

PR changes

Others

Describe

[Pten] Adjust main dir of pten [Part 1]

原目录方案比选问题说明

• 未考率各设备所需的基础组件如何组织管理，比如像CUDAContext，CUDNN Handle等对象的存放
• 对于kernel的组织方式比较理想化，尽管可能对于一般kernel迁移时放置到什么位置比较明确，但是也引入了诸多缺点：
  • 对于kernel裁剪编译不太友好
  • 对于一些特殊用途的比如非api类的op等，比如fuse_op，和Python端文件的对应关系也属于比较模糊，迁移规则也不太明确
• 不能支持跨设备kernel写法统一的需求，不同设备的kernel均是分离实现的，这引入了重复的函数声明代码，若一个kernel复用多个kernel实现，可能会引入更多的重复代码
• 引入了上下层的重复目录和文件设计，迁移代码放置规则不明确，比如kernels下面有cpu和cuda，kernels下面的functions下面也有cpu和cuda，几乎每个文件夹下都有elementwise.h这个文件，再迁移新的kernel，它调用的函数都如何放置，目前是模棱两可的状态
• 未考虑反向kernel的迁移，原先计划反向kernel不属于公共的底层计算库，但后来经讨论认为这样不太合理，因此反向kernel的组织及其带来的训练与推理裁剪都需要考虑

新目录设计

一级目录基本保持现有的设计，增加backend和ops两个子目录

paddle/pten
./api (对外暴露的API及其实现)
	./include（对外暴露的API头文件）
	./lib（对外暴露API的实现）
./include (kernel层API头文件调用的入口)
./common (内外部均会使用到的基础数据结构)
./core (基础组件，比如Tensor相关接口，kernel注册接口，管理单元等)
./backends (各设备及后端的基础组件，下设cpu，cuda等后端目录)
./infermeta (infershape及dtype等相关工具函数)
./kernels (各设备及后端的kernel实现)
./ops (各op的定义，后续采取自动生成的方式完成大部分工作)
./tests (单元测试)

• backends中组织后续需要为各个后端的新增的数据结构，比如CPUContext、CUDAContext等
  • core中放置对于算子库来讲通用的基础数据结构，而特定后端的专用数据结构不放在core中，且依赖关系严格保证backends依赖core，但core不能依赖backends
  • 例1：Context如果有基类，则在core中，而继承的CPUContext在backends/cpu中，CUDAContext在baackends/cuda中
  • 例2：TensorBase在core中，DenseTensor给多数设备使用，也在core中，如果有MKLDNNTensor的话，因为它只给mkldnn用，应该在backends/dnnl中
• ops中组织新形式的Op定义（现阶段不是重点，后期再添加此目录）

下面重点介绍kernels的目录设计，因为此目录基本要承载原fluid/operators目录下的大部分代码，是最为重要的一个子目录。

kernels目录

paddle/pten/kernels
./ (放置设备无关的kernel声明和实现)
./cpu（仅放置cpu后端的kernel实现）
./cuda
./hip
./xpu
./npu
./dnnl
./eigen
./blas
./hybrid（放置原fluid operators下一些支持多设备的functor）
./primitive（放置邢冯设计的Kernel Primitive API实现）
...

说明如下：

• kernels下主目录，放置设备无关的kernel.h和kernel.cc，原则上每个kernel一个.h和.cc
  • 例如一个kernel是使用Primitive api实现的，那么不论在什么设备上，应该都只有一种实现，所以它的声明和实现均直接放置到kernels目录下即可（这是将来的理想状态）
  • 目前我们大部分kernel都不具备跨设备实现统一的特征，但是kernel的输入参数返回值除了DeviceContext之外，应该是一致的，所以kernel参数声明头文件还放到主目录下（和原先的设计保持一致，DeviceContext和T作为模板参数），各设备的函数实现在相应的设备文件夹中
    • 注意，这里跨设备实现统一，并不是指一个kernel的CPU和CUDA实现就算统一了，而是在所有设备的实现都一样，目前至少包括CPU，CUDA，XPU，NPU，MKLDNN等
  • 反向kernel如果不需要支持裁剪，可以做适当归并（但如果要为支持端侧训练留可能性，反向kernel可能也是裁剪的潜在目标）
• kernels下一级子目录，原则上按照backend分类按需新建，仅保留两个特殊的目录:
  • hybird：为了兼容原先fluid operators中functor和function设计保留的目录，放置支持多种后端的functor和functor，还按照原先的一个头文件，多个.cc(u)的方式组织（这部分代码在将来可能被移除，因为会逐渐被Kernel Primirive API替代，这里不做过度设计）
    • 例1：一个公共函数XXXFunction在reduce CPU和reduce CUDA的kernel实现中都被调用，并且reduce CPU和reduce CUDA的kernel实现是不一样的，那么这个XXXFunction应该在hybird目录中
    • 例2：一个函数XXXFunction在scale CPU和scale CUDA的kernel实现中都被调用，但scale CPU和CUDA实现是一样的，都是调用eigen进行实现，那么scale kernel和XXXFunction都应该在eigen目录中
  • primitive：邢冯设计的 Kernel Primitive API，多设备统一kernel的基础
• kernel迁移过来之后，首先创建对应kenrel头文件直接放置到kernels的根目录中，各后端的kernel实现放在相应的设备文件夹中
  • 可参考原先op的归并程度，如matmul原先是单独的.h/.cc，那移过来之后保持，但activation相关的基本写在一个.h/.cc，移过来也仍然保持归并（后续有必要再进一步拆分）
  • 例1：原先scale op的Kernel在scale_op.h中，迁移过来之后创建scale_kernel.h，scale_kernel.cc根据使用的后端放到对应的目录，比如原先paddle的scale使用的是eigen，应该放到eigen中
  • 例2：原先matmul的kernel使用blas实现，迁移过来之后，实现应该在blas中
• 迁移时，只有本kernel用到的辅助函数，一律和kernel实现放到同一个backend文件中，创建.h管理代码，不再单独在别处整理代码，除非这些辅助的函数实现是有多处使用的
  • 即使有多处调用，如果仍然限于同一设备，直接建头文件放到同一个目录下
    • 例如，reduce cuda除了reduce还有别处用吗，elementwise呢
• 反向kernel与前向kernel实现放置在不同的文件中，文件后缀采用*_grad_kernel.*，便于cmake分离编译
  • 不再为反向kernel单独创建目录，否则反向kernel目录下还要创建cpu/cuda等目录
  • 二阶导、三阶导的实现统一也放到grad kernel实现文件中

[paddle-bot-old]

✅ This PR's description meets the template requirements!
Please wait for other CI results.

[paddle-bot-old]

Thanks for your contribution!
Please wait for the result of CI firstly. See Paddle CI Manual for details.