I'm working on a OpenGL ES3 app for Android: for various reasons, I decided to roll my own mini-OpenGL rendering engine. So far so good.

Problem is, the GPU drivers in the mobile industry are such sad things, that dire bugs keep appearing with the most innocent actions.

For example: yesterday I added a point to my scene (you know: the kind with 3 coordinates, plus a mat4 for the projection matrix) and I got the following results:

  • everything fine on a Samsung S4
  • black screen with ANR on my Nexus 5
  • hard freeze and reboot on my Nexus 7 (way to go, Qualcomm!)

I admit I use a number of not so common stuff in my rendering engine (the tougher probably being MRT), but we are still talking about features in the OpenGL ES 3 specification.

So the question is: how do you deal with this state of affair? Are there techniques that will minimise the risk of incompatibilities? Does the OpenGL ES 3 (and 2 since we are at it...) specification contains features better not using?

Mind that this is not the first time I stumble on problems like this (earlier during development I had a bug triggered by the GL_TEXTURE_EXTERNAL_OES OpenGL ES2 extension that actually forced me to do a pre-rendering pass, just to avoid getting a purple screen...), and this is turning the whole development into a quite anxiety-provoking experience.

Thank you for any advice!


1 Answer 1


Well, you have it easy. There's only a few hundred models available, with probably a few dozen representative configurations. It's not like most people build their own smartphones, like with custom PCs where you can have trillions of different configurations.

There's no way around this. Drivers are buggy, and you can either complain or act on that.

Generally speaking, what you want to do is test a lot, especially in the early stages where you're still building your engine. Try to base your game on the most basic features, and leave the functionality that requires the more obscure features optional.

For example, make your game with a single render target. If some of your effects can be enhanced with multiple render targets, then use that on devices that you know support that, but don't make it mandatory for the feature to work, because you will spend all your time looking for workarounds for each different configuration.

Really, there's no way around this. That's the path you chose when you started making your own engine. If you dislike this, you will probably have a more enjoyable time using a third party engine.

  • \$\begingroup\$ Thank you for your answer and point of view (and, well... yes, I was whining a little bit)! Following your arguments, you are right: it's probably not so bad (though admit that freezing solid a device because you draw a point, or turning a screen purple because you inverted a variable order is quote off, even by PC standards... :) ). I'll wait for someone to post a semi-comprehensive list of "dangerous" stuff not to use, or accept your answer. \$\endgroup\$
    – R1ck77
    Commented Jun 26, 2015 at 9:22
  • \$\begingroup\$ I'll also hold on your suggestion about keeping the advanced effects/features on a separate tab (thanks!) \$\endgroup\$
    – R1ck77
    Commented Jun 26, 2015 at 9:24
  • \$\begingroup\$ @R1ck77: I would like to see such a list myself, and I would start with this issue I ran into myself. However, I wouldn't be so optimistic. Most developers who do plain OpenGL/DirectX are doing really basic stuff, and those who do advanced stuff most likely use engines that abstract the boilerplate stuff away. People like you (and me) are not very common, at least on this site. \$\endgroup\$ Commented Jun 26, 2015 at 9:57
  • \$\begingroup\$ I have cursory read your question (we are in very different leagues about graphic programming: I just got started...), but I still understood the problem. What hits me as particularly alarming is how the driver failed at something so basic (I mean: skinning is not basic, but accessing a uniform is), which makes getting the graphics right more a matter of luck, than testing (works -> add a point/invert variable -> boom!). Is it just me, or Qualcomm specifically sucks big time? Anyway, I wish you luck for your problem! \$\endgroup\$
    – R1ck77
    Commented Jun 26, 2015 at 10:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .