[Note] floating-point/fixed-point operations versus OpenGL

From the Android NDK example "bitmap-plasma":

We're going to perform computations for every pixel of the target bitmap. floating-point operations are very slow on ARMv5, and not too bad on ARMv7 with the exception of trigonometric functions. For better performance on all platforms, we're going to use fixed-point arithmetic and all kinds of tricks

I stumbled upon this one or two times before. So it really seems like this is an issue needed to be addressed, since I want to do lots of heavy pixel-by-pixel computation stuff (a.k.a. image processing). Maybe there is a better way to do this: instead of translating everything from floating-point to fixed-point operations or even finding and implementing "all kind of tricks", I could do everything with OpenGL. Android 1.6 supports OpenGL ES 1.1 and from Android 2.0 and up OpenGL ES 2.0 is supported. Such OpenGL-operation are probably performed on the same CPU, but I assume if OpenGL is doing some floating-to-fixed-point translation this is more effective than I could do.

Join the conversation

1 Comment

  1. It seems like my initial idea won't work out. I thought I could "fill" OpenGL with some values, let it do some magic (with my predefined functions) and then retrieve the results. I just learnt this is called GPGPU and describes performing calculations on the GPU. For this OpenGL needs some extensions which enable such features especially for certain harware. Since I can only use OpenGL ES, which is a subset of the full OpenGL, I doubt those extensions would work (or that there are some "ES extensions").
    So it looks I can only put numbers into the OpenGL pipeline and the results will get drawn into the display -- so I would need to read the "results" out of the pixels (somehow).

    The OpenGL-for-number-crunching is put on ice until I find a way how this actually would work.

Leave a comment

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.