In theory checking the GL_VERSION supported by your driver and cross-checking that with the appropriate GL specification should tell you what you need.

In practice OpenGL itself makes no guarantee that any given feature is going to be hardware accelerated. It's perfectly legal for a driver to advertise a feature and have full support for it, but to drop you back to a software emulated path if you actually try to use it.

OpenGL gives you absolutely no way of knowing if this is going to happen, and if you drop back to software emulation per-vertex you may not even notice it - it will be slower but it may not be sufficiently slow for you to clearly determine if it's a software fallback or if it's just a more generic performance issue in your own code.

If you drop back to software emulation at a deeper part of the pipeline - per fragment or in the blend stage - you'll almost definitely notice it because you'll be getting about 1 fps.

The only way to satisfactorily know this is to know which features do or don't play well with current hardware and any previous generations you want to support. For example, some of the earliest GL 2.0 hardware (from 10 years ago now, so you almost definitely don't want to support it, but it's useful to cite as an example) advertised support for non-power-of-two textures but only supported them in a software emulated path, so it's hello to 1 fps.

A rule of thumb might be to only rely on a feature being hardware accelerated if it's from a GL_VERSION or two below what the driver advertises, but that's obviously also a (fairly heavy-handed) constraint - most features are actually perfectly OK, but it's those handful that cause trouble that you need to watch out for.

In practice OpenGL itself makes no guarantee that any given feature is going to be hardware accelerated

Can you force OpenGL to only use hardware accelerated features? If you can how is this done?

In practice OpenGL itself makes no guarantee that any given feature is going to be hardware accelerated. It's perfectly legal for a driver to advertise a feature and have full support for it, but to drop you back to a software emulated path if you actually try to use it.

In practice OpenGL itself makes no guarantee that any given feature is going to be hardware accelerated. It's perfectly legal for a driver to advertise a feature and have full support for it, but to drop you back to a software emulated path if you actually try to use it.

Do you know of any concrete example of an implementation that provides an OpenGL 3.2+ core context but it emulates some features in software? I keep hearing this, yet while being true in the spec, isn't followed by examples of situations in which it happened.

Not 3.2, but on 2.1 I used dynamic indexing of an array of uniform variables inside a fragment shader, and my FPS dropped from 60 to 1 -- a sure sign that the driver has reverted to software emulation

but I haven't seen a GL implementation that fallbacks to software rendering in quite a long time.

iOS partially does in certain circumstances, such as when attributes in a vertex buffer are misaligned.
I say “partially” because it isn’t emulating the full rendering pipeline, it just adds a huge CPU cost because it manually, on the CPU, makes an aligned copy of the vertex data every frame, and basically causes a drastic change in performance without giving you a clue that it is doing it, making it basically the same problem as going into emulation mode (nothing on iOS is fully emulated—it either is hardware accelerated or it fails).

In my own engine for desktop OpenGL 3.3/4.5, I suspect I’ve hit a slow path unknowingly too.

I’ve been very careful with its development and putting in a lot of effort to make sure the OpenGL ports run as close to the performance of Direct3D 11 as they can, and until last week I was at roughly 80-90%.

Suddenly after getting some new models for play-testing Direct3D 9 and Direct3D 11 are around 11,000 and 14,000 FPS respectively, whereas OpenGL dropped to 400 FPS.

I intend to allocate some time to investigate this in detail this weekend, but basically while full-on emulation is rare these days, there are still a million cases that cause it to do unnecessary CPU work.

L. Spiro

Not 3.2, but on 2.1 I used dynamic indexing of an array of uniform variables inside a fragment shader, and my FPS dropped from 60 to 1 -- a sure sign that the driver has reverted to software emulation

Of course but I asked for OpenGL 3 hardware examples for a reason, as to raise the point that this complaint keeps coming up. It seems as if OpenGL users are like the ARB, holding onto the past too much

In any case, knowing if feature X is emulated in Y cards is good knowledge to have, which is also why I asked.

iOS partially does in certain circumstances, such as when attributes in a vertex buffer are misaligned.

ie, not aligned to 16 bytes? ES 2? I've seen thrown around that explicit 16 byte alignment is good for some desktop hardware too, AMD cards apparently. I'm assuming if you're using another API (Mantle? ES 3?) you'd have to do proper alignment in any case.

ie, not aligned to 16 bytes?

Not aligned according to the guidelines here.

At least that page mentions the extra work that needs to be done. For every other OpenGL * implementation you are just guessing.

L. Spiro