Last week, Khronos Group and, more specifically, the ARB released OpenGL 4.0. It’s been approximately six months since OpenGL 3.2 and less than a year since OpenGL 3.1. So ARB has been eager and working hard to get OpenGL up to speed with Direct3D. Maybe even a little too eager, one might think, as such a rapid pace of publishing new specification versions will most likely be confusing to the adopters. The developers are still barely using the 2.x line of the API, so adopting 4.0 can take a good while. Oh, and you need compatible drivers from HW vendors, too – something which will probably take a while as well.

Anyway, the spec is out and it’s time to take a look at what’s new. The new features include double precision floats, shader subroutines, instanced geometry shaders and arrays, as well as a heap of other new additions. Most importantly, however, OpenGL 4.0 introduces two new shader stages: sample shaders and tessellation shaders. The former enable the developers to have more control over sample operations, such as anti aliasing, while the latter offer mechanisms for programming the tessellation, e.g. LODing the geometry.

With these two new shader types, in addition to the already existing vertex, geometry and fragment shaders, it’s fair to say that most of the pipeline is now programmable. And if the developers are required to write shaders for most of the rendering pipeline anyway, why not write the entire pipeline by hand? This way you’d be able to implement any kind of rendering engine without having to deal with the limitations and rendering model of OpenGL. Think, for instance, non-triangle based rendering. This could solve the problem of having virtually every graphics-intensive game looking almost exactly the same. All you need is a mechanism for accelerating your “software renderer” on the GPU, which, of course, is called OpenCL.

Personally, I see no other way around the fact that developers want to customize every step of the rendering pipeline and the pipeline itself, than going back to writing “software rasterizers” and pushing them to the GPU using OpenCL or some such. This, of course, being only the intermediate step between the whole concept of a GPU and simply a mass of generic parallel computing power.

By the way, at least Tim Sweeney agrees with me.

About Symbio TechBlog

The Symbio TechBlog discusses topics related to convergence, software product development and user experience technologies as we see them evolve in the market and our daily lives. Our goal is to provide you with insights on demanding software challenges in different industries and establish an interactive forum for exchanging ideas and experiences.

Symbio has deep domain expertise in multiple industries ranging from IT, Telecommunication, Life Sciences, Automotive, and Industrial, all of which need to come to terms with the increased technological complexity in products and services. Driven by complex customers and end user demands, our experts aim to share their knowledge on a wide range of topics.

We welcome you to contribute and join our discussions!