Back on topic, and regarding performance, one of the often overlooked differences between the two APIs is that OpenGL allows semi-arbitrary software fallbacks whereas D3D does not. This is a fairly important distinction - with OpenGL a glDrawElements call (for example) is not allowed to fail, it's not specified to fail, and if the parameters supplied for the call (or for any of the setup required to make the call) exceed hardware capabilities (but while still being within the capabilities exposed by the driver) then it must be emulated in software. Compare to D3D where you get what's available on the hardware and nothing else; that means that you may have a lot more work to do in order to ensure that you fit within those capabilities, but once you do that you know that your call will work and will not fall back.

There are perfectly valid arguments to be made for and against both design philosophies and I'm not going to make judgement for or against either here.

Regarding the original question - on another viewing it doesn't actually make any sense because it seems to come from the assumption that OpenGL is some form of pure software library. Ummm, no, it's not. OpenGL is a software interface to graphics hardware (page 1, line 1 of any OpenGL spec) and it's still the graphics hardware that is the ultimate arbiter of performance. It's also the case that an OpenGL ICD is a full replacement for Microsoft's software implementation, so those OpenGL calls you make - they're being made to the graphics hardware vendor's implementation, not to anything provided by Microsoft. If there are performance issues then take it up with your GL_VENDOR in the first instance.

Sony is using DirectX 11 for the PS4? Is that rumour or unreleased insider knowledge? If the latter, don't risk breaking any NDAs.

The only reports I can find on the matter is this rumor (from eight months ago), which was later corrected by another rumor to say the PS4 will be running OpenGL natively.

Generally speaking, console graphics APIs never exactly match desktop graphics APIs.
Because each console is built using a specific GPU from a specific vendor, the actual API used to control the GPU is usually written by that vendor (at at least in cooperation with them). This means the API may be based on a desktop API, and might end up being very similar to one, but it's going to be a lot simpler, and allow much lower level control due to it only targeting a single hardware spec.
Often functions that are implemented inside the driver on the PC, like the VRAM allocator, can (or must) be implemented in the game-engine.

Another (hypothetical) way to look at it --
MS builds the D3D11 API, and nVidia then has to write drivers that implement this API for each of their specific GPUs.
nVidia then sells a particular GPU to a console maker, who also needs a graphics API. nVidia ports their driver code to that console, with that code becomming the console's graphics API, which is going to end up looking quite similar to either D3D11 or GL4.

It may be faster in the exact specific way that Valve's (aging) engine architecture could benefit from, or those specific video cards they were testing from, but that doesn't mean OpenGL is faster than DirectX in general. Part of the speed gain they even hinted was from Linux vs Windows and not OpenGL vs DirectX specifically, and the difference between 3.30 and 3.17 milliseconds per frame is only 0.13 milliseconds.

Being that they both are different ways of accessing the same videocard, and neither does alot of heavy processing themselves, they should both be fairly close in speed.

Somebody in another forum tried to explain it, according to him OpenGL is somewhat more loose than Direct3D when it comes to resource management which could allow the driver to make some more optimizations. Never used Direct3D so I can't tell. Then again, it was Nvidia hardware Valve was using for testing, and Nvidia loves OpenGL. Make what you want out of it =P

The sad thing though is that apparently Valve was just using a Direct3D wrapper (ala Wine). Ouch if this is the case, that'd mean emulated Direct3D is faster than Direct3D itself...

There is a whole load of nonsense and barely-informed FUD (in both the computing acronym and Glasgow vernacular senses of the word) on both sides of this particular argument. The truth is that Microsoft wanted OpenGL; they wanted it to be good, they wanted it to run fast, they wanted it to run well - because they wanted to break into the CAD workstation market (games development ain't everything). The problem was that they also wanted D3D, but that wasn't because of any evil conspiracy; it was because MS are (or were at the time) a fairly fragmented company where the left hand doesn't (or didn't at the time) even know what the right hand was doing.

Windows NT team vs. Windows 95 team? Because I had heard it had to do with something like that (with the Windows NT team not wanting to give back their OpenGL code to the Windows 95 team). I never found any reliable sources though so I'd rather call it FUD for now.

Honestly, it'd be wrong to even use the results they got as a comparison when the proper way to use OpenGL would be to rewrite the code from scratch rather than faking Direct3D, and some engines already had their own OpenGL pipelines since the beginning. Also you have to take into account the hardware they used... pretty sure OpenGL suffers a lot on AMD hardware (they don't care as much about it). For a proper test usually you use a wide range of hardware. They never said which versions of the APIs they used, either =P Direct3D 9 should only be compared to OpenGL 2.1, if they used OpenGL 3.x or 4.x the comparison probably isn't proper (since that'd be akin to D3D10 and D3D11, respectively - at least in theory...).

Also L4D may not be one of the most demanding games but the framerate is in the low hundreds (at least during that test)...

It's important to look at the development process of Valve's port.

Their initial working implementation actually ran at 6 FPS - that's not a case of "ZOMG! OpenGL Is teh slower than D3D!" - that's (as they note) "typical of an initial successful port to a new platform".

Following that they identified 3 key areas for improvement - two relating to the game itself and one relating to the driver. Of those, only the last one (that relating to the driver) is - strictly speaking - directly relevant to the OpenGL vs D3D performance question, but that would be assuming that all other things are equal, and of course the game's use of the API is also a huge factor.

Working with the hardware vendors on resolving these, as well as fixing up the game's use of the API, gave the end result, following which they again noted that "it comes down to a few additional microseconds overhead per batch in Direct3D which does not affect OpenGL on Windows" - so the specific reason for the performance difference was identified, and it was isolated to one very specific difference between the two APIs; this is quite clearly not a case "my API is faster than your API" but rather a case of "this one part of my API, in the way we use it for this one particular game, on this one particular hardware configuration, is faster than the corresponding one part of your API in the same circumstances".

That's about as far from a meaningful scientific comparison as it's possible to get.

In actual fact, well-coded OpenGL will always smoke poorly-coded D3D, just as well-coded D3D will likewise smoke poorly-coded OpenGL. I'm not saying that Valve's D3D code is poor (I'd expect it to be close enough to the best D3D code on the planet), but it is still using an ancient version of the API which - guess what - is widely recognized to have more overhead in exactly the area that Valve noted. And that would be an expected result for any code that particularly stresses that particular area. So the end result actually does nothing more than confirm what we already knew! Wowsers!

A more detailed breakdown of performance comparisons between different parts of each renderer would be expected to see D3D pulling ahead in some areas but GL pulling ahead in others. If they're doing any dynamic vertex buffer updates, for example, then - assuming a GL2.0/2.1 baseline - I'd expect to see D3D doing those faster than the GL code.

Finally, it's necessary to note Valve's conclusion: "now that we know the hardware is capable of more performance, we will go back and figure out how to mitigate this effect under Direct3D." Again, this is not a case of "my API is faster than your API", this is instead a recognition that their own use of D3D may have room for further performance improvment and that a mitigation of the identified bottleneck may see D3D pulling ahead again.

Like they said at the very start: "performance is a complicated issue".

All references: http://blogs.valvesoftware.com/linux/faster-zombies/