The shade of things to come

Update (15/10/2013): Microsoft has just announced via an official blog post that the Xbox One will not support Mantle as a programming API.


At GPU14 AMD announced the new Mantle low-level API for their GCN architecture. Anandtech has a pretty good analysis of the presentation, along with some insights of what Mantle could mean for the GPU market.

The announcement left me shocked, but not because I was not expecting such a move; far from it. Actually I had foresaw this some months ago, and I was pleased to see that I got pretty much every detail right... Except for one. A very crucial one.

The landscape above Mantle

We still know very little about the Mantle API.  AMD claims it will allow developers to implement performance critical sections closer to the metal on their GCN chips, without the performance penalty of higher level APIs like OpenGL and Direct3D.

AMD claims that this is a growing need from graphic developers, and I totally copy that; with the "G" in GPU progressively shifting from meaning "Graphics" to mean "Generic", the abstraction gap between OpenGL and the underlying architecture has gradually grown.

Also, AMD is in an interesting market position nowadays, as both the Microsoft Xbox One and the Sony Playstation 4 will feature a GPU based on their GCN architecture.  The Nintendo Wii U hosts an AMD GPU as well, but it's not based on GCN.

The Mantle API is thus intended to squeeze every last graphics performance drop from Xbox One, Playstation 4 and PCs equipped with a AMD GPU, and making porting between these platform easier.

Could the Mantle API be implemented for other GPUs as well?  Probably not while maintaining its intended prime focus on efficiency: from what it can be inferred from the AMD presentation, the Mantle API is strictly tied to the GCN architecture.

History repeating?

The history of graphics programming has a notable precedent of a platform-specific API: Glide.  It was a low-level API that exposed the hardware of the 3dfx Voodoo chipset, and for a long time it was also the only way to access its functionalities.  Thanks to 3dfx' hardware popularity, Glide was widespread, with Glide-only game releases not being uncommon.

While the Mantle API is as platform-specific as Glide was, the present context is much different: OpenGL and Direct3D are now mature, and the ultimate purpose of the new project is likely to complement existing APIs, offering a fast path for critical sections, rather than replacing them.

The other side of today's gaming

It's clear that AMD is trying to leverage its position as a GPU supplier across the PC and console markets.  However, there's another GPU vendor that is going to be in a similar position in the near future: earlier this year, in a SIGGRAPH event that suprisingly got very little press, NVIDIA demonstrated its own Kepler GPU architecture running on Tegra 5, their next generation low power SoC aimed to mobile devices.

So, both vendors have one foot in the PC market, while keeping the other one in the console market for AMD and in the mobile one for NVIDIA.  This is far from being a balanced situation, because console market has shrunk massively during the last years, and the momentum is on mobile gaming right now.  Asymco has a detailed summary of the current situation, along with some speculation about the future I don't fully agree with.

If NVIDIA manages to be a first choice for Steam Boxes, as it's clearly trying to be, and put the Tegra 5 on a relevant base of mobile devices, the Kepler architecture would become the lingua franca between PC and mobile gaming, as much as AMD hopes GCN to do between PC and console gaming.

At that point introducing a platform specific API, both to offer developers the extra edge on their hardware and to lock out competitors, starts to make a lot of sense.

In the end, that was the detail I got wrong: the vendor that API would come from first :)

Book review: OpenGL Development Cookbook

I was proposed to review the latest book from Packet Publishing: OpenGL Development Cookbook.  This post is a slightly expanded version of the review I've already published on two major book review websites.

I had great expectations when I first opened this book.  In fact, I feel there is a big void right in the middle of published books about OpenGL.

At one side of the void there are either technical references or introductory texts, which explain the reader how to properly use the library but don't show practical applications: at the end of those books people know how to texture lookup from a vertex shader, not how to render realistic terrain from a height map.

At the other side there are collections of articles about very advanced rendering techniques, intended for people already well versed in graphics programming and hardly of any use for the everyday developer (think about the ShaderX or the GPU Pro series).

The premise of this book is to be the gap filler, which tells you about all the cool things you can do with OpenGL (in addition to rendering teapots) in a wide range of topics, while remaining practical enough for the average OpenGL developer.


While it's a good shot in that direction, it doesn't live up to this ambitious premise.


Let's start with what's good: recipes cover a vast range of applications, including mirrors, object picking, particle systems, GPU physics simulations, ray tracing, volume rendering and more.

OpenGL version of choice is 3.3 core profile, so all the recipes are implemented using modern OpenGL while still being compatible with most GPU hardware out there.  Every recipe comes with a self-contained and working code example that you can run and tweak. All examples share coding style and conventions, which is great added value.

The toolchain of choice is Visual Studio for Windows, but the examples also build unmodified on Linux installations.  Despite Mac OS X only supporting up to OpenGL 3.2, examples not requiring 3.3 features will build there as well with minor modifications (just be sure to use included GLUT.framework rather than freeglut, as the latter relies on XQuartz which isn't able to request an OpenGL 3 context).


Then, there's something that just doesn't work well.  First, the formatting of code excerpts is terrible: long lines wrap twice or thrice with no leading spaces, so without highlighting it's nigh impossible to read the code right at first glance:

glm::mat4 T = glm::translate( glm::mat4(1.0f),
glm::vec3(0.0f,0.0f, dist));
glm::mat4 Rx=glm::rotate(T,rX,glm::vec3(1.0f, 0.0f,
0.0f));
glm::mat4 MV=glm::rotate(Rx,rY,
glm::vec3(0.0f,1.0f,0.0f));

Given that a good 30% of this book is code, this is really something that should be addressed in a second edition.

A somewhat deeper problem is about how recipes are presented.  Most of them dive directly in a step-by-step sequence of code snippets, taking little time to explain the required background and the overall idea behind the implementation.  On a related note, the book states that knowledge of OpenGL is just a "definite plus" to get through it, but after the very first recipe spends a total of three lines explaining what Vertex Array Objects are, before jumping into code that uses them, it becomes clear that being proficient with OpenGL is a requirement to appreciate the book.

The quality of the recipes varies a lot through the book: the best written and most interesting ones are from chapters 6, 7 and 8, which comes as no surprise as the author's research interests include the topics they cover.  I would have exchanged many of the previous recipes, some of which are variations on the same theme, to be about techniques that both fit the recipe format and are relevant for any up-to-date rendering engine (depth of field, fur, caustics, etc...).  On a related note, I think that perhaps the single biggest flaw of the book is that it's written by a single author, but to offer 50 great recipes a cookbook needs several ones, each master in her own trade and each offering the best of her knowledge.


In the end: if you're already well versed in OpenGL, have interest in the specific topics best covered by the author, and you're going to read each recipe at the computer to comfortably read code, OpenGL Development Cookbook has something to offer.  While not the gapfiller I was initially looking for, the learning opportunity from having a code example for each recipe is remarkable.