Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 2 of 2 FirstFirst 12
Results 11 to 13 of 13

Thread: OpenGL vs DirectX re:Device Context and Windows 8

  1. #11
    Senior Member OpenGL Lord
    Join Date
    May 2009
    Posts
    5,928
    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.

  2. #12
    Junior Member Newbie
    Join Date
    Aug 2012
    Posts
    12
    Quote Originally Posted by Alfonse Reinheart View Post
    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.


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

  3. #13
    Senior Member OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,716
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •