How to handle wildly varying rendering hardware / getting baseline

Question

I've recently started with mobile programming (cross-platform, also with desktop) and am encountering wildly differing hardware performance, in particular with OpenGL and the GPU. I know I'll basically have to adjust my rendering code but I'm uncertain of how to detect performance and what reasonable default settings are.

I notice that certain shader functions are basically free in a desktop implemenation but can be unusable in a mobile device. The problem is I have no way of knowing what features will cause what performance issues on all the devices. So my first issue is that even if I allow configuring options I'm uncertain of which options I have to make configurable. I'm wondering also wheher one just writes one very configurable pipeline, or whether I should have 2 distinct options (high/low).

I'm also unsure of where to set the default. If I set to the poorest performer the graphics will be so minimal that any user with a modern device would dismiss the game. If I set them even at some moderate point, the low end devices will basically become a slide-show. I was thinking perhaps that I just run some benchmarks when the user first installs and randomly guess what works, but I've not see a game do this before.

Answer 1

Depending on what you're aiming for, you have several options.

Best quality on every device? Make a separate version, optimized by hand for every single device separately.

Least amount of work? Find the crappiest device you want to support, develop for that, and port that around.

There's no magic way to detect the performance, but you can investigate the characteristics of various devices; how many pixel/texel pipes, how many shader cores, and so on. You'll find that while the desktop hardware has ludicrous amounts of shader cores and texel/pixel bandwidth, the mobile devices are genrally very, very constricted (some have as few as one shader core =)

EDIT: that said, there's some stuff you can do, like quality settings, and benchmarks, but don't expect desktop content to run on a phone (not yet, at least..)

Answer 2

I've done this professionally. For about a year, I was the guy responsible for managing rendering performance for a single "AAA" 3D game across almost the complete line of iOS devices.

I want to stress this: for the duration of the development of the game, this was exactly all of my job. I did this 8-10 hours per day, five days a week, for a year. I wasn't implementing the game (apart from some shaders); I was only maintaining and tuning rendering performance across a broad set of devices.

This is my way of saying: it's not easy. It takes a serious investment of time to really maintain compatibility across a wide range of devices.

The way that I did it was to build a series of in-game graphic testbeds. Things like level flythroughs, animation tests, and so on. These tests would run, and the devices would log out statistics about how long things took to render, how long they took to process, etc. I'd run these tests on about six different devices every day, as development continued. And then I'd graph these blobs of data, so I could compare how long something took to render on an iPhone3 vs. an iPhone 3GS vs. an iPhone4 vs. an iPhone4S, and I'd have to figure out how to make the iPhone4 run as fast as the 3GS, and how to boost the speed of the 3, and so on. I did research to figure out exactly what operations were slow on each device, so that I could make custom rendering changes for each model.

Often this meant using different shaders. Or disabling shaders entirely. Or tuning the far clip distance or being more or less aggressive in occlusion testing or anything else I could think of to boost performance on the slower devices. And after every change, I'd run the suite of tests again, to see if the change I'd made had actually had the effect I expected it to. It was a slow, laborious process, and required a lot of attention to avoid making mistakes and making things worse.

Incidentally, the other developers loved these graphs; they immediately showed on which days somebody had done something that hurt performance, which meant that we didn't have the usual last-minute crunching to find performance, since we (mostly) caught everything within a day or so of it going in.

In terms of pipeline, I used two separate pipelines; one which used shaders, and one which used the fixed-function pipeline. I'm not sure if I recommend that these days, but it's what I did. (The fixed-function pipeline, in my case, was legacy code which already existed. The shader pipeline was new. I don't think I'd bother writing a fixed-function pipeline from scratch, today, unless I really needed to support something that didn't have shader support.)

The device-specific changes were all placed in game code and in data files, not in the pipeline (so an iPhone4 would load a simpler shader than an iPhone4S would, for example, and an iPhone3 would move to lower LODs at a closer distance, etc), but they'd all be rendering through either the shader pipeline or the fixed-function pipeline, neither of which cared about the particular device they were running on.

Answer 3

You've pretty much identified the reason why - for most people in your position - aiming to support all hardware and all platforms is not a realistic objective. It's a noble objective, it's commendable, but - unless you have the time and resources and are willing to make sacrifices - not realistic.

If you've just started mobile development then I'd suggest that you have way more important things to be spending your time doing, and trying to get reasonable performance and good quality while dealing with all the quirks of each platform is just going to suck that precious time away from you.

So I'd advise to pick a single platform for the first project, focus on that, and learn mobile development on that platform. Much of what you learn will be easily transferrable to other platforms at a later date, but - crucially - you won't need to deal with the headache of supporting multiple platforms while you're learning.

Once you have that down you can look to adding support for other platforms if you want, but view it as a value-added bonus rather than a core requirement. At this stage. Future projects can be more ambitious, but for that first project your objective is to learn, not to be all things to all people.