OpenGL: Regal for OSX?

Discussion in 'Mac Programming' started by blueshogun96, May 28, 2014.

  1. blueshogun96 macrumors regular

    blueshogun96

    Joined:
    Nov 24, 2012
    #1
    I'm looking into Regal for OSX since it may be the only possible way to move beyond Apple's implementation of OpenGL 4.1 on Mavericks. I dunno why Apple won't keep up to date with the latest versions of OpenGL, but I can only see it as a limiting factor, especially if Apple is any way interested in gaming.

    Im also wondering if NVIDIA's web drivers support any features beyond 4.1, but are not accessible via the current OpenGL.framework in XCode. GLEW appears to have some support for regal on OSX, but I can't find much information on that.

    Any ideas?

    Shogun
     
  2. Dranix macrumors 6502a

    Dranix

    Joined:
    Feb 26, 2011
    Location:
    Gelnhausen, Germany
    #2
    May I ask what important new features are in OpenGL 4.2+ that many are so aggressive to get it?
     
  3. marksatt macrumors regular

    Joined:
    Jun 26, 2013
    Location:
    Epic UK
    #3
    Regal will not enable you to access OpenGL 4.2 or 4.3 hardware features that aren't supported by Apple's OpenGL. Regal merely (*) wraps the platform OpenGL and provides API compatibility for a minority of OpenGL extensions that can be supported by emulating them using the existing platform's features. The primary reason to use Regal on the Mac would be to share code with platforms that use a GL 3.2+ Compatibility context (i.e. still use the 2.1 & earlier fixed-function pipeline) or that make use of the Direct State Access extension API, both of which Regal emulates.

    (* Something of an understatement, Regal's code is quite clever in itself and tries to emulate these features in as efficient a way as possible).

    The three most important extensions (for me at least) from 4.2 & 4.3 of the top of my head would be GL_texture_view, GL_ARB_shader_image_load_store and
    GL_ARB_compute_shaders, none of which you will get from using Regal on OS X.

    You could implement a limited, non-conformant and feature restricted version of GL_ARB_compute_shader using OpenCL as the back-end and wrapping all the necessary OpenGL objects but Regal doesn't do this. You'd need OpenCL 2.0 to do a decent job though and OS X is on OpenCL 1.2 as of Mavericks.

    I'm waiting to see what Apple announce at WWDC about the next update to OS X and whether they will update OpenGL again and if so to which version.
     
  4. Dranix macrumors 6502a

    Dranix

    Joined:
    Feb 26, 2011
    Location:
    Gelnhausen, Germany
    #4
    Can you explain what they do and why they are so important?


    What is so heavy missing from OpenCL 1.2?


    I don't want to annoy, I just want to understand all the cries for each new OpenGL-version when we where fine for years with OpenGL 2.x. When I see no relevant improvement after 3.x
     
  5. marksatt, Jun 1, 2014
    Last edited: Jun 9, 2014

    marksatt macrumors regular

    Joined:
    Jun 26, 2013
    Location:
    Epic UK
    #5
    Dranix, the move from OpenGL 2.1 to 4.1 is hugely significant for games on OS X. Having previously worked at Feral porting games to now working on the Mac version UE4 at Pitbull Studios for Epic, I can tell you Apple's GL 4.1 is night and day better than their 2.1 GL.

    It was a real frustration at Feral that games would ship without the advanced rendering features, like tessellation in Batman Arkham City because we were at the time restricted to OpenGL 2.1 which doesn't support anything like the features of D3D11. Nor was it especially performant when compared to latter-day D3D9 renderers. Some games would be notably slower on the Mac due to the way we had to implement certain features on GL 2.1 that could have been improved on GL 3.2 or later (texture copying springs to mind here). Unfortunately D3D9 games tended to make some use of the old fixed-function pipeline so we couldn't move up to the 3.2 core profile as that removes fixed-function support. I seriously looked into whether we could use Regal when porting Batman Arkham City for just that reason, but I couldn't get it to work in that game well enough.

    Newer game engines like UE4 or those used by the new Tomb Raider & Hitman from Feral, are designed for D3D11 from the get-go, so no fixed-function pipeline and much cleaner mapping to the OpenGL 4+ feature-set. The only problem is that base D3D11 features were added in OpenGL 4.2 and 4.3 but Apple only supply 4.1.

    The examples I gave were the three extensions that would most help to add Shader Model 5 rendering support to Mac UE4, which is currently limited to Shader Model 4 due to their absence. I'm not crying about this & I'm not angry either. It'd just be nice to have them so that our users can access the full potential of UE4 & their GPUs.

    GL_ARB_texture_view is the equivalent of D3D11 Shader Resource Views, allowing you to create an alias to a subset of another texture's data, potentially also reinterpreting the format. This is more efficient than changing the original texture object's GL_TEXTURE_BASE_LEVEL and GL_TEXTURE_MAX_LEVEL and/or copying data between textures of different but compatible formats.

    GL_ARB_shader_image_load_store is OpenGL's equivalent to D3D11's RWBuffers - they let you perform arbitrary read and most importantly, write, operations to a single texture layer. You could try and emulate this by copying the texture data to a PBO then binding it as a GL_TEXTURE_BUFFER, while simultaneously binding the texture as a colour attachment to write to, but that'll end up being more complicated and slower. Depending on the driver's capabilities you might also be unable to write to the same formats. A further and potentially crippling limitation would of course be the inability to mimic this extension's most useful feature - writing data in one shader and then reading it in a following one with quite a degree of control over synchronisation e.g. writing data in the vertex and reading in the fragment using atomic load/store.

    GL_compute_shader allows you to use GLSL to perform highly parallel general computation on the GPU from within the OpenGL pipeline, analogous to DirectCompute. This means you need only support two shader languages - HLSL and GLSL since compute is just another shader stage. It also avoids all the tedious & slow manual binding of GL objects to CL using the CL_GL_interop extension, which also breaks if you change certain GL object properties (like GL_TEXTURE_BASE_LEVEL and GL_TEXTURE_MAX_LEVEL). Finally, most game engines aren't designed to batch all the compute work to one part of the frame, since consoles & DirectCompute don't require it, so the required manual GL-CL context swap can be costly as you switch back and forth between GL & CL from one render pass to the next.

    The big limitation in OpenCL 1.2 in Mavericks is the limited support for GL textures and texture sampling in the GL_interop extension. There's no support for mip-mapped textures, only a single texture level can be exposed to CL. Nor can it perform texture filtering or binding from some of the GL texture types. OpenCL 2.0 adds more texture types as well as mip-mapping and linear filtering support, so it is better, but it still isn't ideal compared to GL_ARB_compute_shader.
     

Share This Page