thoughts about computer graphics, game engine programming

Month: September, 2014

DX11 Catalyst Driver Performance over time

Something’s missing

So I’ve been looking around the internet for a post, or something in which I could see how the AMD and Nvidia drivers have improved over time. I definitely was certain that things like:

-they deliberately make the drivers worse so that you’d buy their new GPU

-the driver perf does NOT improve in real-world scenarios

are NOT true. From the OpenGL side I could already see that with each released AMD driver things get fixed, new features are implemented, and that is JUST the OpenGL backend. They have a huge variety of other things in the driver that are constantly improved. On the other hand it seems like compared to NVIDIA, they are always a step behind in supporting the latest OpenGL functionality.

I only have an AMD GPU right now that is capable of DX11, but I’ll soon grab an NVIDIA too, so that post will come later.


The Experiment

So I downloaded all of the WHQL drivers from AMD’s website back to 12.8 as that is supposed to be the first driver to support Windows 8.

I wanted to have a real-world benchmark program that showcases the improvement, so I browsed through my games in Steam, and found out that Metro: Last Light has a benchmark program that puts quite a stress on the system.

The PC I used for testing is the following:

-Core i5 4670 @3.4GHz

-HD 7770 GHz Edition 1GB GDDR5

-8GB 1600MHz RAM

The settings I used were the following:



-Very High Quality

-4x AF

-NO PhysX

-Normal Tessellation

-Low Motion Blur


The Results

I started with the latest beta driver the 14.7 RC3. The overall experience was smooth animation, with FPS drops (to around 25FPS) in places where the GPU just didn’t suffice. I got 38.91 as the average FPS, which is 25.7 ms.

Then I wanted to compare with the oldest possible, the 12.8. This time the animation lagged a bit, or it was just not that smooth overall. The FPS drops were now more severe (to around 20FPS) and the overall framerate was just at least 5-10FPS less. I got 32.96 as the average FPS, which is 30.34ms.

I also tested the drivers in between the two extremes and I found that the average FPS improved ever so slightly with each release.

The minimum and maximum frame times varied a lot, there’s definitely no trend here.

The best driver for the minimum FPS was the 13.9, but this likely cost a bit on the max FPS side, as you can see the trend breaking after 13.4.

Here’s a chart that shows driver performance over time:

AMD Driver Performance over time

And here’s a GIF that shows the perf improvement of the entire frame sequence over time (not just min/max/avg):

AMD Driver perf over time


The Conclusion

So as you could see the driver performance did improve significantly (by 5 ms for the average frame time, which is HUGE) in 2 years. It is definitely worth upgrading your drivers to the latest WHQL version, as you’ll definitely get some small perf improvements and other goodies. The performance did improve in a real world scenario, so you can’t say that they’re only optimizing for 3DMark…

If you’d like to see the original result files, you can find them here:



Physically Based Camera Rendering

The need

With all the talk about Physically Based Rendering nowadays, it’s important to take a look at the abusive post-processing effects games use today to either enhance the image or mask artifacts and lack of detail. Therefore I think it is important to have a Physically Based Camera Rendering (PBCR) system in games, because to have an image that looks like as if it was taken from a movie, you have to look at it through some lenses.

The ingredients

Most (if not all) of today’s AAA games (and even some indie) feature high-quality post effects, such as Depth of Field, Motion Blur, Film Grain, (pseudo) Lens Flares, Bloom, Glare, Vignetting and Chromatic Aberration. Usually you can also adjust the Field of View of the camera you’re observing the world through, and sometimes this is a gameplay feature (think of the sniper rifles).

Of course all this requires a Gamma Correct High Dynamic Range rendering system to be working properly. Pair this with Physically Based Rendering, and you should get really realistic results.

Depth of Field

Depth of Field (or DOF) is an effect that simulates the out-of-focus (blurry) parts of the photographs. http://en.wikipedia.org/wiki/Depth_of_field

Depth of Field

Depth of Field

Bokeh Depth of Field refers to the various shapes that are formed when highlights are out-of-focus. This is in my opinion a pretty nice effect, but there are game styles where this is actually counter-productive (like FPSs).

[UPDATE] The Bokeh shape is directly affected by the aperture, as you can see here, on real world cameras you can even create custom shapes (so sprite based bokeh is not all bs), and with some clever blending between the shapes you can create dazzling eye-candy effects (who told you this can’t be a gameplay feature?).

On real world cameras you can control this effect by changing the point where you focus.

To add, you can change your f-stop (http://en.wikipedia.org/wiki/F-number) number (the diameter of your aperture). The bigger the f-stop is, the smaller the aperture diameter becomes, and therefore less light comes through there, so the image’s exposure should decrease. A high f-stop number also means that your camera will increasingly start to look like a pinhole camera (http://en.wikipedia.org/wiki/Pinhole_camera) and therefore more and more of the image should be in focus.

The f-stop number also depends on the focal length (http://en.wikipedia.org/wiki/Focal_length), and focal length directly affects your field-of-view (FOV).  Large focal lengths should mean small FOV values. The focal length is a parameter of your lenses, however this is why zoom lenses were invented, you can change the focal length, therefore you essentially zoom in on the image, your field of view becomes smaller, and also your depth of field becomes shallower (see, everything correlates).

There are numerous papers around the internet that discuss how to implement this technique efficiently:



Motion Blur

Motion Blur is an effect that simulates the streaking (or blurring) of objects moving relative to the camera either because of their speed, or the camera’s long exposure. http://en.wikipedia.org/wiki/Motion_blur

Motion Blur

Motion Blur

This effect is created because for that camera it actually takes time to record a frame, and in this time objects move, therefore they appear on more than one pixel of the image. Longer exposure times mean that it takes even longer for the camera to record a frame, so objects are more prone to appear blurry.

There are also numberous sources to learn from:




Film Grain (or noise)

So, suppose you have a perfect image rendered using PBR, but it still doesn’t look right. You may be missing some noise. This dreaded artifact of path tracing systems is actually quite common in real-world screnarios (although it is way more subtle).

Film Grain

Film Grain

In real photographs the images may look noisy due to the fact that the surface that captures the light is actually somewhat sensitive to it. The sensitivity is determined by the ISO speed setting on your camera. Large ISO settings mean that the surface is really sensitive to the light, and therefore you can take a picture even at night, or in a dark room. This comes at a cost though, the image will get noisy.

Here’s a link on how to implement this:


Lens flares

Lens flares are again a nice artifact of real world camera systems. They are formed by light reflecting and scattering around in the lens system of a camera. Sci-fi games usually like to abuse this by putting it every-f-in-where, even if it totally shouldn’t be there. Even JJ Abrams would be jealous of some games. http://en.wikipedia.org/wiki/Lens_flare

Lens Flares

Lens Flares

A nice, natural looking lens flare effect though may add a lot to the realism of the scene.

Here’s some links on how to implement it:




Boom is an effect that produces fringes of light extending from the borders of bright areas in an image. The light kind of bleeds to the dark parts of the image. http://en.wikipedia.org/wiki/Bloom_(shader_effect)



Here’s some links on how to implement it:




While bloom is an artifact of the camera lens system, glare is actually an artifact of your eyes’ lens system. While your eye can adopt to sudden light intensity changes pretty quickly, it’s still not perfect, and therefore you may experience difficulty seeing. http://en.wikipedia.org/wiki/Glare_(vision)



You can simulate this by implementing eye adoptation, which changes the exposure of the image over time based on the average luminance.

Here’s a paper on this:



Vignetting in real world camera systems is produced by the lenses blocking light from each other.  This also means that the amount of vignetting is dependent on the f-stop number (aperture). http://en.wikipedia.org/wiki/Vignetting

The bigger the f-stop number is, the smaller the aperture diameter will be, and therefore more vignetting will be visible.






Chromatic aberration

Chromatic aberration is an effect when the lens system fails to focus all colors to the same place. This results in fringes where there are large light intensity differences in an image. http://en.wikipedia.org/wiki/Chromatic_aberration

So probably when you implement it you should experiment with luminance based edge detection filters, so that only the large contrast areas will be affected.

Chromatic Aberration

Chromatic Aberration



Putting it all together

So after you’ve implemented all of these effects, it’s time to link the parameters together, so that all of them work in a system simulating an actual camera.

Here’s an impressive demo that showcases this:


Remember that sometimes less is more, most of these effect are normally really subtle, so make sure you don’t go overboard.

[UPDATE] Just a small addition to the implementation part: the rendering order matters. So, suppose you have your fully lit scene, along with subsurface scattering and reflections blended on top. Then you do these effects in the following order:

1) Depth of Field

2) Motion blur (note that you can do these independently and mix them later as shown here, but quality suffers a bit)

3) Bloom rendering (input: motion blur output)

The usual bright pass, etc. plus eye adoptation!
4) Lens flare rendering (input: bright pass output)

5)  Combine the output of the motion blur pass, lens flares, bloom. Do the vignetting here, on the combined color. Do tone mapping and gamma correction here on the vignetted color.

6) Render chromatic aberration and film grain here (so after tonemapping, in gamma space)

7) Post processing AA comes here (eg. SMAA)

If you still didn’t quite understand all the theory behind all this (especially the real world part), then I recommend you read through this website:


OpenGL browser GUI lib

While I was working on other things I decided to create a UI for it.

I also wanted it to be quick and easy, so I took my already existing berkelium wrapper implementation and created this simple lib. With this you can easily add a UI to your OpenGL application. You can design the UI in a webpage designer application and hook up the js-cpp communication later. You can also implement a dummy cpp implementation in js for more complex projects, so that you can quickly prototype/develop/debug your webpage even in your browser!

So to sum it up:

  • -fast development
  • -easy to use
  • -develop the UI in your browser, hook up the cpp-js code later
  • -design the UI in a webpage designer application
  • -youtube support
  • -webgl support
  • -cross platform

check it out here: