I already mentioned this blog a few posts ago, but let’s dive a bit deeper into it… taking one piece at a time…
“This baffles us. It’s common geek wisdom that standards-based websites, for instance, trounce Silverlight, Flash, or ActiveX. Cross-platform development is laudable and smart. No self-respecting geek enjoys dealing with closed-standard Word documents or Exchange servers. What kind of bizarro world is this where engineers are not only going crazy over Microsoft’s latest proprietary API, but actively denouncing its open-standard competitor?”
Well, that’s a nice bit of FUD right there, to begin with, isn’t it? A case of sentimental fallacy perhaps? What are the reasons why standards-based websites would be better? Silverlight and Flash are widely available, and work just fine if you install the plugin… which is why lots of websites use it for all sorts of things, such as video, navigation etc… Including one of the most popular websites around: YouTube. But let’s move on.
“It’s common knowledge that OpenGL has faster draw calls than DirectX (see NVIDIA presentations like this one if you don’t want to take my word for it), and it has first access to new GPU features via vendor extensions.”
Nice, they use an outdated nVidia presentation (it dates from 2004!)… Which talks about an nVidia-specific OpenGL-extension, which mimics a standard Direct3D feature. And the entire presentation only says this about performance:
“OpenGL draw call cost is lower than Direct3D, but still gives a significant performance benefit”
Not exactly all that convincing if you ask me… Yes, the draw call cost is lower on paper, but still in the same order of magnitude as Direct3D, so you still face the exact same problem in practice. The difference in call cost is irrelevant.
“The tesselation technology that Microsoft is heavily promoting for DirectX 11 has been an OpenGL extension for three years.”
Erm, no… The tessellation in DirectX 11 is far more powerful than this old ATi-only feature (it is fully programmable and introduces two new types of shaders, the hull shader and the domain shader). Which also explains why it never was included in the Direct3D standard. There was no vendor interested in supporting it, outside ATi. With the new-and-improved tessellation (which doesn’t work on that three-year-old ATi hardware), both ATi and nVidia have announced hardware-support. And this new-and-improved tessellation won’t be part of the OpenGL standard until version 4.0.
“We need competition and freedom to drive down prices and drive up quality. A Microsoft monopoly on gaming would be very bad for both gamers and game developers.”
The irony is that competing, driving down prices and driving up quality is exactly what Microsoft is doing with DirectX. They deliver a good set of development tools, good documentation, and they make it easier for IHVs to develop drivers and validate them. Which in turn means more reliable and more consistent drivers, which makes development easier and faster, and allows software to run on different brands of hardware more easily. Those are the main reasons quoted by many developers when asked why they chose Direct3D over OpenGL.
“Back in 1997, the situation was similar to how it is now. Microsoft was running a massive marketing campaign for Direct3D, and soon everyone “just knew” that it was faster and better than OpenGL.”
That’s because in 1997, Direct3D WAS faster and better than OpenGL… at least, on consumer hardware. I’ll quote the GLQuake readme again (which was 1997):
Theoretically, glquake will run on any compliant OpenGL that supports the
texture objects extensions, but unless it is very powerfull hardware that
accelerates everything needed, the game play will not be acceptable. If it
has to go through any software emulation paths, the performance will likely
by well under one frame per second.
At this time (march ’97), the only standard opengl hardware that can play
glquake reasonably is an intergraph realizm, which is a VERY expensive card.
3dlabs has been improving their performance significantly, but with the
available drivers it still isn’t good enough to play. Some of the current
3dlabs drivers for glint and permedia baords can also crash NT when exiting
from a full screen run, so I don’t recommend running glquake on 3dlabs
3dfx has provided an opengl32.dll that implements everything glquake needs,
but it is not a full opengl implementation. Other opengl applications are
very unlikely to work with it, so consider it basically a “glquake driver”.
If it wasn’t for GLQuake, I wonder if OpenGL would ever have taken off at all on the PC. GLQuake was the cue for vendors to start writing ‘miniGL’ drivers, which later evolved into complete OpenGL implementations… but in 1997, the hardware simply wasn’t powerful enough, and there were no OpenGL drivers for consumer hardware. 3dfx reigned supreme with its Glide API. Quake, ID and John Carmack apparently had a lot of influence. I doubt that any other developer could have pulled it off.
“On the other hand, if you use OpenGL, you get faster and more powerful graphics features than DirectX 11, and you get them on all versions of Windows, Mac and Linux, as well as the PS3, Wii, PSP, DS, and iPhone.”
Ouch, where do I start with this one? What he does here, is take all the advantages of OpenGL in individual cases on individual platforms, and generalizes it into a single mega-solution… which is simply not true.
Firstly… Faster and more powerful graphics than DirectX 11? You need DirectX 11-capable hardware at the least… which rules out PS3, Wii, PSP, DS and iPhone. Aside from that, this claim is hard to substantiate, when multi-API engines such as Unigine or Unity appear to perform faster in D3D mode than in OpenGL mode, and OpenGL-mode tends to give D3D9-level quality at best.
Secondly, some of the platforms don’t support OpenGL, but its cousin OpenGL ES. Not entirely the same.
Lastly, the PS3 and Wii only support OpenGL in a ‘homebrew’ way. For best performance and quality, they have their own proprietary libraries. No commercial game on PS3 or Wii uses OpenGL, they all use the Sony/Nintendo-specific APIs or go down to the bare metal. The OpenGL implementations just aren’t fast enough. The custom APIs suit the hardware much better.
“If there’s anything about OpenGL that you don’t like, then just ask the ARB to change it — they exist to serve you!”
Well… the problem with the ARB for the past years has been exactly the opposite… Developers have been asking for a major API update for years, ever since OpenGL 2.0 (for which 3DLabs had a nice proposal). But the ARB decided against it all… In the end, OpenGL 2.0 was little more than the standardization and inclusion of a bunch of extensions into the core API. They repeated this feat again with OpenGL 3.0. So if anything, ARB doesn’t listen AT ALL to its developers, and appears to serve only the IHVs who want to invest as little time and effort into OpenGL as possible.
Thing is… I don’t have anything against OpenGL. I use it myself in the BHM file format project, so open source, open standards, and multi-platform software, I’m all for that… But do we really need to rely on lies and FUD in order to convince other people? I think that’s rather counter-productive, and I certainly don’t support it.
Pingback: What is a platform anyway? | Scali's OpenBlog™