The first, most simple approach: to render from different positions on virtual camera lens into accumulation buffer:
I used 48 samples, for each frame 1024 cubes are rendered with instancing, distance to focal plane is taken into account when building a look-at matrix. 48 "samples" is less than necessary for quality images - banding is highly noticable. I think that well distributed 128 samples will be sufficient for images that resemble ray-traced one.
The second approach: for each window pixel we draw a vertex, then geometry shader expands it to a sprite with some diameter. Then an additive blending is used to blend sprite's color with background. Pretty ugly approach, but at first glance may produce plausible images. Currently I have a troubles with preserving image energy, there are some artifacts and so on.
A few words about implementation: 1024 cubes are rendered with instancing, view space Z is written to depth buffer. Then rendered w * h vertices, each vertex maps to a single window pixel. To reduce workload, there is no vertex buffer at input, vertex shader is called by DrawInstanced() API, vertex coordinate computation is based on SV_InstanceID semantic. Vertex shader fetches color and depth and pass these to geometry shader. The latter computes circle of confusion diameter and expands vertex to a sprite. Then trivial output in the pixel shader and blending to the framebuffer. The bottleneck is in the heavy FP-blending, not in the geometry pipeline.
One thing that I considered important - right computation of CoC diameter. It depends on optical system parameters: lens diameter, focal distance and distance to focal plane. I took the appropriate formula from Dynamic Light Field Generation and Filtering paper.
The curve resembles in some way another curve that is given in this paper on DoF: Pyramidal Image Processing.
I hope that my math is right.
