Android NDK OpenGL 应用程序的浮点还是定点？答案

【问题标题】：Floating point or fixed-point for Android NDK OpenGL apps?Android NDK OpenGL 应用程序的浮点还是定点？
【发布时间】：2011-03-24 02:13:44
【问题描述】：

我正在尝试决定是对我的应用程序中的所有 3D 相关元素（大部分是 C++）主要使用浮点数还是整数。我知道大多数基于 ARM 的设备不支持硬件浮点，所以我认为任何繁重的浮点运算都会明显变慢。

但是，我计划在大多数情况下准备所有数据（即在适用的情况下使用顶点缓冲区并使用变化不大的矩阵进行转换），所以我只是将数据塞进 OpenGL 的喉咙里。我可以假设这或多或少直接到 GPU 上，并且会相当快吗？（顺便说一句，最低要求是 OpenGL ES 2.0，因此可能不包括旧的基于 1.x 的手机。）

另外 - 当我混合和匹配整数和浮点数时，惩罚如何？假设我所有的几何图形只是预先构建的浮点缓冲区，但我使用整数作为矩阵，因为这些确实需要像矩阵乘法这样的昂贵操作，我会在这里招致多少愤怒？

顺便说一句，我知道我应该保持低期望（听起来甚至要求 CPU 上的浮点数要求太多了），但是有没有像 128 位 VMX 寄存器这样的东西？

（我暗暗希望fadden 正在阅读这个问题并且有一个很棒的答案。）

【问题讨论】：

标签： android opengl-es android-ndk

【解决方案1】：

G1 和 MyTouch 等较旧的 Android 设备具有不支持浮点的 ARMv6 CPU。大多数较新的设备，如 Droid、Nexus One 和 Incredible，都使用具有 FP 硬件的 ARMv7-A CPU。如果您的游戏真的是 3D 密集型游戏，那么它对 3D 实现的要求可能比旧设备所能提供的更多，因此您需要确定要支持的硬件级别。

如果您只使用 Java 编写代码，您的应用将在可用时利用 FP 硬件。如果你用 NDK 写原生代码，并且选择 armv5te 架构，你根本不会得到硬件 FP。如果您选择 armv7-a 架构，则可以，但您的应用将无法在 ARMv7-A 之前的设备上使用。

来自 Java 的 OpenGL 现在应该位于“直接”字节缓冲区之上，目前从 Java 访问这些缓冲区的速度很慢，但从本机端访问速度非常快。（不过我对 GL 的实现了解不多，所以我不能提供更多。）

某些设备还支持 NEON“高级 SIMD”扩展，它提供了一些超出基本 VFP 支持的奇特功能。但是，如果您想使用它，则必须在运行时对其进行测试（看起来现在有示例代码 - 请参阅 NDK r4b 的 NDK page）。

较早的答案有一些 info about the gcc NDK 用于“硬”fp 的标志。

最终，“固定或浮动”的答案归结为您希望应用在哪种设备上运行。为 armv7-a 编写代码当然更容易，但您将自己从市场中分得一杯羹。

【讨论】：

我知道fadden 可以解决这个问题。我希望我可以多次投票:) 我已经将自己限制在 OpenGL ES 2.0 上，所以我可以编写顶点和片段着色器，所以我想我不妨一路走下去，需要 ARMv7（这可能会配合手）。我宁愿用漂亮的应用程序吸引更多用户群较小的人，也不愿向大众扔垃圾。他们现在也大多停止为 PlayStation 1 制作游戏了。
那么你应该在 ARMv7 上使用浮点数。它与 OpenGL ES 2.0 并没有齐头并进，但很接近
似乎大多数新手机都有 OpenGL ES 2.0。但是，我查看了基准分数，例如 AnTuTu 基准，发现许多价格较低的模型没有 FPU。

【解决方案2】：

在我看来，你应该尽可能地坚持定点。

不仅旧手机缺少浮点支持，HTC Wildfire 等新手机也缺少浮点支持。

另外，如果您选择需要 ARMv7，请注意，例如，摩托罗拉 Milestone（欧洲的 Droid）确实配备了 ARMv7 CPU，但由于 Android 2.1 是为此设备构建的方式，该设备不会使用您的 armeabi-v7a 库（并可能从市场中隐藏您的应用程序）。

我个人通过使用 NDK r4b 提供的新 cpufeatures library 检测 ARMv7 支持来解决此问题，并使用 dlopen() 按需加载一些 armeabi-v7a 库。

【讨论】：