OpenGL vs DirectX re:Device Context and Windows 8

Is there a future for OpenGL in Windows 8?

Also I was told that Direct 3D is actually faster on Windows 7 because OpenGL needs to go thru something called a Device Context and apparently Direct3D is more direct and doesnt need to go thru this layer so it’s faster.

Is there any truth to this?

David

Is there a future for OpenGL in Windows 8?

There are drivers bringing OpenGL to Windows 8 already - so at least at that end you’re likely safe.

Also I was told that Direct 3D is actually faster on Windows 7

… which would contradict that L4D2’s OpenGL renderer kicks the crap out of its D3D counterpart even on Windows - not to speak of Linux - and I doubt that Valve didn’t do their best to optimize the D3D renderer.

The device context thing is best answered by our multi-API application or driver devs here. However, I doubt that the layer would be so thick and costly that due to this alone OpenGL becomes uncompetitive on Windows.

Unless your “sources” actually have enough data to substantiate a claim like “D3D is faster than OpenGL” or vice versa, you better just don’t care as it’s nothing more than blatant zealotry. Microsoft has done it many times and there are people on both sides of the isle who love to try and smash the other API. Most of the time without any facts and numbers but only because they think they’re right and because they desperately want to be right.

What is the safest Bet …, taking along the fact that …, Direct X along with D3D comes with other usefull package like …, DirectSound,DirectInput,DirectPlay,DirectShow and not to mention the inbuilt the thread safety and atomicity

In what situation would this thread safety and atomicity be a competitive edge to OpenGL?

What kind of a project/game would it have to be?

Well, the thing is that the question wasn’t aiming at whether to use OpenGL or, and this comparison is one of the worst of all time, DirectX. It was about rendering performance of two competing and comparable APIs on a specific platform.

Would you please care to elaborate on “the thread safety and atomicity” your talking about? In regards to what?

[QUOTE=darkdave;1242702]Is there a future for OpenGL in Windows 8?

Also I was told that Direct 3D is actually faster on Windows 7 because OpenGL needs to go thru something called a Device Context and apparently Direct3D is more direct and doesnt need to go thru this layer so it’s faster.

Is there any truth to this?

David[/QUOTE]

D3D has to go through intermediate layers too; all APIs do.

There may be a (small) handful of percent difference here and there, depending on driver quality and performance (not API) and also depending on the developer not doing anything brain-dead to begin with (like using immediate mode), but so long as you’re writing sane and sensible code the ultimate arbiter of performance is not going to be the API, it’s not going to be the OS, it’s going to be the graphics card.

DirectSound,DirectInput,DirectPlay,DirectShow

DirectPlay was deprecated, as was DirectInput in favor of XInput and OS-level keyboard and mouse interaction. DirectShow, despite the name, is not part of DirectX; it’s not distributed in the DirectX SDK (it’s in the Platform SDK). And DirectSound is still technically around, but it’s all done in software since Vista (because audio hardware drivers were a leading cause of Windows crashes, so Microsoft basically banished them).

[QUOTE=thokra;1242714]Well, the thing is that the question wasn’t aiming at whether to use OpenGL or, and this comparison is one of the worst of all time, DirectX. It was about rendering performance of two competing and comparable APIs on a specific platform.

Would you please care to elaborate on “the thread safety and atomicity” your talking about? In regards to what?[/QUOTE]

Check out the bottom of the page at the following link (at the comment section) for more details on threads and atomicity:

http://rastergrid.com/blog/2011/10/opengl-vs-directx-the-war-is-far-from-over/

That is what he is referring to.

[QUOTE=darkdave;1242722]Check out the bottom of the page at the following link (at the comment section) for more details on threads and atomicity:

http://rastergrid.com/blog/2011/10/opengl-vs-directx-the-war-is-far-from-over/

That is what he is referring to.[/QUOTE]

I did a search through the comments. The only discussion of “atomicity” was in regard to atomic counters and such. And that discussion was on whether D3D is exposing AMD’s specialized support for ARB_atomic_counters (rather than using the existing image load/store atomics on a buffer texture).

And that discussion on multiple threads doesn’t get beyond what we already know here.

[QUOTE=Alfonse Reinheart;1242724]I did a search through the comments. The only discussion of “atomicity” was in regard to atomic counters and such. And that discussion was on whether D3D is exposing AMD’s specialized support for ARB_atomic_counters (rather than using the existing image load/store atomics on a buffer texture).

And that discussion on multiple threads doesn’t get beyond what we already know here.[/QUOTE]

So is d3d’s more robust multi thread rendering a significant edge over gl?

In what project scenario would this be true if any? Why would anyone want to use d3d over gl just for a more robust multi threaded rendering feature?

Is there a future for OpenGL in Windows 8?

On Windows 8, certainly. On Windows RT? No.

WinRT the OS discards all of the Win32 API, in favor of WinRT the API (Microsoft’s naming is very confusing). And since creating an OpenGL context requires the Win32 API, there is no way to create an OpenGL context on the WinRT OS.

Where OpenGL stands as far as the future of the Windows platform is another matter. If Microsoft ever discards Win32 on the desktop, it’s highly unlikely that they’ll build a means to create an OpenGL context into WinRT (the API). Without direct OS vendor support, it’s very possible that OpenGL simply won’t be accessible on Windows.

Of course, the ARB and/or conscientious IHVs could develop a way to back-door OpenGL into the WinRT API. But that’s not something that’s been publicly disclosed.

To be fair, Microsoft discarding Win32 on Win9 depends largely on the success of WinRT the OS (and WinRT the API). If it is successful as a tablet system, and lots of apps get written for it that cover the bases, Microsoft may well ditch Win32 on Win9. This also requires that WinRT is quickly and widely adopted by developers writing for Windows.

That being said, the principle strength of Windows as an OS is its backwards-compatibility; some applications written 15 years ago for Win95 will still work on Win7 and Win8 without even being recompiled. Not many OS’s can make that claim. Breaking this backwards compatibility for WinRT makes sense, because WinRT runs on ARM (so you need to recompile your code anyway). Breaking it for a desktop OS… that’s something that would require great care. And in general, I would expect Microsoft to give a long lead-time, letting developers know years in advance that Win32 is being discontinued.

Just look at IE6 and how they still make patches for that.

Why would anyone want to use d3d over gl just for a more robust multi threaded rendering feature?

You assume that this is the reason people use D3D. It’s not. The main reason D3D gets used is driver quality; D3D drivers by and large have fewer bugs than GL drivers. This is a consequence of the difficulty of writing a conformant GL implementation, as well as the fact that there are a lot more D3D applications. Thus, D3D gets exercised more often, bugs are quickly found and reported, etc.

[QUOTE=Alfonse Reinheart;1242743]On Windows 8, certainly. On Windows RT? No.

WinRT the OS discards all of the Win32 API, in favor of WinRT the API (Microsoft’s naming is very confusing). And since creating an OpenGL context requires the Win32 API, there is no way to create an OpenGL context on the WinRT OS.

Where OpenGL stands as far as the future of the Windows platform is another matter. If Microsoft ever discards Win32 on the desktop, it’s highly unlikely that they’ll build a means to create an OpenGL context into WinRT (the API). Without direct OS vendor support, it’s very possible that OpenGL simply won’t be accessible on Windows.

Of course, the ARB and/or conscientious IHVs could develop a way to back-door OpenGL into the WinRT API. But that’s not something that’s been publicly disclosed.

To be fair, Microsoft discarding Win32 on Win9 depends largely on the success of WinRT the OS (and WinRT the API). If it is successful as a tablet system, and lots of apps get written for it that cover the bases, Microsoft may well ditch Win32 on Win9. This also requires that WinRT is quickly and widely adopted by developers writing for Windows.

That being said, the principle strength of Windows as an OS is its backwards-compatibility; some applications written 15 years ago for Win95 will still work on Win7 and Win8 without even being recompiled. Not many OS’s can make that claim. Breaking this backwards compatibility for WinRT makes sense, because WinRT runs on ARM (so you need to recompile your code anyway). Breaking it for a desktop OS… that’s something that would require great care. And in general, I would expect Microsoft to give a long lead-time, letting developers know years in advance that Win32 is being discontinued.

Just look at IE6 and how they still make patches for that.

You assume that this is the reason people use D3D. It’s not. The main reason D3D gets used is driver quality; D3D drivers by and large have fewer bugs than GL drivers. This is a consequence of the difficulty of writing a conformant GL implementation, as well as the fact that there are a lot more D3D applications. Thus, D3D gets exercised more often, bugs are quickly found and reported, etc.[/QUOTE]

Actually im not, i just want to know wether this feature is practically significant.

In the general case it’s not in the least significant. Most existing code isn’t going to see any performance gain from it, some code may even run slower. Where D3D’s threading support helps is in a very very specific case where the cost of issuing commands outweighs the overhead of running your renderer on multiple threads. If that applies to a program then D3D-style threading can help.

It’s important to realise that this is not multithreaded rendering. In many ways it’s similar to old-school OpenGL display lists. So, you record commands into a deferred context on a separate thread, then, when all commands for all objects have been recorded, you replay them on the main thread, and that step is the one where the actual rendering happens. That should make it quite clear which specific bottleneck this is aiming to tackle, and if that’s not a bottleneck for your program, then you get to deal with the joys of thread synchronization, having D3D and your driver switch to thread-safe versions of all API calls, stepping over each command list twice (once to record and once to replay), messy state synchronization, and a bunch of restrictions on how you can use queries and map buffers.

If roundabout now you’re thinking “woah, that’s actually crap” then there’s a strong probability that the very specific case it aims to address doesn’t apply to you.