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 1 of 2 12 LastLast
Results 1 to 10 of 45

Thread: Official feedback on OpenGL 4.4 thread

Hybrid View

  1. #1
    Administrator Regular Contributor Khronos_webmaster's Avatar
    Join Date
    Apr 2007
    Location
    Montreal
    Posts
    151

    Official feedback on OpenGL 4.4 thread

    July 22nd 2013 – SIGGRAPH - Anaheim, CA – The Khronos™ Group today announced the immediate release of the OpenGL® 4.4 specification,bringing the very latest graphics functionality to the most advanced and widely adopted cross-platform 2D and 3D graphics API (application programming interface). OpenGL 4.4 unlocks capabilities of today’s leading-edge graphics hardware while maintaining full backwards compatibility, enabling applications to incrementally use new features while portably accessing state-of-the-art graphics processing units (GPUs) across diverse operating systems and platforms. Also, OpenGL 4.4 defines new functionality to streamline the porting of applications and titles from other platforms and APIs. The full specification and reference materials are available for immediate download at http://www.opengl.org/registry.

    In addition to the OpenGL 4.4 specification, the OpenGL ARB (Architecture Review Board) Working Group at Khronos has created the first set of formal OpenGL conformance tests since OpenGL 2.0. Khronos will offer certification of drivers from version 3.3, and full certification is mandatory for OpenGL 4.4 and onwards. This will help reduce differences between multiple vendors’ OpenGL drivers, resulting in enhanced portability for developers.

    New functionality in the OpenGL 4.4 specification includes:

    Buffer Placement Control (GL_ARB_buffer_storage)
    Significantly enhances memory flexibility and efficiency through explicit control over the position of buffers in the graphics and system memory, together with cache behavior control - including the ability of the CPU to map a buffer for direct use by a GPU.

    Efficient Asynchronous Queries
    (GL_ARB_query_buffer_object)
    Buffer objects can be the direct target of a query to avoid the CPU waiting for the result and stalling the graphics pipeline. This provides significantly boosted performance for applications that intend to subsequently use the results of queries on the GPU, such as dynamic quality reduction strategies based on performance metrics.

    Shader Variable Layout (GL_ARB_enhanced_layouts)
    Detailed control over placement of shader interface variables, including the ability to pack vectors efficiently with scalar types. Includes full control over variable layout inside uniform blocks and enables shaders to specify transform feedback variables and buffer layout.

    Efficient Multiple Object Binding (GL_ARB_multi_bind)
    New commands which enable an application to bind or unbind sets of objects with one API call instead of separate commands for each bind operation, amortizing the function call, name space lookup, and potential locking overhead. The core rendering loop of many graphics applications frequently bind different sets of textures, samplers, images, vertex buffers, and uniform buffers and so this can significantly reduce CPU overhead and improve performance.

    Streamlined Porting of Direct3D applications

    A number of core functions contribute to easier porting of applications and games written in Direct3D including GL_ARB_buffer_storage for buffer placement control, GL_ARB_vertex_type_10f_11f_11f_rev which creates a vertex data type that packs three components in a 32 bit value that provides a performance improvement for lower precision vertices and is a format used by Direct3D, and GL_ARB_texture_mirror_clamp_to_edge that provides a texture clamping mode also used by Direct3D.Extensions released alongside the OpenGL 4.4 specification include:

    Bindless Texture Extension (GL_ARB_bindless_texture)
    Shaders can now access an effectively unlimited number of texture and image resources directly by virtual addresses. This bindless texture approach avoids the application overhead due to explicitly binding a small window of accessible textures. Ray tracing and global illumination algorithms are faster and simpler with unfettered access to a virtual world's entire texture set.

    Sparse Texture Extension (GL_ARB_sparse_texture)
    Enables handling of huge textures that are much larger than the GPUs physical memory by allowing an application to select which regions of the texture are resident for ‘mega-texture’ algorithms and very large data-set visualizations.


    OpenGL BOF at SIGGRAPH, Anaheim, CA July 24th 2013
    There is an OpenGL BOF “Birds of a Feather” Meeting on Wednesday July 24th at 7-8PM at the Hilton Anaheim, California Ballroom A & B, where attendees are invited to meet OpenGL implementers and developers and learn more about the new OpenGL 4.4 specification.
    Webmaster Khronos.org and OpenGL.org

  2. #2
    Senior Member OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,201
    full certification is mandatory for OpenGL 4.4 and onwards
    This on it's own is cause for joy. Any chance of mandatory full certification being brought back to earlier versions as time goes by and drivers mature?

  3. #3
    Intern Contributor Godlike's Avatar
    Join Date
    May 2004
    Location
    Greece
    Posts
    67
    The ARB extensions (bindless texture & sparse texture) sound way more interesting/useful compared to the core ones. Also, having updated specs and new extensions backed by ARB every year is really great for the GL developers.
    Last edited by Godlike; 07-22-2013 at 09:03 AM.

  4. #4
    Intern Contributor nigels's Avatar
    Join Date
    Apr 2000
    Location
    Texas, USA
    Posts
    87
    GLEW 1.10.0 is now available, including GL 4.4 support.
    http://glew.sourceforge.net/

    - Nigel
    ---
    Regal - as OpenGL ought to be

  5. #5
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,128
    and full certification is mandatory for OpenGL 4.4 and onwards
    This is so awesome. We can only hope this won't slow down spec adoption even further.

    The other features sound cool as well, but we'll see how it works out in practice. GL_ARB_buffer_storage, GL_ARB_query_buffer_object, GL_ARB_multibind ... very interesting.

  6. #6
    Senior Member OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,201
    Issue #9 for GL_ARB_buffer_storage makes for fairly grim reading, unfortunately...

    It's a pity as this could have been the kick up the jacksie that GL's buffer object API really needed, and the issue in question should really have been resolved by just saying "this is client memory, full stop, using incompatible flags generates an error, here are the flags that are incompatible and the vendors will have to just live with it", but it seems another case of shooting too high and missing the basic requirement as a result.

  7. #7
    Junior Member Newbie
    Join Date
    Dec 2008
    Location
    WA, Inland Northwest
    Posts
    4
    Quote Originally Posted by thokra View Post
    This is so awesome. We can only hope this won't slow down spec adoption even further.

    The other features sound cool as well, but we'll see how it works out in practice. GL_ARB_buffer_storage, GL_ARB_query_buffer_object, GL_ARB_multibind ... very interesting.
    How do you figure? The spec is mulled over by members of all GPGPU vendors. They are the ones who signed off on it. This strikes me as an official commitment by the vendors to make OpenGL a solid and fully commited spec.

  8. #8
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    The Second Annual Unofficial OpenGL Feature Awards!

    I hereby hand out the following awards:

    We (Finally) Did What We Said We Were Gonna Award

    The conformance test suite.

    I'll just quote Tychus Findley, "Hell, it's about time!"

    One Little Mistake Award

    ARB_multi_bind

    This was good functionality, until I saw glBindImageTextures. I can't really think of a more useless way to specify that. It applies the "defaults", based on the texture target. Which means that an array texture will always be bound layered.

    OK to be fair, you can use texture_views to effectively create single textures who's defaults match what you would pass to glBindImageTexture. And then you just bind them all in one go.

    3D Labs Is Really, Really Dead Award

    ARB_enhanced_layouts

    So, not only can we specify uniform locations in the shader, we can even specify packing behavior. To the point that we can steal components from other vectors and make them look just like other variables.

    That one must be a nightmare to implement. I hope the ARB has a really comprehensive conformance test for it...

    Oh, and this also wins Most Comprehensive Extension Award. It lets us steal components from other interface elements, specify the uniform/storage block layout, define locations for interface block members, and define transform feedback parameters directly in the shader.

    Is OpenGL Still Open Award?

    ARB_bindless_texture

    So. NVIDIA comes out with NV_bindless_texture. And unlike bindless attributes and pointers in GLSL, they actually patent this.

    And now it's an ARB extension. It's not core... but it's not a proprietary extension. Yet anyone who implements it will almost certainly be stepping on US20110242117, and therefore must pay whatever NVIDIA says they have to pay. Unless NVIDIA has some agreement with the ARB, granting anyone a license to implement ARB_bindless_texture without paying a fee.

    The really disconcerting part is that the patent encumbrance issue... isn't mentioned in the spec. Other extensions like EXT_texture_compression_s3tc mention their patent issues. But not this one.

    Last Kid Picked for Baseball Award

    EXT_direct_state_access

    When bindless texturing gets the nod from the ARB, and this doesn't, something interesting is happening behind the scenes. How much does the ARB not want this in core GL, for them to deal with sparse and bindless textures first?

    Then again, apparently NVIDIA wants to support DSA so badly that they may be updating the DSA extension with new stuff... and not telling anyone else who's implementing it. If true, that's not playing fair, guys. There's clearly some kind of huge fight happening around this functionality within the ARB.

    So I hope nobody's holding their breath on this one.

    Fragmenting The World Award

    ARB_compute_variable_group_size

    I understand why ARB_bindless_texture and ARB_sparse_texture aren't core. That reason being (besides the patent issues) that we don't want IHVs to have to say that <insert hardware here> can do 4.3, but not 4.4. There are lower-classes of 4.x hardware that just can't do this stuff. So we leave them as extensions until as such time as the ARB decides that the market penetration of higher-end hardware is sufficient to incorporate them.

    Or until we finally decide to have 5.0 (ie: when Microsoft decides to go to D3D 12).

    But compute_variable_group_size really seems like something any 4.x-class hardware should be able to handle. Something similar goes for ARB_indirect_parameters.

    Hey, That's Actually Useful Now Award

    ARB_buffer_storage

    This extension adds functionality to glFlushMappedBufferRange, one of the more useless functions from ARB_map_buffer_range. Now, you can effectively keep a buffer mapped indefinitely and simply synchronize yourself with the server by flushing written ranges.

    You Were Right Award

    Um, me. Admittedly, it's old, but I still called it: immutable buffer object storage, with better, enforced behavior. I even called the name (which admittedly is derivative and therefore obvious). Though to be fair, the whole "render while mapped" was not something I predicted.

    I was going to say that it seemed odd that not specifying GL_DYNAMIC_STORAGE_BIT still allowed you to map the buffer for writing. But I did see a notation that glBufferStorage will fail if you use GL_MAP_WRITE_BIT without also specifying GL_DYNAMIC_STORAGE_BIT. And of course, you can't map an immutable buffer for writing without GL_MAP_WRITE_BIT.

    It doesn't have all of the bits I would have liked to see. But it has all the bits the IHV's wanted (they even said so in the "issues" section). So I'll call that "good enough."

    Oh, and as for the complaints about GL_CLIENT_STORAGE_BIT being a hint... then don't use it. Remember: the problem with the current buffer object setup isn't merely that they're hints (that contributes, but that alone isn't the full problem). It's that the hints don't really communicate what you are going to do with the buffer. Buffer Storage lets you do that.

    You describe exactly how you intend to use it. The bits answer the important questions up-front: will I write to it, will I map it for reading or writing, do I want OpenGL to access it while it's mapped, etc. And the API enforces every single one of these methods of use.

    I have no idea why they even bothered to put GL_CLIENT_STORAGE_BIT there, since that doesn't describe how you will use the buffer. But as the issue rightly stated, drivers will ultimately just ignore the hint.

    So encourage them to do so by ignoring it yourself.

  9. #9
    Junior Member Newbie
    Join Date
    Aug 2009
    Location
    Ottawa, Canada
    Posts
    5
    Quote Originally Posted by Alfonse Reinheart View Post
    Is OpenGL Still Open Award?
    You probably want to read http://www.khronos.org/members/ip-framework

    Quote Originally Posted by Alfonse Reinheart View Post
    Fragmenting The World Award

    I understand why ARB_bindless_texture and ARB_sparse_texture aren't core. That reason being (besides the patent issues) that we don't want IHVs to have to say that <insert hardware here> can do 4.3, but not 4.4. There are lower-classes of 4.x hardware that just can't do this stuff. So we leave them as extensions until as such time as the ARB decides that the market penetration of higher-end hardware is sufficient to incorporate them.
    <snip>
    But compute_variable_group_size really seems like something any 4.x-class hardware should be able to handle. Something similar goes for ARB_indirect_parameters.
    Your logic for the former extensions applies to the later ones as well.

  10. #10
    Administrator Contributor
    Join Date
    Jan 2002
    Location
    Mt. View, CA
    Posts
    97
    This on it's own is cause for joy. Any chance of mandatory full certification being brought back to earlier versions as time goes by and drivers mature?
    No. Khronos can't require certification for specifications that have already gone through ratification and have shipping implementations. Mandatory starts with GL 4.4 implementations. But some vendors who are shipping earlier versions are likely to choose to make conformance submissions on those drivers. All the major desktop IHVs (and one IV who isn't on desktop at the moment) have been actively contributing to the conformance tests and running them against their drivers during the test development process.

    The conformance tests are not going to solve every behavior difference or address every bug - that level of testing is far out of scope relative to the resources Khronos can put into developing tests - but they should be a significant improvement over SGI's OpenGL CTS,l which was last updated about 14 years ago.
    Jon Leech
    Khronos API Registrar
    ARB Ecosystem TSG Chair
    GL/EGL/GLES Spec Editor
    ...and suchlike

Tags for this Thread

Posting Permissions

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