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 6 123 ... LastLast
Results 1 to 10 of 59

Thread: Official feedback on OpenGL 4.2 thread

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

    Official feedback on OpenGL 4.2 thread

    The Khronos™ Group today announced the immediate release of the OpenGL® 4.2 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.2 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.2 specification has been defined by the OpenGL ARB (Architecture Review Board) working group at Khronos, and includes the GLSL 4.20 update to the OpenGL Shading Language. The OpenGL 4.2 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.

    New functionality in the OpenGL 4.2 specification includes:

    • ARB_shader_atomic_counters
      • GLSL built-in functions to query and increment/decrement atomic counters
      • Counters stored in buffer objects
    • ARB_shader_image_load_store
      • allow shaders to load from, store to, and perform atomic read-modify-write operations to a single level of a texture
    • ARB_texture_storage
      • Immutable textures
    • ARB_transform_feedback_instanced
      • Draw multiple instances of the result of a transform feedback
      • Without query and sync needed for DrawArraysInstanced()
    • ARB_shading_language_420pack
      • Collection of new GLSL features
    • ARB_texture_compression_BPTC
      • ARB extension since January 2010, promoted to core now
      • Same formats as BC6H/BC7 in DirectX 11
    • ARB_base_instance
      • Specify offset within buffer object for instanced drawing
    • ARB_internalformat_query
      • Find out supported number of samples per internal format
    • ARB_compressed_texture_pixel_storage
      • Modify an arbitrary subset of a compressed texture
    • ARB_shading_language_packing
      • allows GLSL shaders to read and write 16-bit floating-point encodings
      • Pack small data types into one larger one
    • ARB_map_buffer_alignment
      • Pointer returned is aligned for SSE/AVX CPU instructions
    • ARB_conservative_depth
      • Shader constructs that help enable depth testing before fragment processing


    Lastly, Khronos has simultaneously released a set of ARB extensions to enable as much OpenGL 4.2 core functionality as possible on previous generation GPU hardware; providing maximum flexibility and platform coverage for application developers.

    Learn more about what is new in OpenGL 4.2 at the BOF at Siggraph, Wed, Aug 10th from 4- 6PM in the Pan Pacific Hotel, Crystal Ballroom B&C. http://www.khronos.org/news/events/s...vancouver-2011
    Webmaster Khronos.org and OpenGL.org

  2. #2
    Super Moderator Frequent Contributor Groovounet's Avatar
    Join Date
    Jul 2004
    Posts
    935

    Re: Official feedback on OpenGL 4.2 thread


  3. #3
    Junior Member Newbie
    Join Date
    Sep 2010
    Posts
    2

    Re: Official feedback on OpenGL 4.2 thread

    there should be a gl_arb_ray_tracing in the traditional path :P

  4. #4
    Junior Member Regular Contributor
    Join Date
    Dec 2009
    Posts
    213

    Re: Official feedback on OpenGL 4.2 thread

    I have a quick question about the swizzle operators (Section 5.5 in the GLSL spec):

    The individual components can be selected by following the variable name with period ( . ) and then the component name.
    I always assumed that the swizzle operators can be used with any vector expression, not just variables (e.g. function results etc).

    If this is the case, can the swizzle operators now be used on constants too, e.g. (1.0).xxx or 1.0.xxx ?

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

    Re: Official feedback on OpenGL 4.2 thread

    In review:

    ARB_base_instance

    Not the sexiest of extensions. And "DrawElementsInstancedBaseVertexBaseInstance". .. really? There was no better alternative than that name?

    Man, that one giant glDraw function from Longs Peak with 20 parameters is starting to sound better and better

    ARB_transform_feedback_instanced

    Just a fix for lacking needed functionality.

    ARB_compressed_texture_pixel_storage

    I'm sure this is useful to someone. Just not me.

    ARB_conservative_depth

    I'm actually surprised that this one made it into the spec. It seems really low-level, but it has its place.

    ARB_internalformat_query

    I can't say I saw this coming. Though I have to say, it seems oddly named. It's more about multisample than internal formats. Though I suppose it could be extended later for other things, like asking if something is color-renderable.

    Though that begs the question as to why that wasn't added into this extension.

    ARB_map_buffer_alignment

    Simple. Direct. To-the-point. Does an important job.

    Good.

    ARB_shader_atomic_counters

    Didn't see this coming. After a cursory glance, the API seems reasonably well-specified and the functionality decent overall.

    ARB_shader_image_load_store

    Something so obvious that even I predicted it.

    ARB_shading_language_packing

    Meh. The functionality is fine and all, but it's not exactly blowing my skirt up.

    ARB_texture_storage

    Now we enter the realm of the bizarre.

    Immutable textures have been something the ARB has wanted for years. Yet it's taken them this long to get it.

    The behavior is very good, but I take some issue with how it's specified. It an API inconsistency.

    It's obvious at this point that the ARB does not want to just add direct state access. They only provide DSA-style functions when they add new functionality, as they did here.

    The problems are these. First, they provided old-style storage functions too. Why? I didn't see a big rush to provide old-style Sampler Object support. Yes, that's a new object type, rather than a modification of an older one. But it still feels inconsistent with the push towards DSA-style functions.

    More importantly is this. If you create a texture object with this extension, you are almost guaranteed to later make a SubImage call. It's the only way to upload data; that's part of the purpose of this extension, right?

    So... where is glTextureSubImage? You know, the DSA-style function that takes a texture object, not a type. If you call glTextureStorage2D, you have almost certainly not bound that texture to the context. So, you don't have to bind the texture to create the storage, but you have to bind the texture to upload to it? Doesn't that kinda defeat the purpose? Yes, I know you can use EXT_DSA, but if you don't want to (or the unlikely event that it's unavailable), what then?

    It just seems inconsistent that they would add a function that strongly suggests using another function, but then not make that function available. And it's not like the ARB didn't use ARB_separate_shader_objects to add in the DSA version of program uniform setting. So this wouldn't be the first time the ARB added convenience functions to the language.

    I do like the fact that you can specify compressed images without using different functions for them.

    ARB_shading_language_420pack

    AKA: ARB_glsl_doesnt_suck. Or ARB_glsl_is_cool_now.

    I've never been a fan of these sorts of "bag of stuff" extensions, where they just bundle a bunch of functionality together. This is mostly due to fears about what hardware they will be implemented on. For something like ARB_gpu_shader5, it's obvious what hardware it'll show up on. But for something like this, which is mostly hardware agnostic, it seems weird. Indeed, according to the revision history, this is a Frankenextension, formed from the bones of many extensions and animated with lightning.

    Fortunately, the extension's functionality seems to fit on GL 3.3-class hardware (though I wouldn't mind seeing a GL 3.4 that bundles this into core). A quick rundown of the bag of tricks:

    • Line continuation: Meh. Useful for #defines, but it doesn't exactly blow my skirt up.
    • UTF-8 encoding: Sure why not.
    • Implicit return value conversion: More banishing of stupid 3D Labs ideas. What hatred did those people have for implicit conversions anyway?
    • Local 'const' variables with non-compile-time 'const' expressions: What took you so long?
    • Qualifier ordering: Again, what took so long? GLSL has been accruing qualifiers like some kind of plague, but it's taken 9 revisions of the language to fix this?
    • Uniform block `binding` location: Of course!
    • Sampler unit `binding` location: See my comment on qualifier ordering.
    • Initializer list: Somebody's read the C++11 specification. Good for you.
    • Vector-type `.length`: Meh. If GLSL had templates or something, this might be useful, but I'm not sure I understand the purpose. Maybe for #define gimmickry.
    • Scalar swizzles: Again, what kept you?
    • Texel offset constants: Good


    As they say in the StarCraft community: "It's about time."

    ARB_faster_vertex_submission

    No, that's not a real extension. It's just a place to register my disappointment that nothing has been done on this front.

    ARB_separate_shader_objects

    I honestly can't believe the ARB didn't fix ARB_separate_shader_objects. It's not like there weren't four bugs filed on this extension.

    Yes, the last two are more "wish-list" than bugs (though I would say that they're more "this functionality is inconsistent with itself and poorly specified", which should count as a bug). And the ARB did fix the state tables in the 4.2 spec. But there is no excuse for GL_PROGRAM_SEPARABLE still not being listed in the program object state table.

    Why bother advertising the Bugzilla database if they're just going to ignore it? The ARB has plenty of ways to ignore commentary; did they really need another?

    Overall

    A solid block of functionality (though little hardware-based). Some really good things, some really odd things, but overall, it was good. But I've only had a cursory glance at the extensions. And ARB_separate_shader_objects has shown that the devil is in the details.

    So consider this a provisional grade of B+. Points were deducted for expecting me to type "DrawElementsInstancedBaseVertexBaseInstance", failure to address the vertex transfer issue, failure to bother to take an hour to read your bug list, and for not providing DSA-style texture uploading.

    Oh, and when are we getting deferred contexts?

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

    Re: Official feedback on OpenGL 4.2 thread

    Actually, I'm bumping that score up to A-. The quick reference card is very nice this time around. It even has a pipeline reference.

    Though I'm not sure if you can call it a "quick" reference if it has to have an index

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

    Re: Official feedback on OpenGL 4.2 thread

    Idea for the ARB:

    Many people would like a copy of the OpenGL specification in book form. Granted, I don't expect it to be a big seller, but there are some people who would certainly pay money for it. Just not enough to publish it.

    At least, not through a traditional publisher. But a less traditional publisher like Lulu Press would actually be a pretty decent idea. The PDF would always be available for free, and it doesn't cost much of anything to just make a "book" available through them. You could sell it for something like $20.00 or so.

    Everyone wins. The ARB gets a little extra pocket money. The users get to have the spec in book form reasonably inexpensively.

  8. #8
    Junior Member Regular Contributor
    Join Date
    Dec 2009
    Posts
    213

    Re: Official feedback on OpenGL 4.2 thread

    Hi Alfonse,

    i guess you did't see this paragraph of ARB_texture_storage:

    Dependencies on EXT_direct_state_access

    If EXT_direct_state_access is not present, references to TextureStorage* should be ignored.
    So the old-style TexStorage* functions are needed when you have no DSA extension.

  9. #9
    Junior Member Regular Contributor Heiko's Avatar
    Join Date
    Aug 2008
    Location
    the Netherlands
    Posts
    170

    Re: Official feedback on OpenGL 4.2 thread

    More OpenGL goodness. Very nice!

  10. #10
    Intern Contributor
    Join Date
    Aug 2009
    Posts
    66

    Re: Official feedback on OpenGL 4.2 thread

    No direct state access?
    What does Khronos has against that?
    Just add DSA counterparts of the non DSA stuff.

    And seriously why do they even continue to make this a minor version bump? The changes seem to better reflect a OpenGL 4.1.1 instead of OpenGL 4.2.

    This really hints at using the minor version number for big hardware generation changes and a third number after that for this kind of stuff. And you could use the major version number to change the api and the context creation calls while avoid breaking old software.


    And something about the following:

    ARB_shading_language_420pack

    I'm assuming the 420 stands for the shading language version 4.2.0 please use separators.

    Such as underscore (using underscores is the most consistent way I think) e.g.: ARB_shading_language_4_2_0_pack

    This way you won't have a problem when one of the numbers reaches 10 or higher. Which has been a big problem for at least one project a while back. (Don't remember what it exactly was. Just that they had problems with versions above 9.)

Posting Permissions

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