OpenGL 4.4 and OpenCL 2.0 Specs Released

← Back to Stories (view on slashdot.org)

OpenGL 4.4 and OpenCL 2.0 Specs Released

Posted by Unknown on Tuesday July 23, 2013 @08:03AM from the supercomputer-in-a-slot dept.

Via Ars comes news that the OpenGL 4.4 and OpenCL 2.0 were released yesterday. OpenGL 4.4 features a few new extensions, perhaps most importantly a few to ease porting applications from Direct3D. New bindless shaders have access to the entire virtual address space of the card, and new sparse textures allow streaming tiles of textures too large for the graphics card memory. Finally, the ARB has announced the first set of conformance tests since OpenGL 2.0, so going forward anything calling itself OpenGL must pass certification. The OpenCL 2.0 spec is still provisional, but now features a memory model that is a subset of C11, allowing sharing of complex data between the host and GPU and avoiding the overhead of copying data to and from the GPU (which can often make using OpenCL a losing proposition). There is also a new spec for an intermediate language: "'SPIR' stands for Standard Portable Intermediate Representation and is a portable non-source representation for OpenCL 1.2 device programs. It enables application developers to avoid shipping kernel source and to manage the proliferation of devices and drivers from multiple vendors. OpenCL SPIR will enable consumption of code from third party compiler front-ends for alternative languages, such as C++, and is based on LLVM 3.2. Khronos has contributed open source patches for Clang 3.2 to enable SPIR code generation." For full details see Khronos's OpenGL 4.4 announcement, and their OpenCL 2.0 announcement. Update: 07/23 20:17 GMT by U L : edxwelch notes that Anandtech published notes and slides from the SIGGRAPH announcement.

66 comments

Min score:

Reason:

Sort:

Better Article by edxwelch · 2013-07-23 08:11 · Score: 5, Informative

There's a better article here:
http://www.anandtech.com/show/7161/khronos-siggraph-2013-opengl-44-opencl-20-opencl-12-spir-announced
1. Re:Better Article by Anonymous Coward · 2013-07-23 08:30 · Score: 1
  
  The author of that Anandtech story wrote the following in response to a question about the feature gap between DX11.2 and OpenGL 4.4;
  
  At a high level the two are roughly equivalent. With compute shaders in OpenGL 4.3 there is no longer a significant feature gap for reimplmenting D3D11 in OpenGL. I didn't cover this in the article since it's getting into the real minutia, but 4.4 further improves on that in part by adding a new vertex packing format (GL_ARB_vertex_type_10f_11f_11f_rev) that is equivalent to one that is in D3D. Buffer storage also replicates something D3D does.
  Glad to see OpenGL at parity, or close to it, with Microsoft's 3D stack. One wonders if that is due to the huge growth in OpenGL utilization by mobile platforms, even though those often use only embedded OpenGL profiles.
2. Re:Better Article by Kjella · 2013-07-23 10:41 · Score: 1
  
  Glad to see OpenGL at parity, or close to it, with Microsoft's 3D stack. One wonders if that is due to the huge growth in OpenGL utilization by mobile platforms, even though those often use only embedded OpenGL profiles.
  Well, that depends on what level you're talking about. At the bottom level is of course the hardware, which will have the exact same features so on the top level declaring an API that does the same is not that hard. The hard part is everything in the middle, which is why OpenGL is now up to version 4.4 while Mesa (the open source implementation) still only supports version 3.1 from March 2009, so that "feature parity" OpenGL version is only available using proprietary blobs. What the packing formats and such are about though is really neither top nor bottom, it's about using the same kind of primitives (textures, shaders etc.) in the same way as DirectX, not because it provides any additional functionality but just to make 1:1 reimplementations easy.
  To take one such example from OpenGL 3.1 ARB_fragment_coord_conventions, in traditional OpenGL the first pixel is lower-left, in DirectX upper-left. Before that extension, you had to rewrite everything to match the coordinate system, now you just say it's using DirectX-style coordinates and pass it right through. It makes transitioning between the two easier if you're writing for example a cross-platform game engine and it particularly helps things like WINE, but mostly it's just happening because it's the same hardware down below - there's no good reason why the calling conventions should need to be different or why you can't support the same format in both languages. The other part is whether the OpenGL stack is as optimized as the DirectX stack, correctness is just a part of the equation.
  
  --
  Live today, because you never know what tomorrow brings
3. Re:Better Article by Bengie · 2013-07-23 11:47 · Score: 1
  
  I've been a pro-DX11 guy, but GO OpenGL. Nice. I hope some new Linux Steam game comes out to make use of this stuff soon(tm).
4. Re:Better Article by gman003 · 2013-07-23 11:56 · Score: 2
  
  They're essentially at parity because they're matching, for the most part, the features of the underlying hardware. It's a weird give-and-take - Microsoft likes to dictate features, but their DirectX team is smart enough (now) to dictate features that at least one of the GPU companies is already implementing - essentially, they ask Nvidia what they're adding, ask AMD what they're adding, then add both of them to Direct3D and tell them both to implement it (and since they're both watching each other's moves anyways, this doesn't really change much). OpenGL takes a less leading role in adding features - they're usually added first as a vendor-specific extension (meaning Nvidia gets to dictate how it works and is used, and the extension has their name as a prefix). Then they standardize it as an ARB (Architecture Review Board) extension - make it more generic, less designed for one specific piece of hardware, and thus much easier for others to implement. Finally, if it's becoming a standard feature, they'll add it to the core language. OpenGL takes a more leading role in obsoleting older functionality, or in designing the OpenGL ES variants of the language. But they leave the cutting edge to the hardware people.
  So that's why OpenGL "trails" Direct3D by a hair - they follow the hardware a bit less closely. But they're both close enough that they're essentially feature-compatible, for modern stuff (this is all completely wrong for OpenGL 2.0 / DirectX 8 or lower).
5. Re:Better Article by Anonymous Coward · 2013-07-23 14:06 · Score: 1
  
  I've been a pro-DX11 guy, but GO OpenGL. Nice. I hope some new Linux Steam game comes out to make use of this stuff soon(tm).
  I've been a pro OpenGL guy forever but only because I found it easier to play with and more open but we all knew DirectX was massively better at this stuff for years. I've spent the last 3 months relearning everything i know to go from 1.x to 3.3 to 4.0 code. It actually is very fun to throw weeks to years worth of work away as l realize i'm years behind and of course it is extremely powerful on all the levels DirectX is now with respect to talking to a GPU. It still is sort of like banging your head on a rock at times and the tools are all over the place and my personal opinion is it all makes it much harder to learn but thank god it is finally happening!
  What got me all excited is seeing the same shaders used on real applications being reused in a web application. Forget texturing is still a problem when modern games require gigs of space but hey it doesn't take much to get me excited!
OpenCL by i+kan+reed · 2013-07-23 08:13 · Score: -1

OpenGL is great, but for trying to be a modern language for writing applications, OpenCL seems a little stuck on old, bad C conventions. Someone should tell the devs that just because they're stuck writing in assembly and C, not every user wants to.
1. Re:OpenCL by Anonymous Coward · 2013-07-23 08:18 · Score: 2, Insightful
  
  If you can't understand C, you have no business touching the GPU or even calling yourself a programmer.
2. Re:OpenCL by kthreadd · 2013-07-23 08:22 · Score: 3, Insightful
  
  Nothing wrong with C, but you don't really need to limit your self to it just because the code is running on the GPU. Have a look at C++ AMP for example.
3. Re:OpenCL by i+kan+reed · 2013-07-23 08:24 · Score: 1
  
  Of course I understand C. I just DONT_WANT_TO_DEAL_WITH_INT_CONSTANTS, when modern type safe enums exist, and other pointless annoyances that are conventional in C.
4. Re:OpenCL by Anonymous Coward · 2013-07-23 08:26 · Score: 0
  
  >When i started programming 20 years ago i was told the following:
  If you can't understand Assembly, you have no business touching the CPU or even calling yourself a programmer.
  Just Because something is hard doesn't mean it's good.
5. Re:OpenCL by Anonymous Coward · 2013-07-23 08:28 · Score: 0
  
  10 print "Basic For The Win!!!"
  20 End
6. Re:OpenCL by Anonymous Coward · 2013-07-23 08:29 · Score: 0
  
  Nothing wrong with C, but you don't really need to limit your self to it just because the code is running on the GPU.
  The portion of the code running on the GPU in OpenCL isn't C.
7. Re:OpenCL by kthreadd · 2013-07-23 08:38 · Score: 0
  
  It's true that it's not C, but the way it's designed make it look like C.
8. Re:OpenCL by Anonymous Coward · 2013-07-23 08:39 · Score: 0
  
  Why can I run a kernel for CUDA in 3 lines of code but I need 2000 lines for running an opencl one?
  Why at one point you had to have your kernel in comments ffs? http://developer.apple.com/library/mac/#samplecode/OpenCL_Hello_World_Example/Listings/hello_c.html
  OpenCl is retarded.
9. Re:OpenCL by Anonymous Coward · 2013-07-23 08:40 · Score: 0
  
  Of course I understand C. I just DONT_WANT_TO_DEAL_WITH_INT_CONSTANTS, when modern type safe enums exist, and other pointless annoyances that are conventional in C.
  There is nothing magical about type safety in a programming language. If you want type safety in C compile with type checking warning turned on. Any C compiler can tell you when you are using different types.
10. Re:OpenCL by Anonymous Coward · 2013-07-23 08:41 · Score: 0
  
  comment/string my bad
11. Re:OpenCL by i+kan+reed · 2013-07-23 08:42 · Score: 1
  
  There's nothing magical about type safety, you know, except for the confidence that the setting your assigning relates at all the value you're using.
12. Re:OpenCL by cheesybagel · 2013-07-23 08:44 · Score: 1
  
  OpenCL requires a lot of boilerplate code to initialize resources and whatever. But the code is a lot more machine portable than CUDA.
13. Re:OpenCL by Musc · 2013-07-23 08:44 · Score: 4, Insightful
  
  Except for the fact that CUDA only works on nvidia devices, and OpenCL works on everything...
  
  --
  Hamsters are at least as feathery as penguins. HamLix
14. Re:OpenCL by Anonymous Coward · 2013-07-23 08:48 · Score: -1
  
  Don't care. CUDA is better.
15. Re:OpenCL by Anonymous Coward · 2013-07-23 08:51 · Score: 0
  
  OpenCL requires a lot of boilerplate code to initialize resources and whatever.
  Not really. You just have to find the device(s) you want to use, then use them per their specs that they make available.
  
  But the code is a lot more machine portable than CUDA.
  Yes. It runs on AMD and even Intel, though Intel has some terrible drivers. (I'm looking at you, whoever thought adding install directory to PATH with their internal Qt version DLLs was a Good Idea!)
16. Re:OpenCL by Musc · 2013-07-23 08:51 · Score: 1
  
  And who cares what is best if you can't use it?
  
  --
  Hamsters are at least as feathery as penguins. HamLix
17. Re:OpenCL by Anonymous Coward · 2013-07-23 08:56 · Score: 0
  
  Until you want to debug or run things fast.
  You want portability? Use a framework.
18. Re:OpenCL by DeKO · 2013-07-23 08:58 · Score: 1
  
  The gpuocelot project has been able to run CUDA in non-NVIDIA hardware for some time now, including x86 CPUs and AMD GPUs.
  Too bad the CUDA compiler often segfaults on ordinary C++ libraries even when they are host-only (in which case nvcc is supposed to just forward it to GCC). Hopefully the LLVM-based compiler for OpenCL 2.0 won't be as buggy.
19. Re:OpenCL by Anonymous Coward · 2013-07-23 09:03 · Score: 0
  
  Why can I run a kernel for CUDA in 3 lines of code but I need 2000 lines for running an opencl one?
  How well do those 3 lines of code work when you are on an AMD or Intel GPU?
  CUDA and the people that use it are retarded.
20. Re:OpenCL by cheesybagel · 2013-07-23 09:05 · Score: 2
  
  In my experience CUDA is not any faster than OpenCL. Frameworks don't solve the problem properly. There are a lot of debugging tools for OpenCL my guess is you did not look hard enough. You can run OpenCL programs without installing all the cruft required to do CUDA development since the driver will compile and run code by itself. This means a lot of people don't bother looking for tools but they are out there.
21. Re:OpenCL by cheesybagel · 2013-07-23 09:16 · Score: 3, Informative
  
  There are also several mobile devices (smartphones, tablets) running ARM which have OpenCL support and zero CUDA support. Not to mention that it is also a web standard namely WebCL.
22. Re:OpenCL by Anonymous Coward · 2013-07-23 09:28 · Score: 0
  
  Indeed. A functional language like Haskell would be so much better suited, it's not even funny. No side effects is *key* in being able to parallelize things. Because you can trust that the same input will *always* give the exact same output.
  And the whole architecture is designed for a function-based model anyway. Look at shaders. They are basically huge expressions. Just like functional code.
23. Re:OpenCL by Anonymous Coward · 2013-07-23 09:40 · Score: 0
  
  You think that defining an IR is a sign of being stuck with C? The goal is clearly to open up the standard to a wide range of languages. C++ AMP is just a compiler front on top of DX IL It's a tool (which happens to implement a standard library) on top of a well defined intermediate layer.
24. Re:OpenCL by Anonymous Coward · 2013-07-23 09:45 · Score: 0
  
  There's nothing magical about type safety, you know, except for the confidence that the setting your assigning relates at all the value you're using.
  If you want type safety in C compile with type checking warning turned on.
25. Re:OpenCL by plover · 2013-07-23 10:00 · Score: 1
  
  Constants aren't type safe.
  
  --
  John
26. Re:OpenCL by Anonymous Coward · 2013-07-23 10:13 · Score: 0
  
  If you can't understand C, you have no business ... even calling yourself a programmer.
  So I guess the hundreds of other programming languages don't count?
27. Re:OpenCL by Anonymous Coward · 2013-07-23 10:21 · Score: 0
  
  I can use it. I have Nvidia GPUs.
28. Re:OpenCL by Anonymous Coward · 2013-07-23 11:12 · Score: 0
  
  Because CUDA does that for you?
  Any specific reason why you couldn't hide all that behind a library for opencl?
  A quick Wikipedia search shows e.g. boost.compute, asgard, etc.
29. Re:OpenCL by Anonymous Coward · 2013-07-23 11:42 · Score: 0
  
  Give him a break. He misspelled "assembly".
30. Re:OpenCL by Bengie · 2013-07-23 12:01 · Score: 1
  
  Understanding C typically means understanding memory layout. Most other languages use managed memory, so it does make a lot of sense.
  
  Anyway, optimal memory access patterns for GPUs are completely different, so you'd better change your loops.
31. Re:OpenCL by gman003 · 2013-07-23 12:05 · Score: 2
  
  Well, let's look at the use cases for OpenCL right now:
  * Scientific computing, at levels from workstations to supercomputers
  * Games that need to offload stuff too parallel for the CPU to handle, or for code that needs to run on the GPU as the output will be used by other GPU code (streaming texture decompression is a common task).
  * Video transcoders, encoders and decoders
  * Bitcoin miners (obligatory Bitcoin reference: check!)
  All of those are fields where performance is a very high priority - in some cases, above even correctness. They're also fields for experts - if you don't know how to program at essentially the assembly level, you won't make it in the field. So is it harder? Sure. But this is stuff where you can't just wave a magic wand and make it easy - it's tough because massively multi-threaded programming is intrinsically difficult.
32. Re:OpenCL by Anonymous Coward · 2013-07-23 15:18 · Score: 0
  
  Yes really. After finding the device you want to use, you still have to create buffers, manage kernel strings, build program objects, set kernel arguments, manage the queue, events, errors, reads, writes and so on.
  It's like having to build a vehicle every time you want to go somewhere. Faster than walking, once it's built, but it is a lot of unnecessary bother to have to build something every time.
  APIs like C++AMP and Bolt can reduce that boilerplate requirement, though, while building on all of OpenCL's good stuff.
33. Re:OpenCL by Anonymous Coward · 2013-07-23 17:04 · Score: 0
  
  So I guess the hundreds of other programming languages don't count?
  Those hundreds on other programming languages are the reason we have been saddled with slow, bloated and inefficient programs for the last 30 years.
34. Re:OpenCL by K.+S.+Kyosuke · 2013-07-23 21:08 · Score: 1
  
  You can completely circumvent this problem by simply writing correct code.
  
  --
  Ezekiel 23:20
35. Re:OpenCL by K.+S.+Kyosuke · 2013-07-23 21:12 · Score: 1
  
  Don't care. CUDA is better.
  Define "better".
  
  --
  Ezekiel 23:20
36. Re:OpenCL by K.+S.+Kyosuke · 2013-07-23 21:14 · Score: 1
  
  Why can I run a kernel for CUDA in 3 lines of code but I need 2000 lines for running an opencl one?
  You need to use clut, just like you would use glut with OpenGL.
  
  --
  Ezekiel 23:20
37. Re:OpenCL by K.+S.+Kyosuke · 2013-07-23 21:15 · Score: 1
  
  If you can't understand C, you have no business ... even calling yourself a programmer.
  So I guess the hundreds of other programming languages don't count?
  It's like calling yourself an international businessman and not knowing English. Yes, those hundreds of other programming languages actually don't count in this case.
  
  --
  Ezekiel 23:20
38. Re:OpenCL by K.+S.+Kyosuke · 2013-07-23 21:40 · Score: 2
  
  No side effects is *key* in being able to parallelize things. Because you can trust that the same input will *always* give the exact same output.
  Actually, that's mostly irrelevant. That could be useful for memoization, but it's not a sufficient condition for parallelization - if you take it to the logical conclusion, you're asking for nothing more than a computer that is reliable, which is an assumption you do for most computer programs, so you're asking for a very weak property. The key to parallel computing is the associativity of individual operations. Other properties that are of lesser help are commutativity, idempotency (basically the thing you've mentioned), and the existence of zeros and identities, but it's associativity that is vital. If you can do (((1+2)+3)+(4+5))+((6+7)+(8+(9+10))) instead of ((((((((1+2)+3)+4)+5)+6)+7)+8)+9)+10, you win big. If you can't, you lose.
  
  --
  Ezekiel 23:20
39. Re:OpenCL by K.+S.+Kyosuke · 2013-07-23 21:47 · Score: 1
  
  You forgot generic creative image processing - stuff like Photoshop, Shake, Nuke, etc. Although, in these areas, you probably don't write the kernels by hand - you're most likely generating them from pipelines, trees, or DAGs of atomic image processing operations "on the fly" from the internal data structures describing what needs to be done (which you do mostly to reduce all the slow random memory accesses).
  
  it's tough because massively multi-threaded programming is intrinsically difficult.
  Only in weak programming paradigms.
  
  --
  Ezekiel 23:20
40. Re:OpenCL by serviscope_minor · 2013-07-23 21:54 · Score: 1
  
  You can completely circumvent this problem by simply writing correct code.
  Well, I'm sure super human awesome coders like yourself can. The rest of us fallible mortals enjoy having tools to automatically catch mistakes without adding any overhead or verbosity. I'll bet you "simply write correct code" so there's no need to test before pushing it to the production server, right?
  
  --
  SJW n. One who posts facts.
41. Re:OpenCL by serviscope_minor · 2013-07-23 21:59 · Score: 1
  
  They can be in C++11: strongly typed enums.
  
  --
  SJW n. One who posts facts.
42. Re:OpenCL by K.+S.+Kyosuke · 2013-07-23 22:00 · Score: 1
  
  You *routinely* program in C things that you "push to production servers"? Exactly *how much* free time do you have on your hands?
  
  --
  Ezekiel 23:20
43. Re:OpenCL by serviscope_minor · 2013-07-24 00:04 · Score: 1
  
  Exactly *how much* free time do you have on your hands?
  I have literally no idea what you are talking about. You were decrying type safety because you could "simply write correct code".
  If that's possible, then there is no reason to ever test anything because it will "simply be correct".
  And yeah, I do test stuff before pushing it to production servers, though no, I do not use C these days.
  
  --
  SJW n. One who posts facts.
44. Re:OpenCL by plover · 2013-07-24 02:50 · Score: 1
  
  Sorry, what I first meant was that #defined macros in C are not at all typesafe (which is the claim the GGG[G*]P was ignoring), but also that not all "ints" should be considered compatible. While it may be syntactically correct and safe to add "int milesPerGallon" and "int averageAgeOfRockStars", semantically it's nonsense. Defining these as distinct types of "miles" and "years" would enable the type system to save a developer from making that mistake.
  
  --
  John
45. Re:OpenCL by Anonymous Coward · 2013-07-24 06:43 · Score: 0
  
  Or CLU, or simply the OpenCL C++ bindings which cover all of the boilerplate except stringification. Wrapping boiler plate in library code is hardly rocket science.
co3k by Anonymous Coward · 2013-07-23 08:30 · Score: -1

of variOuS BSD
1. Re:co3k by jones_supa · 2013-07-23 08:43 · Score: 1
  
  In almost every Slashdot article for the past century I have seen this mysterious message which includes random words with "BSD" there somewhere. Who is the stubborn party behind these spams and how can they still get through?
2. Re:co3k by Anonymous Coward · 2013-07-23 10:58 · Score: 0
  
  Dunno, and the motivation? strange try to demote BSD in search engine rankings? If they index slashdot and they mind modding...
the important question by brodock · 2013-07-23 09:31 · Score: 1

the important question is... when we will see it delivered on Linux drivers?
1. Re:the important question by Anonymous Coward · 2013-07-23 10:09 · Score: 0
  
  Wait a couple of years at least.
2. Re:the important question by dindinx · 2013-07-23 10:53 · Score: 1
  
  If you use an NVidia card, yesterday, it seems: https://developer.nvidia.com/opengl-driver
  On the other hand, AMD only publised catalyst drivers for OpenGL 4.3 today.
  
  --
  DindinX
Conformance tests developed along with spec by GNUThomson · 2013-07-23 10:06 · Score: 2

That's surprisingly uncommon among standardization organizations. I wish IETF could do the same for RFCs...
Will OpenCL 2.0 be valid if NVidia don't support i by Anonymous Coward · 2013-07-23 10:13 · Score: 0

NVidia, who own the 50% of the GPU market and have the most advanced GPU architectures ( K20 ) are still on OpenCL 1.1. They haven't released a version of OpenCL 1.2. It's a shame as a good OpenCL 2.0 or 1.2 release will grow the overall category of GPU's. If NVidia actively support OpenCL it gives the market a sign of security that GPUs are useful beyond games and graphics.
So when will NVidia implement OpenCL 2.0 ??
NVidia not that important. by tuppe666 · 2013-07-23 10:21 · Score: 2, Interesting

NVidia, who own the 50% of the GPU market
Not even close NVidia has 18% of the GPU market with Intel at 61.8% and AMD at 20.2%. NVidia is less prolific than you think. Basically 80% of the market can implement it without Nvidia. I don't think they want to do that.
1. Re:NVidia not that important. by Anonymous Coward · 2013-07-23 15:37 · Score: 0
  
  It's arguable that NVidia own a pretty big chunk of the discrete GPU market.
  One could also argue that Intel own 0% of the GPU market, because you can't just buy an Intel GPU.
  Anyway, you can see how these things are trending here: http://www.investorvillage.com/smbd.asp?mb=476&mn=263502&pt=msg&mid=12790483
  From that, we can infer that people who like GPUs don't want Intel GPUs, and that half the market for OpenCL is getting CUDA handed to them instead.
2. Re:NVidia not that important. by Anonymous Coward · 2013-07-23 21:14 · Score: 0
  
  Yeah sure, if you segment the market enough, you can really make it look good. Hey, I understand nVidia own 100% of the market for discrete GPU's which come in predominantly green boxes and have the word "nVidia" on them!
Citations needed! by EzInKy · 2013-07-23 10:42 · Score: 1

NVidia, who own the 50% of the GPU market...
Just where did you get that data point!? Most everything I've seen retail wise has Intel graphics inside while few come with NVidia's stuff, and those that do come at a premium price.

--
Time is what keeps everything from happening all at once.
Re:Will OpenCL 2.0 be valid if NVidia don't suppor by Anonymous Coward · 2013-07-23 17:44 · Score: 0

The fucking summary is stupid as usual. OpenGL 4.4 is out (NVidia has beta drivers for it already) but for OpenCL:

release of the OpenCL 2.0 provisional specification
then TFA goes on to say

The release of the specification in provisional form is to enable developers and implementers to provide feedback before specification finalization, which is expected within 6 months.
So give it a few months.
Another new version of OpenGL? by Anonymous Coward · 2013-07-24 00:02 · Score: 0

Does anyone understand why Khronos keeps releasing new versions of OpenGL? If there was adoption of the previous versions by hardware vendors and software developers that would be one thing, but from what I can see there isn't. Only Nvidia seems to support the version released last year (4.3). Apple and Intel seem to be stuck using versions from many years ago (3.x). As for software developers I don't know of any apps that use OpenGL 4.x, and very few that use OpenGL 3.x (we plan to continue using OpenGL ES 2.0 for years since that has the broadest adoption).
My understanding is in standard bodies like Khronos all the involved companies get a vote. It would be interesting to understand how they keep getting a majority of the members to approve these new specs because it just doesn't seem to make sense to me.