Dealing with OpenGL ES 2.0 driver bugs

Question

I'm currently porting a 3D C++ game from iOS to Android using NDK. The rendering is done with GLES2. When I finished rewriting all the platform specific stuff and ran the full game for the first time I noticed rendering bugs - sometimes only parts of the geometry would render, sometimes huge triangles would flicker across the screen, and so on and so on...

I tested it on a Galaxy Nexus running 4.1.2. glGetError() returned nothing. Also, the game ran beautifully on all iOS devices. I started suspecting a driver bug and after hunting for many hours I found out that using VAOs (GL_OES_vertex_array_object) caused the trouble. The same renderer worked fine without VAOs and produced rubbish with VAOs.

I found this bug report at Google Code. Also I saw the same report at IMG forums and a staff member confirmed that it's indeed a driver bug.

All this made me think - how do I handle cases of confirmed driver bugs? I see 2 options:

1. Not using VAOs on Android devices.
2. Blacklisting specific devices and driver revisions, and not using VAOs on these devices.

I don't like both options.
Option number 1 will punish all users who have a good driver. VAOs really boost performance and I think it's a really bad thing to ignore them because one device has a bug.
Option number 2 is pretty hard to do right. I can't test every Android device for broken drivers and I expect the list to constantly change, making it hard to keep up.

Any suggestions? Is there perhaps a way to detect such driver bugs at runtime without testing every device manually?

Answer 1

Bugs in OpenGL ES drivers on Android is a well-known thing, so it is entirely possible to have a bug in a driver. Especially if you are using some advanced (not-so-well-tested) features like GL extensions.

In a large Android project we usually fight this issues using the following checklist:

1. Test and debug our own code thoroughly and check against OpenGL specifications to make sure we are not doing any API-misuses.
2. Google for the problem (!!!)
3. Contact the chip-set vendor (usually they have a form on their website to submit bugs from developers, but once you have submitted 2-3 real bugs successfully you will know the direct emails of people who can help) and show them your code. Sometimes they find bugs in the driver, sometimes they find API-misuse...
4. If the feature doesn't work on a couple of devices, just create a workaround or fallback to a traditional rendering path.
5. If the feature is not supported by the majority of the top-notch devices - just don't use it, you will be able to add it later once the market is ready for it.