Khronos Announces "Next" OpenGL & Releases OpenGL 4.5

Subject: General Tech, Graphics Cards, Shows and Expos | August 15, 2014 - 08:33 PM |
Tagged: siggraph 2014, Siggraph, OpenGL Next, opengl 4.5, opengl, nvidia, Mantle, Khronos, Intel, DirectX 12, amd

Let's be clear: there are two stories here. The first is the release of OpenGL 4.5 and the second is the announcement of the "Next Generation OpenGL Initiative". They both occur on the same press release, but they are two, different statements.

OpenGL 4.5 Released

OpenGL 4.5 expands the core specification with a few extensions. Compatible hardware, with OpenGL 4.5 drivers, will be guaranteed to support these. This includes features like direct_state_access, which allows accessing objects in a context without binding to it, and support of OpenGL ES3.1 features that are traditionally missing from OpenGL 4, which allows easier porting of OpenGL ES3.1 applications to OpenGL.

View Full Size

It also adds a few new extensions as an option:

ARB_pipeline_statistics_query lets a developer ask the GPU what it has been doing. This could be useful for "profiling" an application (list completed work to identify optimization points).

ARB_sparse_buffer allows developers to perform calculations on pieces of generic buffers, without loading it all into memory. This is similar to ARB_sparse_textures... except that those are for textures. Buffers are useful for things like vertex data (and so forth).

ARB_transform_feedback_overflow_query is apparently designed to let developers choose whether or not to draw objects based on whether the buffer is overflowed. I might be wrong, but it seems like this would be useful for deciding whether or not to draw objects generated by geometry shaders.

KHR_blend_equation_advanced allows new blending equations between objects. If you use Photoshop, this would be "multiply", "screen", "darken", "lighten", "difference", and so forth. On NVIDIA's side, this will be directly supported on Maxwell and Tegra K1 (and later). Fermi and Kepler will support the functionality, but the driver will perform the calculations with shaders. AMD has yet to comment, as far as I can tell.

View Full Size

Image from NVIDIA GTC Presentation

If you are a developer, NVIDIA has launched 340.65 (340.23.01 for Linux) beta drivers for developers. If you are not looking to create OpenGL 4.5 applications, do not get this driver. You really should not have any use for it, at all.

Next Generation OpenGL Initiative Announced

The Khronos Group has also announced "a call for participation" to outline a new specification for graphics and compute. They want it to allow developers explicit control over CPU and GPU tasks, be multithreaded, have minimal overhead, have a common shader language, and "rigorous conformance testing". This sounds a lot like the design goals of Mantle (and what we know of DirectX 12).

View Full Size

And really, from what I hear and understand, that is what OpenGL needs at this point. Graphics cards look nothing like they did a decade ago (or over two decades ago). They each have very similar interfaces and data structures, even if their fundamental architectures vary greatly. If we can draw a line in the sand, legacy APIs can be supported but not optimized heavily by the drivers. After a short time, available performance for legacy applications would be so high that it wouldn't matter, as long as they continue to run.

Add to it, next-generation drivers should be significantly easier to develop, considering the reduced error checking (and other responsibilities). As I said on Intel's DirectX 12 story, it is still unclear whether it will lead to enough performance increase to make most optimizations, such as those which increase workload or developer effort in exchange for queuing fewer GPU commands, unnecessary. We will need to wait for game developers to use it for a bit before we know.

August 15, 2014 | 11:34 PM - Posted by AMDBumLover (not verified)

mantle all da tings!

August 15, 2014 | 11:45 PM - Posted by JohnGR

If Chronos had moved 2 years earlier on the next gen OpenGL, they could have been the ones changing the computer graphics in PCs. Unfortunately they didn't and the next gen APIs is a windows story with Mantle and DX12. OpenGL now looks just a far behind third.

August 15, 2014 | 11:55 PM - Posted by Does (not verified)

They should just take Mantle and label it OpenGL next. Mantle provides an abstract-enough hardware interface to run all modern GPUs.


August 16, 2014 | 12:02 AM - Posted by Scott Michaud

That was pretty much what I expected to happen, honestly, apart from the sticking point of its reliance on HLSL (versus GLSL). Doubt it will now, though. Still think that AMD wants it to look as much like Mantle as they can get away with.

August 16, 2014 | 03:47 AM - Posted by renz (not verified)

but this is OpenGL that we're talking about. so AMD not the only player giving the input. they might be able to come up with something thing much better than Mantle.

August 16, 2014 | 12:54 PM - Posted by Scott Michaud

Or better in some ways but worse in others, et cetra. Hoping this is OpenGL's time to shine, though. The industry needs a good API that is governed by a society, not a single player.

August 16, 2014 | 04:42 AM - Posted by arbiter

well it DOESN'T run on all modern gpu's which looks like you forgot that. the REAL opengl does.

August 16, 2014 | 12:04 AM - Posted by Scott Michaud

Which doesn't mean anything, per se. Web standards were, like, twenty years behind native applications. Once the last few things get ratified, they're neck-and-neck.

August 16, 2014 | 12:04 AM - Posted by Anonymous (not verified)

OpenGL ES's days are numbered on the high end tablets, as the Nvidia K1, has support for the full desktop version of OpenGL, on the lower cost Tablets, and phones, ES will still be around and viable. ARB_sparse_buffer sounds good for laptops without more than 8 gigs of memory, those high polygon models can eat 8 gigs, without chewing at all, and the ARB_sparse_buffer and other functions that reduce all the memory stress, when working on datasets that always are larger than available RAM. And now that you mention the differences between Nvidia, and AMD graphics with respect to OpenGL and direct hardware support for some OpenGL functions, what about the first GPU to include Hardware Ray Tracing?

The PowerVR wizard has introduced Ray tracing, and this would be so great if it could spur AMD and Nvidia on to add some Ray Tracing to their products, the Main reason that graphics needs the costly workstation CPUs is that the CPU is currently where most of that ray tracing is done, and for CPU ray tracing more expensive multi cores/threaded CPUs are needed, but once the GPU cores, with their massive parallelism, get the ray tracing circuitry, then the need for the costly server CPUs is mostly over for graphics workloads. OpenCL is helping to take some of the Ray Tracing stress off of the limited CPU cores/threads, provided the software takes advantage of OpenCL, but dedicated ray tracing hardware in GPUs could even allow regular laptops to render like a workstation with multiple expensive server CPUs.

August 16, 2014 | 12:59 PM - Posted by Scott Michaud

From what I gather by Khronos statements, OpenGL ES is now, more-or-less, an on-ramp to full OpenGL support for a new wave of GPU manufacturers. It is a more gentle progression for mobile than, "Do everything, do it fast, do it efficient, and do it now!"

August 17, 2014 | 12:18 PM - Posted by Jabbadap (not verified)

How about google's android expansion pack, it will be part of android L. Do you think it could be merged next gen opengl(it's now opengles3.1+aep extensions). Or will it always be google's own little secret.

August 17, 2014 | 02:12 PM - Posted by Anonymous (not verified)

Well, Khronos will have both, so I Guess it's all good, but the Tablet OEM's are going to have to equal the Tegra K1's full OpenGL support if they want to sale devices based on non Tegra K1 based SOCs, so the Tablet SOC makers will have to go to full support for OpenGL quicker. Getting full Linux distros, and the Full desktop graphics applications working on K1 based devices should be much easier, as the driver rewrites will not have to remove any full OpenGL calls, and the drivers themselves will need little or no code refactoring, and Steam OS side loaded onto K1 based devices should be very easy. The K1 SOCs are the prime candidates for Full Linux based tablets, especially the Denver core based variant. AMD needs to get its Custom ARMv8 SKU to market ASAP, Because the Chromeooks, and Linuxbooks form factor devices market is just beginning, and SOCs like Nvidia's K1, And Apple's A8, may begin to be seen in more laptop types of devices, and Hopefully AMD will have an APU with its Graphics, and HSA, to compete, as these devices with, Better than Intel graphics, will be hot sellers.

The High Bar has been set by the green team, and the red team will need to counter with some custom ARMv8 tablet SKUs of its own, and these SOC's Graphics capability will be the what makes the winner. The ARMv8 custom Wider Order SOCs are already approaching the core i3s, in performance, and besting Intel's graphics at a much lower price point, and the Custom ARMv8 SOCs are doing great with the power usage, even while being fabricated on a 28nm process node, and competing favorably with non ARMv8 SOCs fabbed on 22nm. With OpenCL, and other GPGPU HALs/APIs, that extra GPU resource will be put to good work, for more than just gaming, with graphics software and productivity software using OpenCL as the main GPGPU accelerator API on tablets.

August 16, 2014 | 09:28 AM - Posted by Al Gore (not verified)

HMC im-memory processing and FPGA are the future.

AMD & Microsoft & IBM spend ton of money on this for the last 8 years. Nvidia and Intel licensed it. Nvidia canceled their own road map because of this tech. PC 2.0 tech.
Train has gone for OpenGL for 5 years too catch. Better start learn DX12 now.

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Lines and paragraphs break automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <blockquote><p><br>
  • Web page addresses and e-mail addresses turn into links automatically.

More information about formatting options

By submitting this form, you accept the Mollom privacy policy.