No clue what multicore rendering D3D offers, but 'complete lack' is an overstatement.

OpenGL has context sharing, which means several contexts in different threads sharing the same objects. You can issue commands as long as you synchronise access to objects yourself. In practice, that means filling buffers, rendering to an off-screen framebuffer, etc. from other threads.

Multithreading in GL does not work consistently. If you ask the driver vendors (AMD, NVIDIA, etc) they will tell you it doesn't work at all or across platforms. If you ask engine developers (like Valve) they will tell you in talks that it doesn't work across platforms.

What's cross platform? I guess what matters in this specific argument is feature parity with D3D on all the platforms it can compete on.

If it works on Windows, then I wonder if it really matters. I've seen a lot of games (e.g. Team Fortress 2) still offer multithreading as an option in the UI, so there's already two code paths there.

I have been told by driver vendors that GL multithreading does not work on windows, yes.

D3D multithreading works (even, to a lesser extent, with D3D9!), and this is one of the reasons why our D3D9 renderer is dramatically faster than our GL one - we can offload a subset of rendering work to helper threads instead of keeping it all locked on the thread that owns the window.

TF2/etc do offer a multithreaded rendering option, but IIRC on Windows their engine still uses D3D. Also, note that it's an option, because the feature used to be very unstable (still might be, actually) - I suspect people using the GL version of those games may have to disable it on certain hardware/driver configurations.

As mentioned in the other comments it's not consistent nor always supported. And you can do the multithreading only by sharing already rendered fbo's.

In D3D it works as OpenGL display lists would, except with arbitrary commands. So you have multiple threads composing the scene and then a single thread just issues few commands to replay the command buffers created by the other threads.

It would be rather simple to implement the same in OpenGL as we already have the display list concept, even if it originally was made to reduce the amount of glvertex3f calls.

"complete lack" was maybe bit of an exaggeration, however in practice it is true.

I figure you're talking about DX11's multithreaded submission? While it's true that GL doesn't have support for this yet. AFAIK, DX's implementation is very slow, and all the major engine developers end up implementing their own batched dispatch anyways which ends up being faster on PC.