Kicking off this week is the annual SIGGRAPH conference, the graphics industry’s yearly professional event. Outside of the individual vendor events and individual technologies we cover throughout the year, SIGGRAPH is typically the major venue for new technology and standards announcements. And though it isn’t really a gaming conference – this is a show dedicated to professional software and hardware – a number of those announcements do end up being gaming related, if only tangentially. As a result SIGGRAPH offers something for everyone in the graphics/GPU trident, gaming, compute, and professional rendering alike.

Most years the first major announcement to hit the wire comes from the Khronos Group, and this year is no different. The Khronos Group is of course the industry consortium responsible for OpenGL, OpenCL, WebGL, and other open graphics/multimedia standards and APIs, so their announcements carry a great deal of importance for the industry. Khronos membership in turn is a who’s who of technology, and includes virtually every major GPU vendor, both desktop and mobile.

OpenGL 4.4 Specification Released

Khronos’s first announcement for SIGGRAPH 2013 is that the OpenGL 4.4 specification has been ratified and released. This being the 5th edition of OpenGL 4.x, Khronos has continued iterating on OpenGL in concert with their pipelined development process. OpenGL 4.4 follows up on OpenGL 4.3, which last year broke significant ground for OpenGL by introducing compute shaders, ASTC texture compression, and other new functionality for the API.

This year Khronos isn’t making such sweeping changes to OpenGL, but they are adding several new low-level features that should catch the eyes of developers. Most of these are admittedly so low level that it would be difficult for anyone but developers to appreciate, but there are a few items we wanted to go over for their importance and for wider reflection of the state of OpenGL.

The biggest feature hitting the OpenGL core specification in 4.4 is buffer storage (ARB_buffer_storage). Buffer storage is directly targeted at APUs, SoCs, and other GPU/CPU integrated devices where the two processors share memory pools, address space, and other resources. Buffer storage at its most basic level allows developers to control where memory buffer objects are stored in these unified devices, giving developers the ability to specify whether buffers are stored in video memory or system memory, and how those buffers are to be cached. The buffer storage mechanism in turn also formally allows GPUs to access those buffers not being stored locally, giving GPUs a degree of visibility into the contents of system memory where it’s necessary. Like most Khronos additions this is a forward looking feature, with a clear outlook towards what can be done with HSA and HSA-like products that are due to be launching soon.

Khronos’s other major addition with OpenGL 4.4 is enhanced layouts for the OpenGL Shader Language (ARB_enhanced_layouts). The name on this is somewhat self-explanatory in this case, with enhanced layouts dealing with ways to optimize the layout of data in shader programs for greater efficiency. This includes new ways of packing scalar datatypes alongside vectors, and giving developers more control of variable layout inside uniform and storage blocks. Support for constant variables in qualifiers at compile-time is also added through this extension.

Moving on from the OpenGL core, in keeping with the OpenGL development pipeline several new features are being added as official ARB extensions, being promoted (and modified/unified as necessary) from vendor specific extensions. Chief among these new ARB extensions are extensions to support sparse textures (ARB_sparse_texture) and bindless textures (ARB_bindless_texture). You may recognize these features from the launch of AMD’s Radeon HD 7000 series and NVIDIA’s GeForce GTX 600 series respectively, as these two extensions are based on the new hardware features those products introduced and are the evolution of their previous forms as vendor specific extensions.

Sparse textures, also known as partially resident textures, give the hardware the ability to only keep tiles/chunks of textures in resident memory, versus having to load (and unload) whole textures. The most practical application of this technology is to enable megatexture-like texture management in hardware, loading only the necessary tiles of the highest resolution textures; however for professional developers this also opens up a new usage scenario by allowing the use of textures larger than the physical memory of a card, allowing for the use of larger textures without restriction by memory constraints.

Meanwhile bindless textures functionality does away with the concept of texture “slots” and the limits imposed by the limited number of slots, replacing the fixed size binding table with unlimited redirection through the use of virtual addresses. The primary benefit of this is that it allows the easy addition and use of more textures within a scene (under most DX11 hardware this limit was 128 slots), however there is also a performance angle to this. Since binding and rebinding objects is a task that relies on the CPU, getting rid of binding altogether can improve performance in CPU limited scenarios. Khronos/NVIDIA throws around a 10x best-case number, and while this is certainly the exception rather than the rule it will be interesting to see what the real world benefits are like once applications start coming out utilizing this feature.

Ultimately both of these features, along with several other ARB extensions, are in the middle of their evolution. The ARB extension stage is essentially a half-way house for major features, allowing features to be further refined and analyzed after being standardized by the ARB. The ultimate goal here is for most of these features to graduate from extensions and become part of the core OpenGL standard in future versions, which means if everything goes smoothly we’d expect to see sparse texture support and bindless texture support in the core standard (and the devices that support it) in the not too distant future.

Finally, in a move that should have developers everywhere jumping with joy, OpenGL finally has official and up to date conformance tests. OpenGL has not had an up to date conformance test since the project was led by SGI almost a decade ago, with the task of developing the tests being a continual work in progress for many years. In the interim the lack of conformance testing has been an obstacle for OpenGL, as there wasn’t an official way to validate implementations against known and expected behaviors, leading to more uncertainty and bugs than anyone was comfortable with.

Now with the completion of the new conformance tests, OpenGL implementations can be tested for their conformance, and in turn those implementations will now need to be conformant before they are approved by Khronos. For developers this means they will be writing software against better devices and drivers, and for device makers they will have an official target to chase rather than having to interpret the sometimes ambiguous OpenGL standards.

OpenCL SPIR 1.2: An Intermediate Format For OpenCL
Comments Locked

28 Comments

View All Comments

  • chris81 - Monday, July 22, 2013 - link

    Standing for Standard Portable Interface Representation -> Intermediate Representation
  • Ryan Smith - Monday, July 22, 2013 - link

    Aww geeze. Thanks for catching that. Fixed.
  • iwod - Tuesday, July 23, 2013 - link

    Hopefully within a year or two we should finally see some adoption into OpenCL acceleration. Which i have yet to see much software using it. ( May be CPU today is already fast enough for 95% of what we need. )

    Does OpenGL 4.4 matters? Do Microsoft Still support it on Windows ( I remember there were words on dropping support etc i didn't remember what turns out )
    And Apple, even with their unreleased OSX Maverick has ONLY just updated to OpenGL 4.0
    ( Yeah this is depressing )

    So the most important OpenGL would be OpenGL ES, where it is dominating / monopolizing the mobile world. Why isn't there any update on it?
  • Klimax - Tuesday, July 23, 2013 - link

    OpenGL is implemented by GPU vendors and connecting into graphics subsystem using provided interfaces.
    http://msdn.microsoft.com/en-us/library/windows/ha...
  • Krysto - Tuesday, July 23, 2013 - link

    What do you mean? They've just updated it to Open GL ES 3.0 last year. They won't update ES every year.

    That being said, with Nvidia starting to use the full OpenGL in mobile next year, I think Khronos needs to release ES 4.0 next year, so the other GPU chip makers can catch-up a bit, since adopting the full OpenGL 4.3/4.4 might be too hard for them. Nvidia had to use its PC architecture to do that, and even Intel on its latest Haswell for notebooks and PC's doesn't support more than 4.0, which they barely adopted at the last moment, too.

    So either Khronos gives the others ES 4.0 to work with, or the other mobile GPU makers will be literally *years* behind future Tegra devices, when it comes to graphics capability.
  • przemo_li - Thursday, July 25, 2013 - link

    Geometry shaders, and tesselation shaders consume much power and that was reason why they did not landed in OpenGL ES 3.0. It will be interesting to see if Nvidia can come up with some good solution here.

    (Also Intel is utilizing Mesa drivers for their Android efforts, those are already at full OGL 3.1, and 3.2/3.3 should come this year.)
  • Codeledger - Tuesday, July 23, 2013 - link

    As someone who is following Google's GPGPU efforts with Renderscript, it looks like OpenCL 2.0 and OpenCL SIPR are trying to address some of the issues brought up by the Android team. I would be curious to know if the various vendors are using Renderscript as a test bed DSL or in the future will Android adopt and expose OpenCL formally.
  • Wwhat - Sunday, July 28, 2013 - link

    New in OpenCl: DRM type crap

    No need to worry though, we keep the word 'open' in the name...for 'your' convenience.

Log in

Don't have an account? Sign up now