Does Microsoft purposely slow down OpenGL?

This is most certainly not true. It is something that people postulated when Vista came out (along with "Microsoft will not allow OpenGL at all").

OpenGL is an API that is implemented by IHVs (the guys who produce your graphics card). It translates some abstract functions (like glSetXZY or glDrawXYZ) that you call and concepts that you use (like buffers, shaders pipeline, render targets, binding points) into something that the GPU can grok. Whatever is necessary to do that.

Direct3D does exactly the same, with a different API.

There is of course Microsoft's own implementation of OpenGL too, and it is slow. But that is mostly because it is a 10 year old software-only implementation. It's mostly irrelevant, since installing a graphics driver automatically installs a "proper" implementation.

What samoth said. Besides, OpenGL is still widely used for scientific visualization and CAD/CAM work. If Microsoft gimped OpenGL, we'd be hearing about it from more sources than a book. Not to mention that someone would have figured a work around by now.

Microsoft did some FUD for Windows Vista, pretending that OpenGL will just be a layer over DirectX and so DirectX would be faster, basically saying DirectX will run in the kernel, and OpenGL will run above the kernel and just wrap around DirectX.
They also released some charts to 'prove' their point. They like misleading people with pretty images.

Why you should use OpenGL and not DirectX - Interesting blog post on the subject.

Why you should use OpenGL and not DirectX - Interesting blog post on the subject.

Interesting read. Thanks for that!

Why you should use OpenGL and not DirectX - Interesting blog post on the subject.

"Intresting" and mostly biased, rubbish and wrong.

I made a couple of blog posts on here taking the article apart - basically the guy doesn't like DX, has this rose tinted view about OpenGL and feels there is a vast conspiracy to Keep OpenGL Down... which is rubbish.

Even the 'zomg! faster draw calls!' point he made is a non-event; on DX9 with 'small' draw calls it was a problem but DX10 and DX11 have since removed it and 'small' draw calls are so far from the norm it isn't worth caring about.

(And as someone who was using OpenGL from ~99 until 2008 I have a certain perspective; heck some of the older members might recall me defending aspects of 'GL before the Longs Peak screw up, which is when I said 'bye' to using GL and went to the saner DX10 and now DX11 land...)

Yup, that article is too biased to be taken seriously.

haha, looks like phantom is still mad with the board, but heck I still am too.

It looks like GL 4.3 & ES 3.0 are finally heading in the right direction and MS got out of the rails with the (again!) decision to make DX 11.1 Windows 8 only. Furthermore there are finally good GL tools we can use (gDebugger is now free, PerfStudio is great, so is NSight)

This answer shows the history of OpenGL vs DirectX throughout the years and nicely explains why it was GL's pure fault in getting to the state it is now (barely used in games).

Here's your article, phantom, thanks for the counterpoints.

I merely posted the link to the blog post, but I did fail to qualify it. The OP was talking about a book where the author was making some claims about DirectX vs OpenGL and that OpenGL was deliberately slowed down; the author's incorrect information about Microsoft intentionally slowing down OpenGL is probably a result of the Vista FUD campaign and the media attention it received - the blog post I linked to explains that FUD campaign; I wasn't trying to say OpenGL is better than DirectX, nor do I think it is.

I shouldn't have used the blog post's title as the text of the hyperlink, as it makes it seem like I agree with the entirety of that post and entirely support the author's viewpoint (Which I actually mostly do, but by coming to my own conclusions, not just borrowing his).

Thanks for clarifying (in your article) that the FUD campaign wasn't actually a FUD campaign and that Carmack's quotes were taken out of context - both of those points are news to me!

I stand somewhere in the middle ground myself, though I lean more towards OpenGL. Currently I only work with 2D graphics, but when I make the move to 3D, I intend to use OpenGL for two reasons:

1. Because I am targeting multiple platforms like Mac and Windows and Linux.
2. Because some competition is good for everyone in the long haul.

...this is in spite of Direct X seeming to be (from an inexperienced outsider looking in) better designed, and not because I think all opensource software is superior in quality to proprietary software (and just because the standard is open, that doesn't mean the implementations are).

I'm prepared to bear the pain and annoyance of OpenGL inconsistencies across videocards, not because it is better overall, but because it is better for my goals.

Yes, it seems this topic took off. I wasn't trying to start a DirectX vs OpenGL cage match, but I don't mind all the articles. There are lots of different points of view.

I couldn't find anything about OpenGL being slowed down. The author was probably biased, and reacting to the FUD campaign discussed previously.

I've used (and cursed) both APIs, and, like any tool, they've got their uses.

It looks like GL 4.3 & ES 3.0 are finally heading in the right direction and MS got out of the rails with the (again!) decision to make DX 11.1 Windows 8 only.

OpenGL|ES is certainly much saner than OpenGL, in the mobile world it's a good thing indeed.

OpenGL I still consider 'broken' while the bind-to-edit model still exist - it's just too easy to introduce bugs and unexpected behaviour (take VAO's; bind VAO, then bind another buffer and BAM! your original VAO is now changed unexpectedly). Don't get me wrong, OpenGL is improving and needs to because without a strong API to counter it D3D will continue to slow down and coast a bit, but bind-to-edit is just so weak when compared to immutable objects and the explicate edit model of D3D.
(Which I consider annoying as there are at least two features of GL (multi-drawindirect and AMD's PRT extension) which I'd like to play with, but every time I think about using GL it makes me sad :( )

As for DX11.1 - some of it is coming back to Win7 as they need it for IE10 support; I can't recall which bits off the top of my head however, nor can I recall if the interesting bits are.

Yup, that article is too biased to be taken seriously.
haha, looks like phantom is still mad with the board, but heck I still am too.
It looks like GL 4.3 & ES 3.0 are finally heading in the right direction and MS got out of the rails with the (again!) decision to make DX 11.1 Windows 8 only. Furthermore there are finally good GL tools we can use (gDebugger is now free, PerfStudio is great, so is NSight)

http://programmers.stackexchange.com/a/88055" href="http://programmers.stackexchange.com/a/88055">This answer shows the history of OpenGL vs DirectX throughout the years and nicely explains why it was GL's pure fault in getting to the state it is now (barely used in games).

Wait what ? So will DX11 be the last DX version for Win7, that sounds pretty insane, i could understand not backporting DX10 to XP since XP was an ancient and outdated OS at the time but Win7 is still fairly new, OpenGL doesn't suck as badly today(Modern OpenGL is quite pleasant to work with) as it did when they pulled the plug on XP and Apple has gained ground, it seems to me that this could be a fairly risky move.

Allthough it could just be that this .1 release mostly adds tablet/touch related features and that we'll get a D3D12 version for Win7 anyway.

Why you should use OpenGL and not DirectX - Interesting blog post on the subject.

"Intresting" and mostly biased, rubbish and wrong.

I made a couple of blog posts on here taking the article apart - basically the guy doesn't like DX, has this rose tinted view about OpenGL and feels there is a vast conspiracy to Keep OpenGL Down... which is rubbish.

Even the 'zomg! faster draw calls!' point he made is a non-event; on DX9 with 'small' draw calls it was a problem but DX10 and DX11 have since removed it and 'small' draw calls are so far from the norm it isn't worth caring about.

(And as someone who was using OpenGL from ~99 until 2008 I have a certain perspective; heck some of the older members might recall me defending aspects of 'GL before the Longs Peak screw up, which is when I said 'bye' to using GL and went to the saner DX10 and now DX11 land...)

The biggest plus point for OpenGL is that it is currently the only way to access the latest GPU features on the Windows XP / Vista, and if you are *extremely careful* you can get the same code running on linux/macos. Semantics aside, there really isn't that much of a difference between D3D & GL4 imho. I'll give you the point about bind-to-edit, although thin wrappers (dressed up to look like D3D) seems to be the approach most people take these days. At least they've finally divorced the texture data from the sampler parameters! :)

There was recently a comparison of Source engine under Linux (using OpenGL) and under Windows (using D3D). Apparently the Linux version was somewhat faster.

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

Cheers!

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.

Ah yes, bind to edit is a big flaw in OGL.

But not only that, what about "try to see if it's supported" or "try it, check glGetError(), if it works; it's supported" philosophy? I talk about that in the comments in Timothy Lottes' blog, it's really annoying and prone to errors.

It's a very old fashion that comes from the time where OGL was library aimed at "guaranteed rendering on every machine", so there was no such thing as unsupported feature because the library would fallback to SW rendering.

But there was never a way to query which features would cause SW emulation to kick in, and today usage is that OpenGL is just an API to wrap to the GPU hardware (except for pure emulation implementations, like Mesa).

I have a contract with Addison-Wesley Professional regarding an OpenGL ES 2.0 book and should stand on equal ground with the original author of the book that mislead you.
Here is my take on the whole situation.


Firstly, OpenGL wasn’t designed for real-time graphics. It was originally primarily for CAD and graphing, which is why their coordinate system puts [0,0] in the lower-left instead of in the upper-left as with every other rendering system on the planet.
But Microsoft® was also not very good at creating usable rendering pipelines back in the day.

Did Microsoft® ever try to slow down OpenGL? No. It wouldn’t even be possible since that is up to the vendor.
Did Microsoft® unfairly push DirectX? Yes. They never shipped any version of OpenGL natively other than 1.1. Intentionally, they tried to keep support for OpenGL to a minimum in order to gain support for DirectX.


Initially neither API was very good. OpenGL was designed for the wrong thing and DirectX was just practice.
At one time it was actually debatable as to whether or not Microsoft was slowing down OpenGL for its own good.

But Khronos kept pushing its state-driven design and Microsoft was forced to keep advancing DirectX.
But the end result is that OpenGL’s model ensures it will always be second-best to DirectX. It’s a state machine and while both API’s have flaws, OpenGL is a framework built on top of technology built for other purposes. The Khronos group saw the potential for overlap and took off with it, eventually creating OpenGL ES, which is basically a game-oriented version of an API that was meant for graphing. They took the best parts of OpenGL and put them into a game-oriented API package, but that alone is not enough.

Microsoft® stopped trying to figure out what we developers need and finally decided to play ball starting with DirectX 10. It was then no longer a matter of, “Our API supports this and this and that,” but a matter of, “We allow you to have access to everything, so you can do whatever the fuck you want”.

Due to Microsoft® not knowing a thing about graphics and OpenGL being originally intended for graphing, both API’s sucked at the start.
As they grew in parallel, there was never a point when either was intentionally slowed, but definitely a point when one was less-supported.

But today there is no question that DirectX 11 is the clear winner. This is why even Sony® (competitor of Microsoft®) uses this API for PlayStation 4 (with just a few modifications).
When DirectX 9 became stagnant OpenGL’s design allowed it to keep advancing, and it started to become a major competitor with DirectX.
But DirectX 10 and DirectX 11 gave more access to the underlying hardware, and this allowed it to take off, and OpenGL was left playing catch-up. OpenGL 4.0 is basically Khronos’s version of DirectX 11. If you look carefully you will notice that for a while it was Microsoft® who was adding features to DirectX based on OpenGL features, but later (and to this day) it was the opposite.


There has been some heightened competition between the 2 API’s, but at no point were either intentionally slowed.
OpenGL builds off a design that was initially flawed and from DirectX 10 it will always be the slower API. Its very design dictates that.


L. Spiro

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.

That Wolfire blog article does more harm than good to the OpenGL "cause" because it's quite obviously ill-informed and biased, not to mention blatantly inaccurate and shamelessly untrue in many cases (full OpenGL on PS3 and mobile platforms? Yeah right...)

D3D didn't succeed because of any of the paranoid crap that is so frequently put forward; D3D succeeded because it became good enough (ironically, in the very best "Unix tradition" of "worse is better") and offered a single, consistent and hardware-independent way of doing things at the same time as OpenGL was going off to loo-lah land with GL_ARB_do_it_this_way, GL_ARB_do_it_that_way and GL_ARB_do_it_t'other_way for every piece of essential functionality.

On topic - since D3D became able to compete, MS simply didn't actively support GL, which is quite a stretch from slowed it down.

Off topic-

[quote name='mhagain' timestamp='1357948483' post='5020539']
(full OpenGL on PS3 and mobile platforms? Yeah right...)
[/quote]Yeah, the portability argument for GL always irks me.

Desktops have GL1.x, 2.x, 3.x, 4.x.

Mobiles have GLES1.x, GLES2.x

Playstation has PSGL (which is just an emulation layer over GCM, giving a similar API to GLES)

Each of these are different APIs, and code written for one still does need to be ported to by used on another. Further, every GPU driver on Windows, and every version of an Apple OS contains it's own implementation of these APIs with slightly different behaviour, greatly complicating your QA procedures.

From a professional graphics programmer's viewpoint, if I was porting a game from Mac to Windows, there'd be a lot of merit in using GL on the Mac and D3D on windows, just so the implementation of the API is consistent and not driver-dependent...

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.

The big part of the DX vs OpenGL difference on Windows for Valve most likely boils down to it being D3D9(Which has a higher drawcall overhead than OpenGL and D3D10+ and that can easily add up to a hundred or so microseconds per frame(This seems to be valves conclusion aswell),
It is pretty much irrelevant now since D3D9 is on its last legs anyway.

(in reply to some other post, not quoting since the forum screws up my posts anyway and its a pain to fix every time)
I don't quite see where the info that microsoft purposely slowed down OpenGL for Vista came from, i was under the impression that the OpenGL->D3D wrapper they added in Vista only were supposed to replace the insanely slow OpenGL software renderer they had in older Windows versions. (So if anything they made OpenGL without proper drivers faster)

But today there is no question that DirectX 11 is the clear winner. This is why even Sony® (competitor of Microsoft®) uses this API for PlayStation 4 (with just a few modifications).

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.