Arm Community
Arm Community
  • Site
  • User
  • Site
  • Search
  • User
  • Groups
    • Arm Research
    • DesignStart
    • Education Hub
    • Innovation
    • Open Source Software and Platforms
  • Forums
    • AI and ML forum
    • Architectures and Processors forum
    • Arm Development Platforms forum
    • Arm Development Studio forum
    • Arm Virtual Hardware forum
    • Automotive forum
    • Compilers and Libraries forum
    • Graphics, Gaming, and VR forum
    • High Performance Computing (HPC) forum
    • Infrastructure Solutions forum
    • Internet of Things (IoT) forum
    • Keil forum
    • Morello Forum
    • Operating Systems forum
    • SoC Design and Simulation forum
    • 中文社区论区
  • Blogs
    • AI and ML blog
    • Announcements
    • Architectures and Processors blog
    • Automotive blog
    • Graphics, Gaming, and VR blog
    • High Performance Computing (HPC) blog
    • Infrastructure Solutions blog
    • Innovation blog
    • Internet of Things (IoT) blog
    • Mobile blog
    • Operating Systems blog
    • Research Articles
    • SoC Design and Simulation blog
    • Smart Homes
    • Tools, Software and IDEs blog
    • Works on Arm blog
    • 中文社区博客
  • Support
    • Open a support case
    • Documentation
    • Downloads
    • Training
    • Arm Approved program
    • Arm Design Reviews
  • Community Help
  • More
  • Cancel
Arm Community blogs
Arm Community blogs
Graphics, Gaming, and VR blog Here comes OpenGL ES 3.1!
  • Blogs
  • Mentions
  • Sub-Groups
  • Tags
  • Jump...
  • Cancel
More blogs in Arm Community blogs
  • AI and ML blog

  • Announcements

  • Architectures and Processors blog

  • Automotive blog

  • Embedded blog

  • Graphics, Gaming, and VR blog

  • High Performance Computing (HPC) blog

  • Infrastructure Solutions blog

  • Internet of Things (IoT) blog

  • Operating Systems blog

  • SoC Design and Simulation blog

  • Tools, Software and IDEs blog

Tell us what you think
Tags
  • khronos
  • OpenGL
  • opengl_es_3.1
  • opengl_es
Actions
  • RSS
  • More
  • Cancel
Related blog posts
Related forum threads

Here comes OpenGL ES 3.1!

Tom Olson
Tom Olson
March 17, 2014
As I write this, I’m packing my bag for a week in San Francisco, where I’ll be attending the Game Developer’s Conference (GDC). GDC is always a blast, especially now that there’s a big ARM Mali presence, but never more so (for me at least) than this year. The reason is simple; in my role as Khronos OpenGL ES Working Group chair, I’ll have the honor of announcing OpenGL ES 3.1, the latest version of the world’s most widely deployed 3D graphics API. It’s the culmination of a year of very hard work – mostly by other people, but I’m proud to say I was in the room when the work got done. And, of course, I’m deeply grateful to those who did it. In this blog, I’ll give a personal perspective on what OpenGL ES 3.1 is and why it's important.

What’s in it?

OpenGL ES 3.1 isn’t as obviously a big deal as its predecessor, OpenGL ES 3.0, which added over two dozen major features, and extended both the API and the shading language in almost every possible direction. After all, ES 3.0 took five years to create, and was intended to drive hardware requirements for a new generation of mobile GPUs. ES 3.1, on the other hand, was done in about a year, and is explicitly designed to run on most if not all existing ES 3.0-capable hardware. It’s no wonder that by comparison, it looks like a relatively modest advance. But is it? Here’s my view:

Many of the features in the new API amount to filling in gaps in ES 3.0 (bitfield operations in the shading language! Multidimensional arrays!), and continuing our efforts (which began in ES 3.0) to tighten the specification, improve application portability across implementations, and reduce application and driver overhead.  Don’t get me wrong, these features are very important – they make life much better for programmers, leading ultimately to more, better, and cooler applications for everyone. And I can tell you, specifying and testing them is hard (and essential) work.  But they’re kind of hard to appreciate unless you’re a standards geek, or a graphics programmer.


However, I claim that OpenGL ES 3.1’s headline features are going to change the way we do mobile graphics, in ways that will be obvious to everyone. For my money, there are two that stand out; first, it adds compute shaders, which allow the GPU to be used for general-purpose computing, tightly coupled with GPU-based graphics rendering. Second, it adds indirect drawing commands, which allow the GPU to read drawing command parameters from memory instead of receiving them directly from the CPU. I’ll explain why that’s important in a moment.

GPU Compute in OpenGL ES 3.1

Compute support in OpenGL ES 3.1 consists of a handful of new features that sound minor when considered individually, but have huge implications when combined.  (This happens all the time in the tech industry. Hypertext is a way of linking related documents and data (remember HyperCard?), and the internet is a (large) group of networked computers that agree to exchange data using a standard set of protocols.  Put them together, and you get the World-Wide Web, which is a different animal altogether.) 

The first critical compute feature OpenGL ES 3.1 adds is direct access to memory: shader programs can read and write arbitrary data stored in memory buffers or texture images.  The second critical feature is a set of synchronization primitives that allow applications to control the ordering of memory accesses by different threads running in parallel on the GPU, so that results don’t depend on what order the threads run in. The third is the ability to create and dispatch compute shaders, programs for the GPU whose invocations correspond to iterations of a nested loop rather than to graphics constructs like pixels or vertices.

With these features, you can do things like this: Create a 2D array in GPU memory representing points on a piece of cloth, and global data representing objects or forces acting on the cloth. Dispatch a compute shader that creates a thread for every point in the array.  Each thread reads the position and velocity of its point on the cloth, and updates them based on the forces acting on the cloth.


cropped-2014-03-13-110649.pngFigure 1: A rather nice carpet, animated by an ES 3.1-style compute shader, has a frightening encounter with a big shiny flying donut. Photo (and demo) courtesy of Sylwester Bala, Mali Demo Team. You can watch the video here.

Indirect Drawing

Indirect drawing sounds even more innocent than the various features that support GPU computing; it just means that the GPU can accept a drawing command whose parameters (such as how many items to draw, and where to find their vertices) are stored in memory, rather than passed as function-call arguments by the CPU.  What makes this interesting is that the memory buffer containing the parameters is fully accessible to the GPU – which means that a compute shader can write them. So for example, an application can fire off a compute shader that generates geometry data into a vertex buffer object, and also fills in an indirect drawing command that describes that data. After the compute shader finishes, the GPU can proceed to render the geometry as described in the buffer, without any additional work by the application or the CPU.

Winding Up

There’s other interesting stuff in OpenGL ES 3.1, but I’m out of space to talk about it. By the time you read this, the official specification will be available in the Khronos OpenGL ES registry, and there’ll be lots of information floating around following GDC presentations by myself and my fellow Working Group members. Incidentally, if you’re attending GDC, I hope you’ll stop by the ARM booth or one of our technical talks, and/or come to the Khronos OpenGL ES session, where we’ll walk through the OpenGL ES 3.1 specification in detail.

When will you see ES 3.1 in consumer devices? It’s up to the device makers, of course; but the Khronos conformance test should be up and running by this summer, and the API is meant to run on existing OpenGL ES 3.0 hardware, so it shouldn’t be terribly long. It will certainly be supported* on the ARM Mali Midgard GPUs.

As always – got comments or questions? Drop me a line!

Anonymous
Parents
  • Lori Kate Smith
    Offline Lori Kate Smith over 8 years ago

    Hi Tom,

    Here's a nice demo the Mali guys did on Open GL ES 3.1 so all can see what you're discussing.

    It's on a Samsung Electronics Galaxy Note 10.1 based on Exynos Octa 5 (5420)

    • Cancel
    • Up 0 Down
    • Reply
    • More
    • Cancel
Comment
  • Lori Kate Smith
    Offline Lori Kate Smith over 8 years ago

    Hi Tom,

    Here's a nice demo the Mali guys did on Open GL ES 3.1 so all can see what you're discussing.

    It's on a Samsung Electronics Galaxy Note 10.1 based on Exynos Octa 5 (5420)

    • Cancel
    • Up 0 Down
    • Reply
    • More
    • Cancel
Children
No Data
Graphics, Gaming, and VR blog
  • Style transfer for graphics post-processing on mobile

    Pavel Rudko
    Pavel Rudko
    This blog explains how developers can implement style transfer for graphics post-processing on mobile, in particular neural style transfer.
    • March 24, 2022
  • Analyzing ray traced content with Arm Mobile Studio

    Geraint North
    Geraint North
    This blog describes how Arm Mobile Studio can analyze ray traced content, with this being showcased via OPPO Find X5 pro smartphones at GDC 2022.
    • March 15, 2022
  • Using Adaptive Performance for the “Amazing Adventures of Dr. Arm”

    Joe Rozek
    Joe Rozek
    This blog explores Unity's Adaptive Performance and how it was applied to an internal Arm gaming title that will be showcased at GDC 2022.
    • March 14, 2022