Overview
This technique implements tile based deferred shading using OpenCL for the lighting stage.
In the image above you can see 1024 point lights combined with diffuse albedo. A skybox was used to illustrate the background, which is reflected using environment mapping on a spere. The human figure that you can see in the middle is only used for showcasing purposes. The original can be downloaded from here:
http://thefree3dmode...ed_i/14-1-0-564

Motivation & other implementations
I was very impressed by the 2010 Siggraph presentation by Intel, in which they showcased the same technique using DirectX 11 compute shaders:
http://software.inte...ring-pipelines/
Unfortunately the demo was implemented in DirectX so it only runs on Windows, so I decided to implement a cross platform version of it in OpenCL (and OpenGL). My version runs on Linux, Windows and possibly on Mac too if I had a Mac and ported it.
Frostbite 2 by Dice also implements this technique via DirectX 11 compute shaders.
http://www.frostbite2.com/?page_id=50
I also found a similar, but slower implementation of this technique on Mac:
http://www.idevgames...hread-8649.html

Implementation details
The implementation contains two types of light attenuations: one linear and one full (constant, linear, quadratic) and uses the Blinn-Phong lighting model. The scene contains 1024 point lights, but spot lights and directional lights could be easily implemented as well.
The G-buffer consists of:
RGBA for diffuse albedo (the alpha channel is free currently but could be used for storing per pixel specular intensity)
RG16F for normals that are encoded using spheremap projection:
http://aras-p.info/t...malStorage.html
R32F for linear depth, because OpenCL doesn't support reading from hardware depth buffer yet:
http://mynameismjp.w...n-from-depth-3/
That is total 96 bits per pixel, which is about 11 MB in 720p and 25MB in 1080p. Possibly an additional buffer will be added for storing further material properties.

The OpenCL kernel outputs the result into a RGBA16F buffer. This is needed since OpenCL doesn't support RGB texture format yet. A possible optimization could be to output the result into a RG16F containing the red and the green channels, and a R16F buffer for the blue channel.
This is needed because using floating point buffers enable the usage of gamma correct effects (such as bloom, HDR, tone mapping etc.)

About the performance
I ran it on a AMD Radeon HD 5670 GDDR3 1GB and it did around 40-50 FPS on average.
On a AMD Radeon HD 5770 GDDR5 1GB, which has twice the power it ran around 80-100 FPS.
The Intel implementation performed around 140-160 on the 5770, and 60-80 on the 5670. [s]But note that my implementation uses deferred shading (+at least 32 bits per pixel!), while Intel's uses deferred lighting.[/s] Intel's implementation uses deferred shading too, but still optimization could add a lot to the performance. To add my implementation is currently not optimized yet.

Why this technique?
So why did I choose this implementation over the traditional deferred lighting techniques?
First of all deferred shading becomes eventually faster when scene complexity reaches a critical level when it becomes a bottleneck to render it twice. Secondly the traditional quad or geometry based deferred lighting techniques aren't very efficient due to they have to use several passes to calculate the lighting. Also with this technique no light geometry is needed to be actually rendered. To add since almost every modern game engine contains a view frustum culling technique, performance can be even further increased by pre-culling lights against the view frustum, so less lights need to be uploaded to the GPU memory and processed eventually. Furthermore, with OpenCL, one is capable of doing per-architecture optimizations. This enables doing severe optimizations where needed, the mid-range video cards: AMD's VLIW5 and 4, or NVIDIA's Fermi architecture. Lastly, since both NVIDIA and AMD are focusing on increasing general purpose GPU performance with their latest GPU generations (the newest GCN and the [s]upcoming[/s] Kepler) it is possible that this technique will achieve serious speedup just by running it on those video cards.

Check out the video as well! (note that the quality is bad because of youtube and the capturing software)

Click here to view the iotd