我有一个简单的自定义渲染脚本,可将NV21转换为RGB位图:
#pragma rs_fp_relaxed
rs_allocation NV21;
uint32_t Yline;
uint32_t UVline;
uint32_t Width;
uint32_t Height;
uchar4 __attribute__((kernel)) NV21toRGB(uint32_t x, uint32_t y)
{
uint32_t Vidx = Yline*Height + (x & ~1) + y/2 * UVline;
short Y = rsGetElementAt_uchar(NV21, x + y * Yline);
short V = rsGetElementAt_uchar(NV21, Vidx) - 128;
short U = rsGetElementAt_uchar(NV21, Vidx + 1) - 128;
// https://en.wikipedia.org/wiki/YCbCr#JPEG_conversion
short R = Y + (512 + 1436 * V) / 1024; // 1.402
short G = Y + (512 - 352 * U - 731 * V) / 1024; // -0.344136 -0.714136
short B = Y + (512 + 1815 * U ) / 1024; // 1.772
if (R < 0) R = 0; else if (R > 255) R = 255;
if (G < 0) G = 0; else if (G > 255) G = 255;
if (B < 0) B = 0; else if (B > 255) B = 255;
return (uchar4){R, G, B, 255};
}
此脚本的动机是ScriptIntrinsicYuvToRGB
使用视频 BT.610色彩空间(其中 Y 在[16…235]
范围内)。
结果令人满意,但是在我的设备(装有Android 10的诺基亚4.2)上,它的速度比固有脚本慢大约两倍:平均9
vs。 18 ms
适用于1920x1080。这两个脚本使用相同的输入和输出分配。
所有时间均在Release Arm64版本上进行测量。值得一提的是,最短的时间是11 ms
。实验表明,检索YUV和转换计算都可以进行优化:如果我只返回rsYuvToRGBA_uchar4(Y, U, V)
,则平均时间将降至14 ms
。
问题:有什么方法可以进一步改进自定义脚本?例如,Tim Murray mentioned 自定义内在函数 ,但我什至在2020年都不知道如何定义它们。
更新 :谢谢AccoGuy,我尝试了带/不带debug.rs.default-CPU-driver 1
的这两个渲染脚本(请参见comment commit)。结果是惊人的:
使用内部转换器,转换本身的时间为4 ms
(ScriptIntrinsicYuvToRGB.ForEach()
),无辜的5 ms
的时间为outputAllocation.copyTo(output)
。
当我禁用GPU(adb shell setprop debug.rs.default-CPU-driver 1
)时,时间为3 ms
加1 ms
。
在使用自定义脚本的情况下,在禁用的GPU上,时间介于13 ms
和30 ms
之间,但平均需要~19 ms
进行转换(加上相同的1 ms
用于复制)。 / p>
意外的部分是启用GPU时,时间分为 (错误因为我忘记了asynchronous nature of forEach);
已修复: 2 ms
进行转换和 18 ms
14 ms
用于转换,7 ms
用于outputAllocation.copyTo(output)
。
该模式在其他设备上仍然有效,甚至可能更强。例如。具有Snapdragon 835的Sony在1 ms
中运行固有RS,在4 ms
中运行自定义RS。固有脚本之后的分配副本为2 ms
,自定义RS之后的分配副本为4 ms
。
我不知道这是怎么发生的,或者如何改善它。