ysh329

placeholder

# 基于分块的渲染 本文介绍了基于分块（tiled-based）渲染的GPU优缺点，并拿桌面级的即时渲染模式的GPU在优缺点上进行了比较，以及未来挑战。 Mali-gpu使用基于分片的渲染架构。这意味着GPU渲染过程会将帧缓冲区（framebuffers）输出为几个不同的较小子区域，这些较小子区域称为分块（tile）。完成后将每个分块写入内存，Mali gpu的分块很小，每个分块仅为16x16像素。 ## 即时模式（Immediate Mode）GPUs 传统的桌面级GPU架构通常被称为即时模式架构。该模式将渲染作为一个严格的命令流进行处理，在每次`draw`调用中对每个基本体（primitive）依次执行顶点（Vertex）和片段（Fragment）着色器。 下面是对该过程的伪代码示例，忽略并行处理和流水线： ```python for draw in renderPass: for primitive in draw: for vertex in primitive: execute_vertex_shader(vertex) if primitive not culled: for fragment...

# MindSpore Lite OpenCL AutoTune策略分析 mindspore的LiteKernel父类，会被相应设备继承，如OpenCL后端就会有子类`class OpenCLKernel`继承LiteKernel。这点确保了不会对不同设备后端侵入公共父类，造成代码污染，也让MindSpore的代码看着非常干净，`class OpenCLKernel`作为所有具体OpenCL Kernel类的公共父类，里面有一个`Tune`方法，各个具体的Op如Conv2DOpenCLKernel在实现时候可以不实现该`Tune`方法也可以实现，在调优时即`op->kernel->Tune()`。 ## 1. 调优Tune思路和流程 该`OpenCLKernel`父类的实现位于[lite/src/runtime/kernel/opencl/opencl_kernel.cc](https://github.com/mindspore-ai/mindspore/blob/7799c86797c3a2624fb477c595ea3083311c33fd/mindspore/lite/src/runtime/kernel/opencl/opencl_kernel.cc#L281)，下面我们从`Tune()`方法开始，看看其流程和思路。 下面是`Tune()`方法的实现，可以看到首先进去会判断是否开启了Profiling，因为调优需要根据不同参数设置下的OpenCL的Kernel执行时间，获取该时间就需要在创建OpenCL Command Queue时对属性设置加上Profiling的Flag，且对要获取时间的Kernel在入队时设置event，才能获取GPU的计算时间。 紧接着是TuneMode的判断，根据查询MindSpore Lite的代码，发现其有3种TunningMode： 1. `TuningMode::DEFAULT`：不做调优，直接返回； 2. `TuningMode::FAST`：只对对`FAST_MODE_OPS`做调优，目前看到这是一个包含了3个OP的列表：DepthwiseConv2D、Conv2D、DeConv2D。在流程上，当进入该方法，会先判断是否是该模式，同时判断当前OP是否在此列表内的OP，若不在就直接返回。看来这也是FAST的精髓所在，同时后文也没发现模式上有什么区别； 3. `TuningMode::EXTREME`：对模型中所有OpenCL OP调优。 后面就是执行流程，具体看代码和我加入的注释： ```cpp int OpenCLKernel::Tune() {...

## 2. 生成候选参数的流程 前文，分析了整体流程，下面我们看下具体对LocalWorkSize的生成，这部分在`GenerateTunningParam`方法里，该方法在OpenCLKernel基类里就有实现的，作为子类如Conv2D等对其进行了重写。在通用性上，基类里的方法更具有普适性。 下面我们先来看看通用的生成策略，再看针对Conv2D的生成策略。 ### 2.1 通用的OpenCLKernel::GenerateTuningParam 这部分的实现可以在：[mindspore/lite/src/runtime/kernel/opencl/opencl_kernel.cc#L231](https://github.com/mindspore-ai/mindspore/blob/28cbab85ede52f0af920d4f5dd3998e5566d8260/mindspore/lite/src/runtime/kernel/opencl/opencl_kernel.cc#L231)找到，在生成GenerateTuningParam过程中，生成过程完全依赖人工设定的规则和GlobalWorkSize： - 人工规则结合了暴力搜索和些许的经验，这部分在后文`GenerateLocalByGlobal`有写到； - GlobalWorkSize的设定，则是根据任务量在GPU上的分配，这个和OpenCL kernel的实现有直接关系，这里不做展开。 本文更关注生成调优参数的策略和流程，下面是通用的`OpenCLKernel`父类在`GenerateTuningParam`方法的实现代码： ```cpp std::vector OpenCLKernel::GenerateTuningParam() { size_t ndim = global_size_.size(); std::vector tuning_params = {}; if (ndim ==...

## 3. 性能变化 下面分别在麒麟820和骁龙855上以armv7平台上，选取了2个模型mobilenetv1和v2在两个框架上情形，即总共4个模型。并做了2个TuningMode的测试：default和extreme，测试过程中二者CPU都绑定大核，且设置单线程，确保性能稳定。 ### kirin820/armv7/bigcore/st 根据kirin820上的两个调优模式的增益来看（第三行：`performance%`），arm mali gpu对local work size的调优，可能并不敏感：较大的提升仅6.5%，且测试过程中发现存在调优性能和不调优性能，都存在一定波动，其它的提升均较小。 | TuningMode\Model | caffe_mobilenetv1 | caffe_mobilenetv2 | tf_mobilenetv1 | tf_mobilenetv2 | |:------------:|:------------------:|:-------------------:|:---------------:|:---------------:| | DEFAULT | 15.3 ms | 18.4...

## `gemm_mm_interleaved_transposed_f32_midgard` gemm performance using `gemm_mm_interleaved_transposed_f32_midgard` strategy https://github.com/ysh329/OpenCL-101/issues/23 ## other strategies This issue follows strategy above named `gemm_mm_interleaved_transposed_f32_midgard`. Besides, ACL has other GEMM or GEVM implementations: - `gemm_mm_interleaved_transposed_f32_bifrost`: This OpenCL...

## OpenCL ### 增加op kernel迁移进展：http://agroup.baidu.com/api/static/40/0243a9f31e7bc8dab29a523e69a6e0e50908a8?filename=OpenCL+%25E9%25AB%2598%25E4%25BC%2598+OP+.xlsx 1. 增加opencl image2d relu6 kernel：https://github.com/PaddlePaddle/Paddle-Lite/pull/2802 2. 增加opencl image2d elementwise_mul的4种kernel：https://github.com/PaddlePaddle/Paddle-Lite/pull/2815、https://github.com/PaddlePaddle/Paddle-Lite/pull/2945 3. 增加opencl image2d elementwise_add / fusion_elementwise_add_act kernel：https://github.com/PaddlePaddle/Paddle-Lite/pull/2844 4. 增加opencl image2d conv3x3 kernel以及修复conv3x3spl 5. 增加activation_type4宏方法：https://github.com/PaddlePaddle/Paddle-Lite/pull/2874 6. 增加fc+relu的融合：https://github.com/PaddlePaddle/Paddle-Lite/pull/3010...

# Paddle：调研/中英文文档修复/API修复 1. Pytorch op调研8个，完成。2月 2. 修复clip相关的paddle文档，级别高。6月 3. 3个训练clip相关API的迁移/修复，9月 4. clip_by_norm性能慢于1.8版本8倍：CMake对Eigen版本升级导致 5. 中英文clip等API中英文文档修复：https://github.com/PaddlePaddle/FluidDoc/pull/2922 、 https://github.com/PaddlePaddle/paddle/pull/28994

## Paddle-Lite ### 文档 1. 文档：增加如何添加Layout、如何使用OPENCL预测：https://github.com/PaddlePaddle/Paddle-Lite/pull/2897 、 https://github.com/PaddlePaddle/Paddle-Lite/pull/3091 ### bug修复 1. 修复build.sh、ci_build.sh、build_bm.sh里多线程编译。拼写错误等：https://github.com/PaddlePaddle/Paddle-Lite/pull/3094/files 2. 修复armv8 cpu编译demo/mobile_light.so出现undef CreatePaddlePredictor的问题：https://github.com/PaddlePaddle/Paddle-Lite/pull/3123 3. 增强现有单测，追加命令行补充input_shape/repeats/warmup/是否打印结果 ，便于benchmark：https://github.com/PaddlePaddle/Paddle-Lite/pull/3153 4. 解耦精度和性能Profiler：https://github.com/PaddlePaddle/Paddle-Lite/pull/3305/files 5. 定位clang opencl编译失败，arm cpu编译奇慢无比的问题，二分commit定位发现是有改动kernel注册导致爆出大量return type&和override warn的警告log导致，修复为不报warn； 6. 修复tf_vgg16在转换cpu模型时，移除tf冗余op的pass因空指针挂掉的问题； ###...

## mobile业务：全民小视频-人脸特效AR项目-人脸关键点模型 - 背景： - 先前上线使用Ankain，目前计划迁移Paddle-Lite； - 目前plite性能比Anakin好：mv6s模型，shell环境plite 1.8ms，anakin 1.9ms。祥达app内lite 2.7ms，结果也已对齐； 环境：mv3模型、cpu-armv7-st； - 目前问题：mv6因int8缘故，精度较v3低，故用v3。v3的int8和float模型性能接近。人脸关键点v3模型，int8和float性能接近，int8收益很小，原因仍需进一步分析。 测了 【kernel（profile的k-average）整体耗时】 v3-int8-model: 5.908ms v3-float-model: 7.503ms 补充：repeats=10000，warmup=100 环境：v2.1.0, OMP_OFF，PROFILE，ADD_DETECT_KERNELS_OPS，test_mobilenetv1_int8 【模型整体耗时】 v3-int8-model: 10.969 ms v3-float-model: 11.951 ms...