That doesn't mean they're wrong about OpenGL being faster than DirectX, and even if they are wrong, it doesn't mean they're being intentionally misleading. But it's important to keep our eye on the priors.

Valve (in their blog post):

"This experience lead to the question: why does an OpenGL version of our game run faster than Direct3D on Windows 7? It appears that it’s not related to multitasking overhead. We have been doing some fairly close analysis and it comes down to a few additional microseconds overhead per batch in Direct3D which does not affect OpenGL on Windows. 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."

Extreme Tech:

"As for why OpenGL is faster than DirectX/Direct3D, the simple answer is that OpenGL seems to have a smoother, more efficient pipeline. At 303.4 fps, OpenGL is rendering a frame every 3.29 milliseconds; at 270.6 fps, DirectX is rendering a frame in 3.69 milliseconds. That 0.4 millisecond difference is down to how fast the DirectX pipeline can process and draw 3D data."

In OpenGL all the fun stuff (e.g. the stuff that's in DX9+) is in vendor specific extensions.

A bit like vendor prefixes in CSS, except they can actually be implemented differently, have different names, etc. It's BAD news, and the main reason why 99% of AAA games use DirectX on Windows.

There are few things one might miss in core OpenGL 4.2. If anything any features exposed in extensions building on OGL 4.2 are so new or experimental that D3D doesn't have them at all.

You'll get hundreds of bug reports about game crashing on start.

Testing on old hardware (for <50 000 triangle games it's Intel GMA and Geforce 4 MX and some old Radeon) is a good way to be sure it works on most of computers. Of course game needs to support those old cards only on lowest quality settings.

To understand a somewhat more casual audience, it's interesting to contrast the users of Unity: http://unity3d.com/webplayer/hwstats/pages/web-2012Q1-gfxcar...

If the user's GPU doesn't support D3D 11, you have to supply a fallback.

But you have to be careful: my amateur OpenGL 3d game had problems running on half of computers, especially laptops. It's because various cards support different opengl extensions. You can't use non-power-of-two textures, can't use textures bigger than 512x512 (or other number), can't generate mipmaps automatically, can't have too big display lists.

I thought about optional DirectX renderer when running on Windows, because I've heard it's more standarized.

OpenGL is an awesome platform for those who want system portability IE minecraft, or any other indie developer who wants maximum exposure.

The question development shops would be asking themselves is: will the additional revenues provided by Linux / Mac ports of these games be enough to offset the cost of retraining their people (or hiring new people) who are prepared to do serious OpenGL development?

Moreover, many game companies are using licensed game engines. These engines may not now (or ever) support OpenGL, so the game developers themselves may not have the option to change--even if they did want to.

I'm pretty sure we're seeing that already. And WebGL is not going to improve the situation for D3D.

Make every game reinvent their own chip-level drivers? Wow. You want to run 10X faster, or slip your schedule by years?

Listening to people like Carmack, Torvalds, and others of their ilk is a good thing; but, we need to be cognizant that they are, themselves, special cases in the world of engineering and what can work well for them likely won't work well for the other 90% of the engineering world.

They imply well documented hardware and the potential to access it directly. But you can also use, and/or help improve the the higher levels of abstraction.

No, let's be honest--we'd end up with a half-dozen opinionated projects with slight overlap implementing different graphical interfaces, and another half-dozen metaprojects on top of that. Fuck. That.

Just give me a competent implementation of OpenGL or Direct3D by leading vendors who know their hardware and quirks, and be done with it.

What is changing now, is that because of the consolification of commercial OSes, there is strong commercial pressure to support linux now, just to keep an open OS. What is happening with opengl on linux now, is because of this change.

So, audio isnt a good counter example: who knows how much worse it would have been with closed source drivers.

And the problem isnt having multiple solutions/systems available: the problem is lack of a clear winner.

Companies like Valve and Canonical will be getting more dominant in picking the "winning" systems. This is true already to such an extend, companies like NVidia and AMD go out of there way to please companies like Valve. Contrast this with the kind of get-on-our-knees-and-beg relationships the linux community has had.

And Valve is arguing for opensource drivers. You should read Intels blog about their cooperation. They felt like they had to constantly remind Valve, they were preaching to the choir.

And NVidia and AMD might not give Linux much priority, but they will not let Linux ruin their relationship with the gaming industry.

The point about open drivers is continuity and integration. The HW vendors really should concern themselves with the quality. The opensource community should concern itself with adapting that support to their needs.

I want NVidia to write and maintain their driver, but i want them to publish the source. They are ones that should maintain quality: they are the ones profitting from it with hardware sales.

Audio is a really bad example, because the actual hardware is pretty much without a meaningfull profit margin, being integrated and all. And at the other side, there are few needs that reach beyond just "play this audiobuffer". I dont know who writes these systems, or what motivates them. But 99% of the needs were already fullfilled with OSS.

Thats very different from game developpers contributing to the graphics infrastructure, to fix actual problems they have.

I think you grossly overestimate the time most developers have to fix other peoples' problems, especially game developers.

In fact, I'll go out further: if you give game developers the impression that they can go look at driver code, you are opening an entire box of sadness and compulsive brittle micro-optimization that will consume a lot of man hours.

It doesn't matter about the power trip Linux people can have now that the graphics vendors are coming to them. It doesn't matter about the "freedom" to have overworked and underpaid developers muck around in driver code that frankly may exceed what they are competent at doing. It doesn't even matter that the open-source community can now second-guess and snarf about shitty vendor driver code.

What matters is that this innocent little idea could do very, very bad things to developers. "It Just Works, don't worry" is a solid reassurance, and having my game fail because some neckbearded jackass decides to recompile the Nvidia sources but-oh-so-different and push it upstream is unacceptable.

This is a bad idea.

And, for chrissakes, let's start small. How about you give me a stable ABI to program against, and we'll take it from there? Baby steps.

http://hsafoundation.com

> DirectInput

Officially deprecated for Windows Message Loop and XInput

> DirectPlay

Deprecated for GFWL, not even present anymore in the DirectX SDK (I believe), some modules (voice and NAT helpers) were completely removed in Vista.

> DirectSound

Deprecated for XAudio2 (Vista and 7 implement DirectSound in software, although ALchemy will dynamically intercept DirectSound3D calls and translate them to OpenAL on the fly on Audigy and X-Fi)

http://www.libsdl.org/

I do think this push into Linux is great for making Linux a richer platform overall. This way, everyone wins in that case, but I still do not see it an overly successful monetary venture.

If Windows 8 is a failure, people will either stay with what they know (Windows 7/XP) or continue to defect to OS X. Microsoft doing what they always do, will see where they need to improve, and continue to iterate and push out a more polished Windows 9.

Perhaps not, lets wait until Valve has a chance to fix their D3D issues. It seems to me the blog post was more about success in ferreting out problems with drivers and APIs on Linux and Windows than pure Linux/OpenGL superiority.

I'm a longtime Linux user and there is little reason to assume Linux the is king of graphics. One thing worth pointing out is that Valve is using a Nvidia card with proprietary drivers which don't make use of any shared Linux graphics infrastructure (Gallium3D, etc). So this type of performance gain compared to Windows may not be repeatable with Intel or ATI cards.

OGL still needs to get rid of the legacy fixed unit pipeline and standardizes the interfaces for more advanced functionality (like OGL ES 2 and DX10).

If you request an OpenGL context from your OS and ask for a core profile context, you'll get a context that's almost identical to ES2. It's shader based and all of the legacy fixed stuff is entirely gone.

I gather you're talking about DirectPlay, DirectSound, and DirectInput?

They've all been deprecated and removed from modern versions of DirectX. You need to pull in other libraries to replace those portions (Games for Windows Live, XAudio2, and Windows Message Loop + XInput is one way to roll up that functionality).

Honestly DirectX is mostly just Direct3D in modern incarnations. The situation is fairly similar to modern OpenGL.

Sounds about right. If raw speed was more essential than less problematic development, we'd all be writing in assembler.

I don't know about that any more. I have heard that for about a decade, but with the massive changes that have been made to OpenGL, I don't see why that should still be true, if it even was true in the first place.

http://blog.wolfire.com/2010/01/Why-you-should-use-OpenGL-an...

and a follow up:

http://blog.wolfire.com/2010/01/DirectX-vs-OpenGL-revisited

Source: Current version on newest OS X if you don't want to support Legacy OS X is 3.2, Legacy OS X is 2.1 https://developer.apple.com/graphicsimaging/opengl/capabilit...

Most recent OpenGL is 4.2. http://www.opengl.org/

Most OS X coders, till the recent OS X release have been using 2.1 which was released in 2006 which is when OpenGL was inferior to DirectX in every way.

That's in part a driver issue (though Mach message traffic may also limit perfs), the drivers are mostly developed in-house by Apple, and Apple is notoriously hard to work with (for third parties). So while Valve did lead to significant performance improvements following Steam/OSX I would expect they couldn't work closely with internal drivers developers.

And game perfs probably still isn't the main focus for OSX drivers development, sadly.

Really? Are you sure about that? I'm pretty sure that while there's some Apple-supplied kernel-mode glue, and maybe a lot of user-space components, most of the driver code is actually supplied by NVidia/AMD/Intel.

In fact at one time or another OSX seems to have inherited funny GPU driver bugs that were common with Windows (like the way NVidia's 32-bit drivers were unhappy with living outside the 2GB-4GB memory range).

Although these days I'm it looks like they write significant portions of the graphic driver subsystems: when released their automatic graphics switching seemed quite markedly different from Optimus and completely independent[0], which is corroborated by them not wanting to restrict their ability to switch back to AMD.

[0] http://arstechnica.com/apple/2010/04/inside-apples-automatic...

So let me see if I can follow this: OpenGL is faster than DirectX because...OpenGL is faster than DirectX?

> we could be on the cusp of an OpenGL revolution

Close enough?