最近有尝试将github中yolov8-pose的C++代码整合进入rockit demo,方便rockit demo也能展示pose效果。
整合进入后,发现其后处理(函数decode_boxes_and_keypoints)大约需要50ms,极其的不正常。
通过调试,
a. 代码片段:
auto centers = get_centers(std::ref(strides), std::ref(network_dims), raw_boxes_outputs.size(), strided_width, strided_height);
耗时20ms左右.
b. 三次box与keypoint的数据整理耗时15ms左右(特别是 6400的那次数据整理需要耗时12ms左右,远远大于1600 2ms左右的4倍)
// Boxes setup
float32_t qp_scale = raw_boxes_outputs[i]->vstream_info().quant_info.qp_scale;
float32_t qp_zp = raw_boxes_outputs[i]->vstream_info().quant_info.qp_zp;
auto output_b = common::get_xtensor(raw_boxes_outputs[i]);
int num_proposals = output_b.shape(0) * output_b.shape(1);
auto output_boxes = xt::view(output_b, xt::all(), xt::all(), xt::all());
xt::xarray<uint8_t> quantized_boxes = xt::reshape_view(output_boxes, {num_proposals, 4, regression_length + 1});
auto shape = {quantized_boxes.shape(1), quantized_boxes.shape(2)};
// Keypoints setup
float32_t qp_scale_kpts = raw_keypoints[i]->vstream_info().quant_info.qp_scale;
float32_t qp_zp_kpts = raw_keypoints[i]->vstream_info().quant_info.qp_zp;
auto output_keypoints = common::get_xtensor(raw_keypoints[i]);
int num_proposals_keypoints = output_keypoints.shape(0) * output_keypoints.shape(1);
auto output_keypoints_quantized = xt::view(output_keypoints, xt::all(), xt::all(), xt::all());
xt::xarray<uint8_t> quantized_keypoints = xt::reshape_view(output_keypoints_quantized, {num_proposals_keypoints, 17, 3});
auto keypoints_shape = {quantized_keypoints.shape(1), quantized_keypoints.shape(2)};
c. 其他的反量化之类的耗时也不少。
而同样的代码使用gihub的demo直接在RK3588上面编译却只有第一次需要50ms,后续只需要5ms左右的时间。
针对a,我注意到此部分在每帧调用的时候会得到一样的结果,我将此代码片段挪到初始化处,然后传参centers 到这个函数,节约处理时间。
但是其他部分完全没有发现任何异常的地方,起初我有怀疑到,后处理运行在CPU的大核小核原因,代码片段在我这边进行数据拷贝原因,也尝试将整个后处理另外开线程进行单独运算,都未能解决问题。
后面主要注意到Boxes/keypoints setup 时间在3次不同size情况下的巨大差异,通过查询资料,发现主要原因是我的rockit demo在代码编译的时候没有使用 -03 gcc的代码优化编译。
只需要在CMakeList.txt中增加一行
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -O3")
就可以解决此问题。
发表回复