Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Graphics Technology

OpenGL ES 3.2 & New Extensions Unveiled 46

Posted by Soulskill from the onward-and-upward dept.
An anonymous reader writes: With kicking off ACM SIGGRAPH '15, The Khronos Group came out with several big announcements, including the release of OpenGL ES 3.2 (which incorporates Android AEP functionality), confirmation that Google will support Vulkan on Android (when released), new desktop OpenGL extensions, and updates to the existing OpenCL 2.0 specification. They stopped short of releasing the heavily anticipated Vulkan Graphics API and also refrained from releasing a new desktop OpenGL version. They hope to have the Vulkan specification and its implementations released before year's end.
This discussion has been archived. No new comments can be posted.

OpenGL ES 3.2 & New Extensions Unveiled More

OpenGL ES 3.2 & New Extensions Unveiled

Comments Filter:

  • The whole draw of OpenGL was that developers could just add in the effects they wanted and allow users to turn them on/off to improve looks/performance. You weren't reliant upon the static/unflexible capabilities of APIs like D3D.

    Now they're just playing the copycat game, and ignoring their biggest strength, to truly push GPU hardware to the limit.

    What a fucking joke.

    • Re: (Score:2, Informative)

      by Anonymous Coward

      "developers can still use individual features if they’d like"

      Third paragraph. [anandtech.com]

      Feature sets are in addition to individual features. In any case, pushing the latest GPU hardware to the limit is the entire point of playing on a PC, instead of waiting several years for the next generation of console.

      • Re: (Score:2)

        by Khyber ( 864651 )

        Individual Features? Present or not-present?

        Is OpenGL still focusing on being extensible as shit while being minimal, or are they playing the feature-creep game with DX12, which is what I'm implying?

        It used to be games running OpenGL or 3Dfx GLide needed FAR LOWER requirements for the same game to run vs D3D. Unreal Tournament 1999, for example. With a 3Dfx or OpenGL card, you could haul ass on a shit 4 or 6 MB card, maxed everything, on a 133MHz Pentium MMX with 16MB RAM. And it looked great. For D3D, you

        • Re:OpenGL has lost its way (Score:5, Interesting)

          by beelsebob ( 529313 ) on Monday August 10, 2015 @11:41AM (#50285389)

          Believe it or not, the world of graphics hardware and APIs has moved on substantially since 1999. What was a good API design then, is now far from it. These days, you can get an order of magnitude speed improvement from two major API changes from the current OpenGL one:
          1) Drop the state machine, and require states to be specified (and hence verified, and compiled) up front, rather than via a series of changes during drawing.
          2) Drop the inbuilt thread safety, and require the users of the API to implement correct thread safety themselves.

          These two changes together make a very very significant difference to the performance you can get out of a CPU/GPU pair. There's a very good reason why Microsoft went that way with D3D, Apple went that way with Metal, AMD went that way with Mantle, and now Kronos is going that way with Vulkan.

          • Re: (Score:2)

            by Bengie ( 1121981 )
            Vulkan is based on Mantle. They whole-sale lifted nearly all of the API signatures and just renamed them. Kronos explicitly stated that they do not create new APIs, the only define established ones. They are followers, not leaders.

          • 2) Drop the inbuilt thread safety, and require the users of the API to implement correct thread safety themselves.

            There was thread safety? I'm sure I remember OpenGL having "interesting" bugs if you used multiple threads in the same context even back in the 1.4 days.

            • Re: (Score:2)

              by spitzak ( 4019 )

              You are required to use a different context per-thread, so of course you got "interesting" bugs using the same context.

              However even if you used different contexts there are bugs in the drivers (or hardware) so it did not work.

            • OpenGL has a bunch of implicit locks and blocking operations that do not need to be blocking. For example, if you have a font atlas, and you know that for frame 1, you only need to be able to access the glyphs for 'a', 'n' and 'd', but for frame 2, you know you'll also need 'y', 'u' and 'o', frame 2's texture upload would block any draw calls from accessing the texture (or it would block until those draw calls had completed). There is no way to avoid this in OpenGL, even if you yourself have knowledge tha

        • Re: (Score:2)

          by Bengie ( 1121981 )
          Vulkan shouldn't need to be extensible. I'm sure there will be a few exceptions, but I don't expect nearly as many. The old API needed to do most of the work, so implementation was important. Vulkan now expect the game engine to do the implementation and to communicate near-directly with the GPU. Extending Vulkan would be akin to extending x86 to make your program work. Someone may want to may a new SIMD, but it should be very rare to need a new extension.

        • OpenGL specification development continues to focus heavily (but not exclusively) on efficiency. Direct State Access is one of many examples of that - not yet present in ES, but expected for ES 4

    • Re: (Score:2)

      by Xrikcus ( 207545 )

      Maybe, though from the point of view of the engine devs pushing Vulkan, I think their goal here is to push GPU hardware to its limit in a way that GL made difficult, in particular by removing driver overhead and complexity that vendors couldn't ever hope to optimise.

    • Re: (Score:2)

      by Bengie ( 1121981 )

      The whole draw of OpenGL was that developers could just add in the effects they wanted

      It is also its greatest weakness. There are two independent sets of developers, the graphic driver developers and the developers who actually use the API. The graphic developers may love that they can extend OpenGL to make use of their random new fangled features in their graphics card, but the developers actually using the API now need to check for some huge number of custom extensions that may or may not exist.

      The whole point of a standard API is for there to be a standard! either you follow the standa

      • There are two independent sets of developers, the graphic driver developers and the developers who actually use the API.

        And the OpenGL extension methodology serves both. Developers can utilize the new features of new GPUs when they know what they are targeting and developers targeting broader audiences use core profiles.

        The graphic developers may love that they can extend OpenGL to make use of their random new fangled features in their graphics card

        That's good, you don't want to have to wait until a new feature is incorporated into the standard before you can use it.

        but the developers actually using the API now need to check for some huge number of custom extensions that may or may not exist.

        No they don't, that's what the core profile is for. If you want to target a broad audience then use that.

    • The whole draw of OpenGL was that developers could just add in the effects they wanted and allow users to turn them on/off to improve looks/performance. You weren't reliant upon the static/unflexible capabilities of APIs like D3D.

      Except that the world changed and most of the "effects" shifted away from the underlying fixed function pipeline and into the programmable hardware which removed the inflexibility.

      Now they're just playing the copycat game, and ignoring their biggest strength, to truly push GPU hardware to the limit.

      This is about pushing GPU hardware to the limit, they are removing the generic resource management implementations that reside in the driver and force applications to suffer significant overhead by being unoptimized (hence the reason drivers are so large and that driver releases often include optimizations for AAA titles). The GPU

  • Here's a quick demo [imgtec.com] we've written for SIGGRAPH that compares Vulkan and OpenGL ES performance for Android on a prototype driver.

  • I'm quite amazed that Vulkan will support all versions of Windows from XP onwards. So you can have the low overhead of DirectX 12 without forcing your users to upgrade to Windows 10.
    I can see a lot of game developers migrating to Vulkan, just because they get more sales the more OS versions they support

    • I'm quite amazed that Vulkan will support all versions of Windows from XP onwards. So you can have the low overhead of DirectX 12 without forcing your users to upgrade to Windows 10.
      I can see a lot of game developers migrating to Vulkan, just because they get more sales the more OS versions they support

      I can see Sony caving and going with Vulkan for their next box instead of doing their own thing once again. By that point Direct3D is going to be looking just a little bit funky, being the last roll-yer-own funky API standing.

  • Every time I set out to learn OpenGL, I just get put off by how fucked up it is. Not necessarily just being low level, but the sheer disrespect of host programming language, standardization and modern design practices. It's OK to use float[] instead of ByteBuffer. Textures can be objects instead of integers. Modern GPUs can handle one modern standard compressed texture format with alpha. Maybe one day I will find a decent wrapper that takes away unnecessary grant work. Until then I will just look for more s

    • It's OK to use float[] instead of ByteBuffer

      Well the underlying datatype is an array of floating point values, if you have a language-specific wrapper around OpenGL then maybe for your language a ByteBuffer makes sense and nothing precludes doing that.

      Textures can be objects instead of integers.

      But what you are referring to isn't a texture, it is a texture id which is why it is an integer.

      Modern GPUs can handle one modern standard compressed texture format with alpha.

      Not sure what you mean there.

Slashdot Top Deals

Beware of all enterprises that require new clothes, and not rather a new wearer of clothes. -- Henry David Thoreau

Close