ysh329
commented
4 years ago 2.1 策略一： TuningType::FAST （通用）
通用FAST策略的代码比较简单。可以看出按照z、x、y的顺序依次设置work group：
- 首先，找z方向的local work size，找寻过程是来找grid.z（即z方向的global work size）最大能被
max_divisor（默认为8）整除的数。从8往下找，若grid.z能被8整除则8就是z方向的local work size，否则再尝试4、2，如果都不满足则以传入的max_divisor作为上界往下找； - 当z方向确定了，则就有x和y方向的local work size的乘积上限也确定了。即使用
kernel_info.max_work_group_size，，每个CLKernel对象都有一个struct KernelInfo包含了private_memory_size和max_work_group_size，当CLKernel::CreateFromProgram执行时，这二者均是通过查询OpenCL内置的CL_KERNEL_PRIVATE_MEM_SIZE和CL_KERNEL_WORK_GROUP_SIZE信息分别获取到每个work item的private mem，以及GPU设备最大支持的work group，来除去刚得到的z方向的local work size； - 确定x方向的local work size。用grid.x除以2并向上取整，与wg_xy_size比较大小，取小的作为x方向的local work size；
- 确定y方向的local work size。wg_xy_size除以wg_x，与grid.y取较小的，作为y方向的local work size。
int3 GetWorkGroup(const int3& grid, int max_size) {
int wg_z = GetBiggestDividerWithPriority(grid.z, 8);
int wg_xy_size = max_size / wg_z;
int wg_x = std::min(DivideRoundUp(grid.x, 2), wg_xy_size);
int wg_y = std::min(wg_xy_size / wg_x, grid.y);
return int3(wg_x, wg_y, wg_z);
}
int GetBiggestDividerWithPriority(int number, int max_divider) {
if (number % 8 == 0 && 8 <= max_divider) {
return 8;
}
if (number % 4 == 0 && 4 <= max_divider) {
return 4;
}
if (number % 2 == 0 && 2 <= max_divider) {
return 2;
}
for (int i = max_divider; i != 0; i--) {
if (number % i == 0) {
return i;
}
}
return 1;
}
// @param n must be non negative
// @param divisor must be greater than zero
template <typename T, typename N>
T DivideRoundUp(T n, N divisor) {
const T div = static_cast<T>(divisor);
const T q = n / div;
return n % div == 0 ? q : q + 1;
}
最近发现TensorFlow Lite在GPU方面的性能有不小提升，先前了解到起初是支持的OpenGL来完成计算，猜想可能是考虑到GL的更广阔的的兼容性（不同的GPU版本，兼容的新老的库版本），但后续这次对GPU以OpenCL进行支持，应该考虑的更多是计算性能，也是与TFLite的相关竞品，如MACE / Paddle-Mobile / MNN / TNN在OpenCL上的支持和性能确实不容忽视。
说到OpenCL，深入一些都会谈及GPU的Kernel调优的手段和策略。根据阅读TensorFlow Lite在GPU方面的代码，发现其GPU/CL部分有
tuning_parameters.h这一文件：ProfiliingCommandQueue是
class ProfilingCommandQueue : public CLCommandQueue，在原有父类CLCommandQueue基础上，增加了opencl kernel计时、找最佳work group（GetBestWorkGroupIndex）等方法。此外，又发现可能和性能调优（tuning/tune）相关的目录或者文件：
device_info.cc：定义了不同型号的GPU的相关信息，针对不同硬件有细致的区分，为后续调优做指导：128*144*16，其它6xx系列为128*96*16；WaveSize：对于<400系列不支持、<600系列会判断是否full_wave进而选择64或32、其它型号也会判断是否full_wave使用进而判断是128还是64；work_group_picking.cc、work_group_picking.h：这个后续会详细说明，主要定义了上述两种tunning_type的策略实现，以及相关的辅助函数；tuning_parameters.h、tuning_parameters.cc；inference_context.cc：InitFromGraphWithTransforms有定义模型从原始Graph转换为适合GPU执行的Graph的流程。大体主要有3个步骤：GPUOperation::Tune设置WorkGroup。gpu_operation.h、gpu_operation.cc：实现了GPUOperation::Tune方法，包含整个Tune的过程，目前看来每次只会选择一种，并没有在多种WorkGroup下做选择，即目前还没支持针对某个确定Operation做大规模和批量WorkGroup的性能Tune。那就先来看看Tune这一方法，该方法进入时，会先获取KernelWorkGroups，注意是一个候选表
std::vector<int3> possible_work_groups，然后在最后if-else分支的else情况中，选择这些里最好的best_work_group_index，作为当前Operation最终的work_group。Tune的流程是不可避免的，每个GPU Operation node都会有Tune操作，而不是可选项，即
GetPossibleKernelWorkGroups方法是必然要进入的，并拿到可能的一个或者多个work group，即std::vector<int3> possible_work_groups。当有多个work groups时，会选择最佳workGroup，即会执行后续if-else的else分支的GetBestWorkGroupIndex方法，而当只有一个work groups时，直接返回，一个work groups也没有则直接报错提示absl::NotFoundError("Can not found work_group size to launch kernel");。1. 找候选work group
我们知道，当opencl的cl kernel在给定不能改动的情况下，性能和work group的设置策略有极大关系，
GPUOperation::GetPossibleKernelWorkGroups做了细致的设置策略，该方法会调用GetPossibleWorkGroups，暂且称之为通用策略，作为各个GPU Operation继承的默认策略。此外除了继承，各个GPU Operation node子类也可能做一些自定义的策略，目前发现有名为GetPossibleWorkGroupsConv的方法，发现对该带Conv后缀的设置策略的调用有如下Conv方法：可以看到目前调用带Conv后缀的方法的，主要是conv_buffer_1x1和conv_transpose，以及针对powervr实现的conv_powervr（但实际上，这个名字改为
conv_general可能更合适，因为其它架构的GPU如AMD/Intel及Adreno等在某些情况下，也有用到）。此外，根据目录下包含Conv关键字的文件，可以其中可以看到部分Conv并没有调用带Conv的后缀的work group设置策略，其中包括depthwise_conv、conv_texture、conv_constant、conv_3d等。换言之，这种特殊的GetPossibleWorkGroupsConv是针对性增加的。下面我们深入
GetPossibleWorkGroupsConv和GetPossibleWorkGroups看看他们的执行策略，还能怎么划分。我们深入
GetPossibleWorkGroupsConv和GetPossibleWorkGroups后（见如上代码），可以把找候选work group的情况和策略分为如下几种：综上来说，排除掉default的情况，Tuning策略有通用FAST、通用EXHAUSTIVE和非通用FAST三种，下面我们将会逐个分析实现。