Jump to content

  • Log In with Google      Sign In   
  • Create Account

Does Microsoft purposely slow down OpenGL?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
28 replies to this topic

#21 phantom   Moderators   -  Reputation: 7593

Like
1Likes
Like

Posted 11 January 2013 - 08:12 PM

(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)

 

There was (and I'm working on memory here I admit) a couple of aspects to it one of which was real with regards to how OpenGL frame buffers would compose with the D3D driven desktop and windows however that one did get sorted out once MS gave a little on it with some pressure from the IHVs.

 

The other is, as you say, regarding the apparent OpenGL->D3D layering which many took to mean (without bothering to look into it, just looking at a slide) that OpenGL would sit on D3D; what it REALLY meant was MS was going/planning to provide a OGL1.4 implementation based on D3D (I'm not sure they ever did in the end at that.)

(At the time this was going down I was using OpenGL, I heard the above did a 'ffs...' and then once I looked at the details realised the panic was rubbish in this regard...)

 

With regards to MS 'slowing down' OpenGL; many many years ago they were on the ARB (pre-2003 I think?) so they had opportunity to do so with regards to the spec but they didn't have to. Back when the ARB was an infighting mess, a running conflict between the interests of ATi, NVidia, Intel, SGI & 3DLabs so getting anything done was a nightmare which is why nothing got done - GL2.0 was the first causality in that war and Longs Peak was the most recent even after they all started to get along..



Sponsor:

#22 phantom   Moderators   -  Reputation: 7593

Like
1Likes
Like

Posted 11 January 2013 - 08:18 PM

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.

 

It isn't and it isn't.

 

I think I can say that without the NDA Ninjas breaking my door down anyway...



#23 mhagain   Crossbones+   -  Reputation: 8285

Like
1Likes
Like

Posted 11 January 2013 - 09:02 PM

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.


It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.


#24 Hodgman   Moderators   -  Reputation: 31964

Like
0Likes
Like

Posted 11 January 2013 - 10:37 PM

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.

#25 Sik_the_hedgehog   Crossbones+   -  Reputation: 1836

Like
0Likes
Like

Posted 11 January 2013 - 11:45 PM

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.


Don't pay much attention to "the hedgehog" in my nick, it's just because "Sik" was already taken =/ By the way, Sik is pronounced like seek, not like sick.

#26 phantom   Moderators   -  Reputation: 7593

Like
0Likes
Like

Posted 12 January 2013 - 05:39 AM

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...

 

Reading that I get the impression they were using their own translation layer rather than an external one such as WINE which makes sense as it'll have a much lower code cost than trying to effectively rewrite the renderer so that it can natively target both platforms.

 

The problem with trying to draw any conclusions from all this is that there is still a frustrating lack of details on system performance over all; L4D is hardly the most demanding of games (as evidenced by the frame rate) but I'd like to know the overall system load from this multi-threaded approach, how many cores is it using (and indeed memory) compared to the D3D version as that would impact other games with more demanding resource requirements.

(It also remains a D3D9 spec'd engine; everyone else is running off into D3D11 land, heck it's been 18months since we killed support for D3D9 in our engine at work, so seeing a more modern D3D11-style engine tested in this manner would also be nice.)

 

Don't get me wrong, this is good work when all is said and done BUT the lack of some details is bothersome to me as it prevents detailed analysis of just what is going on.



#27 Sik_the_hedgehog   Crossbones+   -  Reputation: 1836

Like
0Likes
Like

Posted 12 January 2013 - 06:00 AM

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)...


Don't pay much attention to "the hedgehog" in my nick, it's just because "Sik" was already taken =/ By the way, Sik is pronounced like seek, not like sick.

#28 phantom   Moderators   -  Reputation: 7593

Like
0Likes
Like

Posted 12 January 2013 - 06:22 AM

The slides say;

- D3D9-like API with extensions and only shader model 2.0b, which implies a GL2 context

 

Also the framerate, post optimisation work, is ~300 which is very low demand work load both CPU and GPU wise as they can turn out a frame every 3.3ms or so; I'd call that the very definition of not demanding ;)



#29 mhagain   Crossbones+   -  Reputation: 8285

Like
1Likes
Like

Posted 12 January 2013 - 09:08 AM

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/


It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS