C / Renderscript /霓虹灯内部函数之间的电池电量消耗 - 视频滤波器（Edgedetection）APK [英] Battery Power Consumption between C/Renderscript/Neon Intrinsics -- Video filter (Edgedetection) APK

问题描述

我已经开发了3 C / RS /霓虹内部函数版本的视频处理算法的采用Android NDK（用C ++的API Renderscript）。调用C / RS /霓虹灯将从JAVA前端进行到母语水平的NDK的一面。我发现，由于某种原因，霓虹灯版本会消耗大量的电能与C和RS版本比较。我用的 Trepn 5.0 因为我的能力测试。

1. 能否有人澄清我就对这些方法C，Renderscript功耗级别 - GPU，霓虹灯内部函数。哪一个最耗电？

2. 什么是一个理想的功耗水平RS codeS？，因为GPU上运行更少的时钟频率和功耗一定要少！

3. 是否Renderscript的API专注于功率优化？

视频 - 1920×1080（20帧）

1. Ç - 11115.067毫秒（0.80mW）
2. RS - 9867.170毫秒（0.43mW）
3. 在霓虹灯本质 - 9160毫秒（1.49mW）

解决方案

首先，电力渲染脚本code的消耗取决于SOC，频率类型/电压，其中的CPU，GPU等操作

即使你从同一家厂商的CPU，ARM说比如A15S和A9S，A15S的CPU更耗电相比A9。同样，马里GPU4XX对6XX也表现出了同样的任务的功耗差异。 此外，功率变化量也不同厂商之间存在，例如，英特尔和ARM处理器，用于执行相同的任务。同样地，人们会注意到一个QCOM的Adreno GPU之间的功率差，并说ARM马里的GPU，即使它们运行在相同的频率/电压电平

如果你使用的Nexus 5，我们得到了一个四A15 CPU起动在每个CPU 2.3G的速度。 Renderscript推动CPU和GPU来的最高时钟速度。所以在此设备上，我期望的基于CPU /霓虹灯或只是CPU RS code中的功耗是最高取决于你正在做的，再其次是RS GPU code这样的操作的类型。所以底线，功耗，设备的类型正在使用事项很多由于它们使用的SOC的差异。在最新一代的SOC是在那里的，我期待的CPU /霓虹灯更加耗电然后GPU。

RS将推动CPU / GPU时钟频率，以最快的速度。所以，我不知道，如果能在这里做有意义的功耗优化。即使他们这样做，比起他们的最高速度消耗起，CPU / GPU的功耗的节能将是微乎其微的。

这功耗等移动设备上一个很大的问题，你可能会被罚款，从您的过滤器用于处理计算成像空间中的几帧功耗角度。但当下一个确实renderscript实时视频处理，该装置被加热这么快，甚至更低的视频分辨率，然后OS系统热管理开始发挥作用。这些热经理降低总体CPU速度，从而导致不​​可靠的性能，CPU renderscript。

回应意见

单独频率不耗电的原因。它是频率和电压的组合。举例来说，GPU运行在说200兆赫在1.25V和550兆赫在1.25V可能会消耗相同的功率。取决于如何电源域被设计在系统中，像0.9V应该足够200Mhz的和系统理论上应该transision GPU的功率域，以较低的电压时，频率下来。但不同的SOC的有各种各样的问题，因此不能保证一致的电压和频率转换。这可能是背后的原因GPU的功耗可能会更为额定负载高的原因之一。

所以不管是什么，复杂性，如果你持有的GPU电压在说类似1.25V@600兆赫，你功耗将是pretty的高，相当于给CPU的起动时2G@1.25V ..

我测试霓虹灯内在 - 5X5卷积和他们相比，不使用的CPU为同一任务pretty的快（3倍5倍）。氖硬件通常是在相同的功率域的CPU（又名MPU功率域）。因此，所有的CPU都保持在电压/频率，即使霓虹灯硬件工作正常。由于霓虹灯执行得更快对于给定的任务不是CPU，我也不会感到惊讶，如果它消耗更多的功率相对比CPU该任务。东西已经给你是否得到更快的性能 - 这显然是权力。

I have developed 3 C/RS/Neon-Intrinsics versions of Video Processing Algorithm using Android NDK (using C++ APIs for Renderscript). Calls to C/RS/Neon will be made to Native level on NDK side from JAVA front end. I found that for some reason Neon version consumes lot of power in comparison with C and RS versions. I used Trepn 5.0 for my power testing.

1. Can some one clarify me regarding the power consumption level for each of these methods C , Renderscript - GPU, Neon Intrinsics. Which one consumes most ?

2. What would be the Ideal power consumption level for RS codes ?, since GPU runs with less clock frequency and power consumption must be less!

3. Does Renderscript APIs focuses on power optimization ?

Video - 1920x1080 (20 frames)

1. C -- 11115.067 ms (0.80mW)
2. RS -- 9867.170 ms (0.43mW)
3. Neon Intrinsic -- 9160 ms (1.49mW)

解决方案

First, Power consumption of render script code is dependent on the type of SOC, the frequency/Voltages at which the CPUs, GPUs operate etc.

Even if you look at CPUS from the same vendor, say ARM for instance A15s and A9s, A15s CPUs are more power hungry compared to the A9. Similarly, A Mali GPU4XX versus 6XX also exhibits power consumption differences for the same task. In addition, power deltas also exist between different vendors, for instance, Intel and ARM CPUs, for the doing the same task. Similarly, one would notice power differences between a QCOM Adreno GPU and say ARM Mali GPU, even if they are operating at the same frequency/voltage levels.

If you use a Nexus 5, we got a QUAD A15 CPU cranking at 2.3G speed per CPU. Renderscript pushes CPUs and GPUs to their highest clock speed. So on this device, I would expect the power consumption of RS code based on CPU/Neon or just CPU to be highest depending on the type of operations you are doing and then followed by the RS GPU code. So bottomline, on power consumption, the type of device you are using matters a lot due to the differences in SOCs they use. In the latest generation of SOCs that are out there, I expect CPUs/Neon to be more power hungry then GPU.

RS will push the CPU/GPU clock frequency to the highest possible speed. So I am not sure if one could do meaningful power optimizations here. Even if they do, those power savings will be miniscule compared to the power consumed by CPUS/GPU at their top speed.

This power consumption is such a huge problem on mobile devices, you would probably be fine from power consumption angle with your filters for processing a few frames in computational imaging space. But the moment one does renderscript in real video processing, the device gets heated up so quickly even for lower video resolutions, and then the OS system thermal managers come into play. These thermal managers reduce the overall CPU speeds, causing unreliable performance with CPU renderscript.

Responses to comments

Frequency alone is not the cause of power consumption. It is the combination of frequency and voltage. For instance, GPU running at say 200 Mhz at 1.25V, and 550 Mhz at 1.25V will likely consume the same power. Depending on how power domains are designed in the system, something like 0.9V should be enough for 200Mhz and system should in theory transision GPU power domain to a lower voltage when frequency comes down. But various SOCs have various issues so one cannot guarantee a consistent voltage and frequency transition. This could be one reason behind why GPU power could be high even for nominal loads.

So for whatever, complexities, if you are holding GPU Voltage at say something like 1.25V@600 MHz, you power consumption will be pretty high and comparable to to that of CPUs cranking at 2G@1.25V...

I tested Neon intrinsic - 5X5 convolve and they are pretty fast (3x-5x) compared to not using CPUs for the same task. Neon hardware is usually in the same power domain as CPUs (aka MPU power domain). So all CPUs are held at the voltage/frequency even when Neon hardware is working. Since Neon performs faster for the given task than CPU, I wouldn't be surprised if it consumes more power relatively than the CPU for that task. Something has to give if you are getting faster performance - it is obviously power.

这篇关于C / Renderscript /霓虹灯内部函数之间的电池电量消耗 - 视频滤波器（Edgedetection）APK的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！