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 3 of 6 FirstFirst 12345 ... LastLast
Results 21 to 30 of 59

Thread: Official feedback on OpenGL 4.2 thread

  1. #21
    Junior Member Regular Contributor
    Join Date
    Jun 2000
    Location
    Cambridge, England
    Posts
    190

    Re: Official feedback on OpenGL 4.2 thread

    ARB_shader_image_load_store is a really big deal! Shaders can scatter as well as gather which is going to enable some interesting techniques.
    I'm just wondering how it will perform - has anyone given it a try yet?

  2. #22
    Senior Member OpenGL Pro Ilian Dinev's Avatar
    Join Date
    Jan 2008
    Location
    Watford, UK
    Posts
    1,290

    Re: Official feedback on OpenGL 4.2 thread

    Quote Originally Posted by Don't Disturb
    ARB_shader_image_load_store ...
    - has anyone given it a try yet?
    OIT stuff,
    and http://www.opengl.org/discussion_boa...393#Post296393

  3. #23
    Advanced Member Frequent Contributor
    Join Date
    Dec 2007
    Location
    Hungary
    Posts
    985

    Re: Official feedback on OpenGL 4.2 thread

    Wow, I'm just back from holiday and here we have GL 4.2.

    Very nice update with a lot of useful features, even though only about half of the features I wanted to see in GL 4.2 were actually added.
    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/

  4. #24
    Member Regular Contributor
    Join Date
    Apr 2006
    Location
    Irvine CA
    Posts
    299

    Re: Official feedback on OpenGL 4.2 thread

    Quote Originally Posted by aqnuep
    Very nice update with a lot of useful features, even though only about half of the features I wanted to see in GL 4.2 were actually added.
    By repeating this process over time, the feature set will asymptotically approach your needs!

  5. #25
    Advanced Member Frequent Contributor
    Join Date
    Dec 2007
    Location
    Hungary
    Posts
    985

    Re: Official feedback on OpenGL 4.2 thread

    I know that. Obviously they had some real tough extensions to discuss this time (I mean here especially the ARB_shader_image_load_store and ARB_shader_atomic_counters, even though the later was already almost complete a half year ago).

    Anyway, what maybe we can say at least now with confidence is that GL 4.2 achieved feature parity with DX11 (at least from point of view of exposed hardware capabilities).
    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/

  6. #26
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948

    Re: Official feedback on OpenGL 4.2 thread

    Obviously they had some real tough extensions to discuss this time (I mean here especially the ARB_shader_image_load_store and ARB_shader_atomic_counters, even though the later was already almost complete a half year ago).
    Actually, I'd guess that most of the discussion was around ARB_shading_language_420pack and ARB_texture_storage. The former is really a merger of what seems like a half-dozen extensions, which much have been in development.

    And ARB_texture_storage introduces functionality that I'm sure some in the ARB saw as superfluous. After all, there's nothing you can do with ARB_texture_storage that you can't with regular texture creation. And the immutability must have rubbed some of the more conservative elements the wrong way.

    Anyway, what maybe we can say at least now with confidence is that GL 4.2 achieved feature parity with DX11 (at least from point of view of exposed hardware capabilities).
    Honestly, it's not "feature parity" that interests me so much as "niceness parity". And 420pack really, really helps. Shaders are much more robust and stand-alone. And the last of the horrible 3D Labs-based nonsense is finally expunged from GLSL. It only took 10 revisions of the language and 6 years.

    Also, I've come to appreciate why it's one extension instead of a half-dozen. If it were many extensions, then those using GL 3.3 would have to have a giant list of #extension enable lines at the top of every shader. That would be pretty terrible. This way, you just have one extension (or two if you're using pack) and that's it.

  7. #27
    Advanced Member Frequent Contributor
    Join Date
    Dec 2007
    Location
    Hungary
    Posts
    985

    Re: Official feedback on OpenGL 4.2 thread

    Quote Originally Posted by Alfonse Reinheart
    Actually, I'd guess that most of the discussion was around ARB_shading_language_420pack and ARB_texture_storage. The former is really a merger of what seems like a half-dozen extensions, which much have been in development.
    I agree that ARB_shading_language_420pack is very important as I was also very frustrated by the way how you attach bindings to uniforms as an example. However, atomic counters were even more important, I think, as without it we simply cannot implement OIT and other stuff efficiently. And before anybody tries to argue, atomic read/writes exposed by EXT_shader_image_load_store and now also by the ARB version is not equivalent with atomic counters. Atomic counters are more than 10 times faster than atomic read/writes on AMD hardware as they have special hardware for it, and it is also faster on NVIDIA as well.

    Honestly, it's not "feature parity" that interests me so much as "niceness parity". And 420pack really, really helps. Shaders are much more robust and stand-alone. And the last of the horrible 3D Labs-based nonsense is finally expunged from GLSL. It only took 10 revisions of the language and 6 years.
    Yeah, that's also important, however I'm more interested first in being able to solve a problem than how nicely I can solve it (no, I'm not saying that solving a problem elegantly is less important, however, functioning software has priority over that).

    Also, I've come to appreciate why it's one extension instead of a half-dozen. If it were many extensions, then those using GL 3.3 would have to have a giant list of #extension enable lines at the top of every shader. That would be pretty terrible. This way, you just have one extension (or two if you're using pack) and that's it.
    Good point as well, even though the name is kind of funky, it's better to have just a single extension.

    Update: Actually I'm also very happy to see ARB_base_instance as this was a functionality that was present in hardware for quite some time but even ARB_draw_indirect didn't expose the functionality earlier. This is one of my favorites, even though the name glDrawElementsInstancedBaseVertexBaseInstance sounds a bit ridiculous Btw, I don't know why they didn't simply created two new functions with names like: glDrawElementsDirect and glDrawArraysDirect (analogous to the new indirect draw commands) which does the same like glDrawElementsInstancedBaseVertexBaseInstance and glDrawArraysInstancedBaseInstance. You can do all the glDraw* commands with these two by using proper parameters so people could migrate to the new commands and we could mark all the rest of glDraw* commands as deprecated. Also, it would be great to see glMultiDraw* versions as well (what we have at least for indirect drawing thanks to AMD_multi_draw_indirect).
    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/

  8. #28
    Member Regular Contributor malexander's Avatar
    Join Date
    Aug 2009
    Location
    Ontario
    Posts
    317

    Re: Official feedback on OpenGL 4.2 thread

    Thanks for promoting ARB_shader_load_store and the atomic counters, while adding useful features for older hardware. Expanding the shader bindings is great, though I'm still not a big fan of the layout syntax.

    However, the one ARB extension I do take issue with is ARB_internalformat_query - not for what it does, but for how it's named. In all instances of "query" in the registry, the use of query as a noun indicates a query object (ARB_occlusion_query, ARB_timer_query), whereas its use as a verb indicates a synchronous, object-less fetch of the information (ARB_texture_query_lod, OES_query_matrix). So at least it should be ARB_query_internalformat.

    Further to this, the extension doesn't actually query the internal format of a texture, which I was really hoping for when I saw it. Rather, it queries the supported multisample counts for a given internal format. In my opinion, the extension should have been called ARB_query_multisample. Sorry if this comes across as a bit pedantic, and I realize it's likely too late to do much about, but it felt misleading enough to me to point out in the feedback thread.

  9. #29
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948

    Re: Official feedback on OpenGL 4.2 thread

    If you check the issues for that extension, it was going to be much more ambitious, but they scaled it back for the current release.

    The name makes sense because it's providing a query mechanism for internal format information. It just doesn't do much with that mechanism yet.

  10. #30
    Member Regular Contributor malexander's Avatar
    Join Date
    Aug 2009
    Location
    Ontario
    Posts
    317

    Re: Official feedback on OpenGL 4.2 thread

    I saw that, but that still implies a future extension with a different name. Perhaps ARB_internalformat_query2, 3, etc. are coming, but the name still doesn't do much for the current extension.

Posting Permissions

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