• Locked Locked
  • Replies 7 replies
  • Subscribers 136 subscribers
  • Views 8252 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Dithering on SGS2/Mali400MP

Peter Strand
Note: This was originally posted on 19th June 2011 at http://forums.arm.com

Hi,

I was just investigating a color banding issue in a gles2 application on Samsung Galaxy S II and noticed that GL_DITHER was disabled by default, and could not be enabled either.
Is this a known problem? Intentional? Driver or android/platform issue?

Regards,
Peter
  • Note: This was originally posted on 20th June 2011 at http://forums.arm.com

    Hi Peter,

    strange - I see a different result here. I modified a simple example to do this in the setup:


    GLboolean bDither = GL_CHECK(glIsEnabled(GL_DITHER));
    LOGD("glIsEnabled(GL_DITHER) = %i\n", bDither);

    GL_CHECK(glDisable(GL_DITHER));
    LOGD("glDisable(GL_DITHER)\n");

    bDither = GL_CHECK(glIsEnabled(GL_DITHER));
    LOGD("glIsEnabled(GL_DITHER) = %i\n", bDither);

    GL_CHECK(glEnable(GL_DITHER));
    LOGD("glEnable(GL_DITHER)\n");

    bDither = GL_CHECK(glIsEnabled(GL_DITHER));
    LOGD("glIsEnabled(GL_DITHER) = %i\n", bDither);


    When I run this on my S2 I see this output:

    06-20 12:02:01.840: DEBUG/Mali  Simple Examples(25391): glIsEnabled(GL_DITHER) = 1
    06-20 12:02:01.840: DEBUG/Mali  Simple Examples(25391): glDisable(GL_DITHER)
    06-20 12:02:01.840: DEBUG/Mali  Simple Examples(25391): glIsEnabled(GL_DITHER) = 0
    06-20 12:02:01.840: DEBUG/Mali  Simple Examples(25391): glEnable(GL_DITHER)
    06-20 12:02:01.840: DEBUG/Mali  Simple Examples(25391): glIsEnabled(GL_DITHER) = 1

    My S2 reports this:

    Model number: GT-I9100
    Android version: 2.3.3
    Baseband version: I9100XXKDJ
    Kernel version: 2.6.35.7-I9100XWKE2-CL187606 root@DELL101 #2
    Build number: GINGERBREAD.XWKE2

    What is your setup? Cheers, Pete
  • Note: This was originally posted on 20th June 2011 at http://forums.arm.com

    I used glGetBooleanv (and glGetIntegerv) to query the state, glIsEnabled does indeed return 1.
    And I noticed that glGet doesn't return zero which I thought, they don't touch my parameter at all..
    (shouldn't glGet work for state queries as well as glIsEnabled?)

    However, the result in the framebuffer looks undithered, which is my real problem to begin with.

    I have exactly the same version of the S2 as you.



    Here is a small test application:


    (prebuilt debug-apk in bin/SimpleGL.apk)
    It displays smooth (dithered) gradients on Adreno and SGX. Undithered on Mali.


    /Peter
  • Note: This was originally posted on 20th June 2011 at http://forums.arm.com

    Hi Peter,

    OK I have looked into this and I have a workaround but I need to investigate further.

    Even with the app as it is, I do see dithering between colour levels in screenshots from DDMS:



    Though I agree, the colour banding is very clear.

    My suspicion is that on other platforms you are requesting RGB565 but getting a higher colour depth returned. The EGL spec allows this, as does Android's setEGLConfigChooser() method.

    Leaving the request at 565 but modifying the onCreate() method in SimpleGL.java:


    glView = new GLView(this);
    glView.getHolder().setFormat(PixelFormat.RGBA_8888); // Gives smooth gradient.
    setContentView(glView);


    Taking a screenshot via DDMS I now see smooth shading whilst still seeing dithering (though it's much harder to see, may need to zoom in):



    The logcat output remains the same:

    06-20 14:40:02.120: INFO/nena(1579): onCreate()
    06-20 14:40:02.130: INFO/GLThread(1579): starting tid=10
    06-20 14:40:02.270: INFO/(1579): !@Mali Android API Version : 7 [1308577202]
    06-20 14:40:02.305: INFO/ActivityManager(2701): Displayed se.nena.simplegl/.SimpleGL: +244ms
    06-20 14:40:02.335: INFO/nena(1579): initializeGL()
    06-20 14:40:02.335: INFO/nena(1579): Bits: RGB565 A0 [dither false true]
    06-20 14:40:02.345: INFO/nena(1579): Vertex:
    06-20 14:40:02.345: INFO/nena(1579): Fragment:
    06-20 14:40:02.345: INFO/nena(1579): Program:
    06-20 14:40:02.345: INFO/nena(1579): Locations 0 1
    06-20 14:40:02.345: INFO/nena(1579): onSurfaceChanged 480x724

    I still need to investigate whether this addition is correct and necessary, and also your point about glGet() but in the meantime, does this change produce the same results across platforms for you?

    Cheers, Pete
  • Note: This was originally posted on 20th June 2011 at http://forums.arm.com


    Hi Peter,

    OK I have looked into this and I have a workaround but I need to investigate further.

    Even with the app as it is, I do see dithering between colour levels in screenshots from DDMS:

    Ah, yes, I also se a very subtle dithering now when I run my sample app. Not sure how I missed it before...


    My suspicion is that on other platforms you are requesting RGB565 but getting a higher colour depth returned. The EGL spec allows this, as does Android's setEGLConfigChooser() method.

    Is it possible to trust glGet(GL_XXX_BITS) to give the actual depth of the buffer, rather than the requested?
    (It suggests that I get RGB565 everywhere when I request that from EGL, regardless of the PixelFormat)

    I'll make the egl selection more specific and see what difference that makes..

    Anyway, I definitely see dithering on other platforms.
    Here's a crop from a HTC Desire:




    Leaving the request at 565 but modifying the onCreate() method in SimpleGL.java:


    glView = new GLView(this);
    glView.getHolder().setFormat(PixelFormat.RGBA_8888); // Gives smooth gradient.
    setContentView(glView);


    I still need to investigate whether this addition is correct and necessary, and also your point about glGet() but in the meantime, does this change produce the same results across platforms for you?


    This produces much better results on Mali, and it seems to use the full 888 depth while still subtly dither.
    (at least when looking at gradients)

    On adreno and sgx I get the same result as with a 565 surfaceview (i.e. approx. 565 resolution and strong dither).


    What happens under the surface in this case? Android gives you a 32-bit surface but you render with 16-bit precision and dither - how does that compare performance-wise to just run with 888?

    /Peter
  • Note: This was originally posted on 22nd June 2011 at http://forums.arm.com

    Hi Peter,


    I used glGetBooleanv (and glGetIntegerv) to query the state, glIsEnabled does indeed return 1.
    And I noticed that glGet doesn't return zero which I thought, they don't touch my parameter at all..
    (shouldn't glGet work for state queries as well as glIsEnabled?)


    I have investigated this part of your question further and I think you may be right. It appears GLES1.x didn't have a glGet() for GL_DITHER but GLES2.0 does - since you have a GLES2.0 context, the glGet() function should work for GL_DITHER I believe. We will investigate this issue further.

    Thanks, Pete
  • Note: This was originally posted on 12th July 2011 at http://forums.arm.com

    Since i bought SGSII i never seen normal 24 bit colors on it, like it is on any other device. Alvays there is that horrible banding. Does Mali 400 capable to produce 24 bit picture anyhow?
  • Note: This was originally posted on 12th July 2011 at http://forums.arm.com

    Hi,

    yes Mali-400 supports many color modes including 16-bit, 24-bit and 32-bit.

    if you select an RGB888 EGL config in the GLSurfaceView's constructor method:

    setEGLConfigChooser(8, 8, 8, 0, 0, 0);

    and set the pixel format in the Activity's onCreate() method:

    glView = new GLView(this);
    glView.getHolder().setFormat(PixelFormat.RGBA_8888);
    setContentView(glView);


    then you should get a 24-bit color surface for your 3D application.

    HTH, Pete