[pjmlp]

> But no matter how you slice it if you want to support multiple graphics APIs you do have to pay a tax in doing the QA and possibly custom development for each one.

Because the portability of APIs like OpenGL only happens in theory when you restrain yourself to a specific set of hardware.

The combinatory explosion of vendor extensions, driver bugs, shading language differences across versions and drivers, differences between OpenGL and OpenGL ES, force any studio that wants to keep sanity in their code, to write an OpenGL adaption layer anyway.

So if one if forced to write an adaptation layer anyway, then better go for the API that properly exposes all hardware features with less bugs and better tooling support.

This is one reason that while there are third party OpenGL wrappers to game consoles, or even first party ones like on the PS3, no one bothers to use them.

Taking the PS3 as an example, OpenGL ES doesn't define how to take advantage of the SPUs, other than via extensions anyway, thus making the code PS3 specific even if OpenGL ES is being use.

While at the same time less performant than the PS3 native API due to the OpenGL ES driver semantics.

[shmerl]

All this assumes, you need to use non portable extensions every time. It could be reasonable in the past, it's way less reasonable today. And using a whole different API is surely more complex, than adapting usage of portable API to differences of potential targets, depending on features which they support.

It's pretty easy to check what's supported by the driver and decide whether to use some optional feature.