I updated my DirectCompute Mandelbrot fractal demo to be able to render using both CUDA and DirectCompute. The program is a simple Mandelbrot renderer, but you can dynamically switch between a CUDA and DirectCompute render.

Relevant Links

http://developer.download.nvidia.com/compute/cuda/sdk/website/Graphics_Interop.html#simpleD3D11Texture
The NVIDIA CUDA 3.2 SDK includes a DirectX11 interop sample “Simple D3D11 Texture” which I used as reference. For the 3.2 SDK, I think this is the only CUDA sample using D3D11. The SDK sample uses a ID3D11Texture3D as a CUDA resource while my Mandelbrot fractal program uses a ID3D11Buffer as a CUDA resource.

http://developer.nvidia.com/object/cuda-by-example.html
I mainly used the CUDA 3.2 SDK programming manual to learn CUDA, but I also read the NVIDIA “Cuda by Example” book on Safari Informit. The book is very easy to follow and I read it in one sitting. This book teaches the basics of CUDA in a simple language and I thought it was a good first book.

http://www.yakiimo3d.com/2010/02/02/directcompute-mandelbrot-fractal-viewer/
My old DirectCompute Mandelbrot fractal viewer. The program has a bug (oh no!) when the screen size dimensions are not divisible by the thread group size dimensions, which I fixed in my new CUDA interop demo.

Demo Notes

Took some timings to compare the CUDA DirectX11 interop and DirectCompute performances. Timings were taken on my Geforce GTX 460, Driver 266.58, Vista 64-bit SP2, CUDA SDK 3.2. Neither the CUDA nor DirectCompute implementations have been optimized. With better documentation, better tools and finer control over the program, I think the CUDA program has a better chance of good optimization.

The higher the iteration count, the more work that the compute shader has to do. When the iteration count is low, DirectCompute is faster. When the iteration count becomes higher, CUDA becomes faster than DirectCompute. I’m assuming this means that with my current code, the CUDA kernel execution is faster, but that there is a fixed cost for DirectX11 interop that makes CUDA initially slower.

http://nvidia.fullviewmedia.com/gdc2011/agenda.html
On Friday, I watched the NVIDIA GDC2011 “GPU Radiosity: Porting the Enlighten runtime to CUDA” presentation, and around 28:23, the speaker mentions that “Switching between D3D and CUDA is expensive (it’s a power cycle!)”. I’m guessing this power mode switch cost is what makes CUDA initially slower in my Mandelbrot fractal program. I watched the entire Enlighten presentation and it was very interesting. The stream had some technical info, but if you are curious about Enlighten tech, there is a DICE&Geomerics Siggraph 2010 presentation that contains even more detailed technical information about Enlighten http://advances.realtimerendering.com/s2010/index.html.

Demo

Source Code & Binary
http://yakiimo3d.codeplex.com/releases/view/62087

I updated my simple Temporal AA demo to include an implementation of Temporal AA without blending. A lot of times, in technical 3D forums, you read about Temporal AA not showing up in screenshots. If you blend jittered frames like in my previous demo then Temporal AA is going to show up in screenshots. However, it’s also possible to implement Temporal AA without manual blending, and in that case, the AA is not going to appear in screenshots. Over the weekend, I implemented this other version of simple Temporal AA.

CodePlex link for my program’s source code and binary are provided at the end of the article.

Relevant Links

1) http://en.wikipedia.org/wiki/Radeon_R420
The Radeon X700-X850 series apparently featured Temporal AA without blending. Don’t think it’s supported on newer graphics cards as my HD5750 with Catalyst 10.10 doesn’t show an option.

2) http://techreport.com/articles.x/6672/22
This Tech Report article has a nice explanation of the Radeon Temporal AA implementation. Mulitisampling patterns are alternated each frame. If vsync is enabled and the app can maintain 60fps, even without manual blending, the eyes will interpolate the jittered frames giving an illusion of higher-sampled anti-aliasing. In the Radeon implementation, 2x MSAA using temporal AA will give an illusion of 4x AA.

3) http://forum.beyond3d.com/showthread.php?t=46241
Beyond3D’s “List of Rendering Resolutions + basics on hardware scaling, MSAA, framebuffers” thread mentions both Temporal AA with and without blending.

4) http://www.yakiimo3d.com/2010/09/28/dx11-perspective-matrix-jittering-temporal-aa/
My implementation of Temporal AA with blending. A simple implementation without reprojection, so you get ghosting/blurring.

Implementation Details

The implementation is the same as my last Temporal AA implementation except that I don’t manually blend the previous and current frame, but let the eye do the interpolation. I added a combobox for selecting the vsync interval. Only vsynced 60fps gives good results; non vsynced 60+fps, vsynced 30fps, vsynced 20fps all give pretty terrible edge flickering. With blending, the artifact is blurring/ghosting, without blending, the artifact seems to be edge flickering.

Unlike the Radeon implementation, I’m not alternating MSAA patterns, but just alternating jittered scene renders, so the quality should be equivalent to 2x SSAA (like my previous blended Temporal AA implementation). In the demo, the Temporal AA without blending looks a little bit worse than Temporal AA with blending because I decreased the sub-pixel offset to 0.15 from 0.25. Even at a vsynced 60 fps setting, I can sometimes still see an occasional edge flicker.

Demo

Source Code & Binary
http://yakiimo3d.codeplex.com/releases/view/56973

I would recommend viewing the demo in full-screen mode as this seems to give a more stable frame rate, and less edge flickering. I also fixed my texture mipmap settings and set the anisotropic filter to 16x. Even at this setting, you can still see a tiny bit of reduction in texture aliasing (without noticeable texture blurring from the SSAA, I think) in some parts of the scene, but it’s not significant and I guess that’s not the main point of Temporal AA.

Sorry for the download size. My mesh model data, borrowed from the DirectX SDK samples, is pretty big. Like my previous Temporal AA implementation, DX11 isn’t necessary for this technique, but my hobby coding is now done using DX11, so that’s what the demo uses.

Final Words

While I was working on my last Temporal AA demo, another Japanese programmer told me that he saw very little texture aliasing reduction in his Temporal AA test, but I foolishly didn’t check my code for bugs. Hopefully, I didn’t make any stupid mistakes this time!