Problem with glGenerateMipmap and RGB565 textures

I'm running into trouble using glGenerateMipmap on rgb565 textures, on a SGX540 (both on a Nexus S and a 7" Samsung Galaxy Tab 2). The image contents can still be recognized, but the color values are hopelessly messed up. The same code works fine on devices with Mali-400 and Tegra2 gpu's. Also 24bit RGB textures are not a problem on the SGX540.

Are there any known problems with using glGenerateMipmap on rgb565 textures? 

The Nexus S runs on Android 4.0.4, the Tab2 on 4.0.3.

Edit: the exact same build works fine on an older 7" Galaxy Tab, also with a SGX540 (Android 2.3.6)

svdree2012-06-06 15:13:29


Can you share a binary that reproduces the issue with us? If you do not want to share this publicly, you can send it to


I created a small Android app that exhibits the same behaviour on all the devices mentioned above, and put it in my public dropbox folder (the .apk file). The source is also there (mipmaptest.tgz), as well as 2 screenshots showing the effect that I get. The image should show a solid blue square, with a circle that has a gradient between 2 shades of blue.

It's interesting to note that the solid blue color gets mipmapped OK, while the gradient has problems.

Hope this helps, I'm really curious what's going on here.

Thanks for taking the time to look at it!


Sorry for the delay. I’ve ran the binary on a Nexus S and Galaxy S I have, but neither have shown the artefacts you’d mentioned when zooming using the test’s slider. Here’s some information about these two devices:

* Nexus S - 2.3.1 [SGX driver]
* Galaxy S - 2.3.3 [SGX driver]


thanks for looking into it. As I mentioned, I’ve also seen it work correctly on devices with slightly older firmware. The mentioned effect can definitely be seen on a Nexus S with Android 4.0.4, GL_VERSION string = “OpenGL ES 2.0 build 1.8@785978”


I’ve now ran your test on a Galaxy Nexus and been able to reproduce the issue:

* Galaxy Nexus - 4.0.4 [SGX driver 1.8@785978]

I’ve informed our driver team of this problem. I believe this problem is specific to this 1.8 driver. Future drivers should no longer have this problem. As a workaround, can you check the GL_VERSION string for this driver number and use a 24 bit texture if a 1.8 driver is detected?

Thanks for the confirmation. We’ve worked around it by implementing our own mipmap generation routine for rgb565 textures, so it’s not a big issue for us. Just wanted to let you know.

Ah, ok. Glad to hear you already have a work around :slight_smile: