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 96

Thread: Official feedback on OpenGL 4.3 thread

Hybrid View

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

    Official feedback on OpenGL 4.3 thread

    August 6th, 2012 – Los Angeles, SIGGRAPH 2012 – The Khronos™ Group today announced the immediate release of the OpenGL® 4.3 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.3 integrates developer feedback and continues the rapid evolution of this royalty-free specification while maintaining full backwards compatibility, enabling applications to incrementally use new features while portably accessing state-of-the-art graphics processing unit (GPU) functionality across diverse operating systems and platforms. The OpenGL 4.3 specification contains new features that extend functionality available to developers and enables increased application performance. The full specification is available for immediate download at http://www.opengl.org/registry.

    Twenty years since the release of the original OpenGL 1.0, the new OpenGL 4.3 specification has been defined by the OpenGL ARB (Architecture Review Board) working group at Khronos, and includes the GLSL 4.30 update to the OpenGL Shading Language.

    New functionality in the OpenGL 4.3 specification includes:

    • compute shaders that harness GPU parallelism for advanced computation such as image, volume, and geometry processing within the context of the graphics pipeline;
    • shader storage buffer objects that enable vertex, tessellation, geometry, fragment and compute shaders to read and write large amounts of data and pass significant data between shader stages;
    • texture parameter queries to discover actual supported texture parameter limits on the current platform;
    • high quality ETC2 / EAC texture compression as a standard feature, eliminating the need for a different set of textures for each platform;
    • debug capability to receive debugging messages during application development;
    • texture views for interpreting textures in many different ways without duplicating the texture data itself;
    • indirect multi-draw that enables the GPU to compute and store parameters for multiple draw commands in a buffer object and re-use those parameters with one draw command, particularly efficient for rendering many objects with low triangle counts;
    • increased memory security that guarantees that an application cannot read or write outside its own buffers into another application’s data;
    • a multi-application robustness extension that ensures that an application that causes a GPU reset will not affect any other running applications.


    Learn more about what is new in OpenGL 4.3 at the BOF at Siggraph, Wed, August 8th from 6-7PM in the
    JW Marriott Los Angeles at LA Live, Gold Ballroom –Salon 3. Then join us to help celebrate the 20th anniversary of OpenGL on Wednesday August 8th from 7-10 PM in the JW Marriott Los Angeles at LA Live Gold Ballroom – Salon 1, 2 & 3.

    Complete details on the BOF are here:
    http://www.khronos.org/news/events/s...012#opengl_bof

    Complete details on the Party are here:
    http://www.khronos.org/news/events/o...iversary-party
    Webmaster Khronos.org and OpenGL.org

  2. #2
    Advanced Member Frequent Contributor
    Join Date
    Apr 2009
    Posts
    578

    Big thankyou.

    A Big Thankyou to all the contributors of the GL4.3 specification. The reorganization of the specification (which is almost like a text-rewrite) is wonderful . Comments on the added beans to follow from me.

    Wish I could have made it to SIGGRPAH this year .

  3. #3

  4. #4
    Intern Contributor
    Join Date
    Aug 2009
    Posts
    66
    The compute shaders with the shader storage buffer objects are very interesting. (Calculating data and integrating that data into the graphics pipeline + other direction and doing both in an advanced application could achieve very interesting blends of things.)

    high quality ETC2 / EAC texture compression as a standard feature: Hopefully this solves texture compression for the foreseeable future. Becomes core in a future OpenGL version.

    Multi-application robustness: important, I can't believe OpenGL only has this now. Hope to see this in OpenGL ES and WebGL too!

    Feature requests:

    Direct State Access functions: less error prone, same done with less code.

    Bindless textures: less error prone and abstraction allows things not possible before while driver can be optimized for gpu specific architecture things.

    If I debug an application I want to be able to see if api calls are deprecated, either in the currently used OpenGL version in the context or other versions (let me specify api's and version ranges, compatibility ranges, profiles). If I use an 3.3 context also show me deprecations for further contexts. First list the currently used version then the other ones (from earlier deprecation to recent deprecation). This way a developer can work from the earlier stuff that should be tackled first to the later stuff that should be tackled last in the list. Make sure this is not tied to the used context of the OpenGL application just like the show debug output.
    Last edited by Gedolo; 08-06-2012 at 07:50 AM.

  5. #5
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    The Unofficial OpenGL 4.3 Feature Awards!

    I hereby hand out the following awards:

    We Did What We Said We Were Gonna Award

    The OpenGL Graphics System: A Specification (Version 4.3)

    Literally as I was downloading the spec, I said out loud something to the effect of, "There's no way the ARB actually did the rewrite they promised." I was wrong.

    It's a much better spec. There are still a couple of issues, like why VAOs are still presented after all of the functions that set state into them. But outside of a few other anomalies like that, it is much more readable. Props for having a dedicated error section for each function, in a different background, to make it clear what the possible errors are.

    Most Comprehensive Extension Award

    ARB_internalformat_query2

    This is something OpenGL has needed for ages, and I generally don't like giving props for people finally doing what they were supposed to have done long ago. But this extension provides pretty much every query you could possibly imagine. It's even a little too comprehensive, as you can query aspects of formats that aren't implementation-dependent (color-renderable, for example).

    One Little Mistake Award

    ARB_vertex_attrib_binding

    This was good functionality, until I saw that the stride is part of the buffer binding, not the vertex format. Indeed, that's the reason why it can't use glBindBufferRange; because it needs a stride. Why is the stride there and not part of the format? Even NVIDIA's bindless attribute stuff puts the stride in the format.

    This sounds like some horrible limitation ported over from D3D's stream nonsense that OpenGL simply doesn't need.

    We Declare A Do-Over Award

    ARB_compute_shader

    The existence of ARB_compute_shader is a tacit admission that OpenCL/OpenGL interop is a failure. After all, the same hardware that runs compute shaders will run OpenCL. So why wouldn't you use OpenCL to do GPGPU work, and interop with OpenGL with the interop layer.

    3D Labs Is Finally Dead Award

    ARB_explicit_uniform_location

    The last remnants of the Old Republic have been swept away forever. GLSL, as 3D Labs envisioned it, is now dead and buried in a shallow grave. OpenGL has finally accepted that uniform locations won't be byte offsets and will have to be mapped into a table to reconstruct those byte offsets.

    So it's high time the ARB cut their losses with the last of 3D Labs's horrible ideas and provided functionality in a way that coincides better with reality.

    We Need More Ways To Do Things Award:

    ARB_shader_storage_buffer_object

    You know what OpenGL doesn't have enough of? Ways to access buffer objects from shaders. I mean, buffer textures, UBOs, and image buffer textures just weren't enough, right? We totally needed a fourth way to access buffer objects from shaders.

    Yeah, I get what they were saying in Issue #1 (where they discussed why they didn't re-purpose UBOs for this). But it doesn't change the fact that there are now 4 separate ways to talk to buffer objects from shaders, and each one has completely different performance characteristics.

    Let's Rewrite Our API And Still Leave The Original Award:

    ARB_program_interface_query

    I get the idea, I really do. It provides a much more uniform and extensible ways to query information from shaders. That's a good thing, and I'm not disputing that. But we already have APIs to do that; indeed, pretty much the only thing missing from those APIs was querying fragment shader outputs.

    Now the API is very cluttered. We have the old way of doing things, plus this entirely new way.

    You Were Right Award

    Mhagain's suggestion for texture_views, which was implemented. I_belev's initial idea was close, but much more narrow (changing the format on an existing texture, rather than creating a new texture that referenced the old data) than the actual texture view stuff provided by 4.3.

    Overall, I'm getting a feeling of deja vu: once again, OpenGL has many ways to do things, and little guidance as to how to do it. We've got multiple ways to set up vertex formats and buffers, multiple ways to read data from buffers in shaders, etc.

    Of course, we won't see another API cleanup and function removal round, since the last one went so well.

  6. #6
    Advanced Member Frequent Contributor
    Join Date
    Dec 2007
    Location
    Hungary
    Posts
    985
    Quote Originally Posted by Alfonse Reinheart View Post
    One Little Mistake Award

    ARB_vertex_attrib_binding

    This was good functionality, until I saw that the stride is part of the buffer binding, not the vertex format. Indeed, that's the reason why it can't use glBindBufferRange; because it needs a stride. Why is the stride there and not part of the format? Even NVIDIA's bindless attribute stuff puts the stride in the format.

    This sounds like some horrible limitation ported over from D3D's stream nonsense that OpenGL simply doesn't need.
    I couldn't agree more, stride is just strange there, as it's more a format specifier than a resource specifier. Also, the additional indirection between vertex attribute indices and vertex buffer binding indices sounds way too much abstraction. But to be honest, personally, I would drop all vertex array stuff at once. Using shader storage buffers now is probably the best way to access vertex data, if you can live with the limitation that your shaders now have to know explicitly your vertex data formats (actually, from performance-wise it's probably preferable to be explicit).

    Quote Originally Posted by Alfonse Reinheart View Post
    We Declare A Do-Over Award

    ARB_compute_shader

    The existence of ARB_compute_shader is a tacit admission that OpenCL/OpenGL interop is a failure. After all, the same hardware that runs compute shaders will run OpenCL. So why wouldn't you use OpenCL to do GPGPU work, and interop with OpenGL with the interop layer.
    Sad, but probably true. I wouldn't expect it either, but if that's what it takes to have efficient compute-graphics interworking, then let it be.
    Disclaimer: This is my personal profile. Whatever I write here is my personal opinion and none of my statements or speculations are anyhow related to my employer and as such should not be treated as accurate or valid and in no case should those be considered to represent the opinions of my employer.
    Technical Blog: http://www.rastergrid.com/blog/

  7. #7
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    But to be honest, personally, I would drop all vertex array stuff at once. Using shader storage buffers now is probably the best way to access vertex data, if you can live with the limitation that your shaders now have to know explicitly your vertex data formats (actually, from performance-wise it's probably preferable to be explicit).
    ... how? Attribute format conversion is free; doing it in the shader would be not free. How is "not free" faster than "free"?

    Furthermore, attributes are fast, with dedicated caches and hardware designed to make their particular access pattern fast. Shader storage buffers are decidedly not. Specific hardware still beats general-purpose code.

  8. #8
    Super Moderator Frequent Contributor Groovounet's Avatar
    Join Date
    Jul 2004
    Posts
    934
    Quote Originally Posted by Alfonse Reinheart View Post
    ... how? Attribute format conversion is free; doing it in the shader would be not free. How is "not free" faster than "free"?

    Furthermore, attributes are fast, with dedicated caches and hardware designed to make their particular access pattern fast. Shader storage buffers are decidedly not. Specific hardware still beats general-purpose code.
    First the stride parameter needs to be a binding parameter. It allows to reusing the same vertex formats but data that is dispatched into various number of buffer. Typically we can expect cases where a vertex format will be used for a perfectly packed buffer which interleave all the data. We can however imagine that the same vertex format can be reused without switching for a data that are stored into two buffers: One static and one dynamically updated.

    Second, attribute format conversion is the same cost when done in the shader because it is effectively already done in the shader behind or back. GPUs no longer use dedicated hardware for that, it takes space that can't be reused for something else. That will be more and more the case.

  9. #9
    Member Regular Contributor
    Join Date
    Apr 2009
    Posts
    268
    Quote Originally Posted by aqnuep View Post
    Also, the additional indirection between vertex attribute indices and vertex buffer binding indices sounds way too much abstraction.
    Hey, but we have gained some consitency. Now both inputs (attributes) and outputs (frag outs) from pipeline have the indirection

  10. #10
    Advanced Member Frequent Contributor
    Join Date
    Apr 2009
    Posts
    578
    Combing the forums, one can see lots of stuff that was stated in Suggestion for next release of GL found there way into GL4.3:
    • Texture views (though I strongly suspect that it was in the draft specs before it appeared as a suggestion)
    • The decoupling of vertex attribute source and format
    • explicit uniform location
    • read stencil values from depth-stencil texture
    • ability to query in's and outs of shaders and programs
    • arbitrary formatted to structure writes to buffer objects from shaders (I freely confess that what I was begging for was NVIDIA's GL_NV_sahder_buffer_load/store but what is delivered in GL4.3 is still great)


    Really happy about the spec rewrite/reorg.

Posting Permissions

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