1

I have created an android app for drawing of lines,circles.. by using GLSurfaceView in OpenGLES 2.0 like an Auto cad app.

The app works well with Google Nexus 7, in the sense that if we draw a line & then a circle the line doesn't get erased in surface view. But with Samsung Galaxy Note II, it is entirely different.

The line previously drawn before a circle being drawn, gets erased. i.e., each time if we draw a new line or circle, the previous one gets erased.I can draw only one image at a time. What I need is the same output which I get in Google Nexus 7 in Samsung Galaxy Note II.i.e.I want to draw more than one image in the GLSurfaceView at a time.

Note : Both the Android OS in Google Nexus 7 and Samsung Galaxy Note II are Jelly Bean 4.2. But both devices are different GPU. Google Nexus 7 GPU is ULP GeForce & Samsung Galaxy Note II is Mali400MP.

Would this be an issue in the rendering of output of the Surfaceview ?

Should we take into account of GPU while Coding ?

Can anyone tell me why this problem of different output in different devices ?

genpfault
  • 51,148
  • 11
  • 85
  • 139
deiva
  • 127
  • 6

2 Answers2

4

Should we take into account of GPU while Coding ? No way, The OpenGL API is a layer between your application and the hardware.

This is largely correct for desktop graphics as all GPUs are immediate renderers, however, this is NOT the case in mobile graphics.

The Mali GPUs use tile-based immediate-mode rendering. For this type of rendering, the framebuffer is divided into tiles of size 16 by 16 pixels. The Polygon List Builder (PLB) organizes input data from the application into polygon lists. There is a polygon list for each tile. When a primitive covers part of a tile, an entry, called a polygon list command, is added to the polygon list for the tile. The pixel processor takes the polygon list for one tile and computes values for all pixels in that tile before starting work on the next tile. Because this tile-based approach uses a fast, on-chip tile buffer, the GPU only writes the tile buffer contents to the framebuffer in main memory at the end of each tile. Non-tiled-based, immediate-mode renderers generally require many more framebuffer accesses. The tile-based method therefore consumes less memory bandwidth, and supports operations such as depth testing, blending and anti-aliasing efficiently.

Another difference is the treatment of rendered buffers. Immediate renderers will "save" the content of your buffer, effectively allowing you to only draw differences in the rendered scene on top of what previously existed. This IS available in Mali, however, is not enabled by default as it can cause undesired effects if used incorrectly.

There is a Mali GLES2 SDK example on how to use "EGL Preserve" Correctly available in the GLES2 SDK here

The reason the Geforce ULP based nexus 7 works as intended is that, as an immediate based renderer, it defaults to preserving the buffers, whereas Mali does not.

From the Khronos EGL specification:

EGL_SWAP_BEHAVIOR

Specifies the effect on the color buffer of posting a surface with eglSwapBuffers. A value of EGL_BUFFER_PRESERVED indicates that color buffer contents are unaffected, while EGL_BUFFER_DESTROYED indicates that color buffer contents may be destroyed or changed by the operation.

*The initial value of EGL_SWAP_BEHAVIOR is chosen by the implementation.*

The default value for EGL_SWAP_BEHAVIOUR on the Mali platform is EGL_BUFFER_DESTROYED. This is due to the performance hit associated with having to fetch the previous buffer from memory before rendering the new frame, and storing it at the end as well as the consumption of bandwidth (which is also incredibly bad for battery life on mobile devices). I am unable to comment with certainty as to the default behavior of the Tegra SoCs however, it is apparent to me that their default is EGL_BUFFER_PRESERVED.

To clarify Mali's position with regards to the Khronos GLES specifications - Mali is fully compliant.

rcbevans
  • 7,101
  • 4
  • 30
  • 46
  • thanks for the aportation! I will study a bit deeper these difference. – Adrian Maire Jul 15 '13 at 11:56
  • OpenGL is an API, that is, a specification. If a hardware implement OpenGL, you should be able to use your code (if well done) on every one of them without changing anithing, that is the point of standards. As you explain in your answer, Mali seem to implement a non-standard version of OpenGl, in this case, yes, you must take it in consideration, but that is not an OpenGL problem, but a Mali problem. Am I wrong? – Adrian Maire Jul 16 '13 at 08:36
  • to clarify, we are talking about openGL ES, NOT openGL, while Mali T6XX is fully hardware compliant with the full openGL standard, the driver currently does not support it. The EGL API states the standard code that needs supporting by the hardware to be compliant, NOT the required implementation or default configuration the underlying system must use. Theoretically all code will run on all compliant platforms, but the API does not state all code will have same performance or even same rendered result. This is a casing point. I have added to my answer the Khronos spec for EGL_SWAP_BEHAVIOUR – rcbevans Jul 16 '13 at 14:02
  • Thanks you for the aclaration, 1+. – Adrian Maire Jul 17 '13 at 09:44
0

I have not seen your code, but you are probably doing something wrong. Maybe you swap the buffer, erase it, etc. where you must not.

Should we take into account of GPU while Coding ? No way, The OpenGL API is a layer between your application and the hardware.

Adrian Maire
  • 14,354
  • 9
  • 45
  • 85
  • 1
    i added my code in this blog for your understanding. http://tuxbalaji.wordpress.com/2013/06/19/draw-a-line-using-opengles2-0-by-touch-event-in-android/ But this is not the full code it is only for drawing a line.I checked my app in google nexus 7 and lava iris,it is working fine in both devices.But it is not working for samsung galaxy note II.please give your suggestions.. – deiva Jun 19 '13 at 10:48
  • Hi Adrian, My question is related to this stack overflow link(am facing same issue here). please see this and try to help me.. http://stackoverflow.com/questions/17229066/is-opengl-development-gpu-dependant/17230475?noredirect=1#17230475 – harikrishnan Jun 26 '13 at 04:59
  • Please see my answer below as to why your statement about not considering the underlying hardware does not apply in the mobile space – rcbevans Jul 15 '13 at 10:17