[Bf-cycles] Environment/lightprobe importance sampling patch

[Mike Farnsworth]

Someone tried the patch and had a crash when using an importance
resolution greater than 1023.  (It's really just eating it with a
cuda_assert(cuLaunchGrid(cuDisplace, xblocks, 1)) when launching the
shader task.)  I had the same issue with my GTX 260, and I thought it
was just because that was an old(er) graphics card.  On my GTX 460 it
doesn't seem to have any issues with the importance resolution.  If
the GTX 560 Ti is crashing too, though, then I should probably to do
something about it.

The issue is that when running a cuda task, you can't have 65536
blocks in any dimension.  We use a block size of 16, and with a
resolution of 1024x1024, that results in 65536 blocks in the X
direction.  The near-term workaround is to keep the resolution under
1024, perhaps limited in the UI.

The long-term solution is that I need to break up the background
evaluation task into, say, chunks of 128x128 and go through them one
at a time in order to cover the whole background.

-Farny

On Sun, Jan 15, 2012 at 11:35 PM, Mike Farnsworth
<mike.farnsworth at gmail.com> wrote:
> This patch includes a full implementation of importance sampling for
> environments, including the MIS solution we talked about.  It adds two
> items for the user to control: on/off switch for whether to treat the
> environment as a light (off is old behavior), and a resolution control
> for the importance map.  Here are a few notes about the patch:
>
> * For environments that are a solid color (or very slowly changing),
> turning on the env light machinery is overkill, and will actually
> result in reduced performance.  For anything complex (textures, sky,
> noise, etc) it produces noticeably less noise for the same number of
> passes, so it should be a solid advantage.
>
> * Any HDR environment textures are chopped down to SDR range by the
> texture upload to device right now (nothing to do with my patch, of
> course); this reduces the effectiveness of this new environment
> sampling.  If we can fix that, the env light sampling will have an
> even greater effect, not to mention potentially improved visuals in
> general.  Just sayin'...
>
> * The patch includes a change where the displacement device function
> now outputs to a float4 buffer, not a float3 buffer, because on my
> older GPU that was causing completely screwed up sampling of the
> background when building the importance map.  So, displacement and
> shader tasks now have a slightly larger output buffer, but it now
> works on both my older GPU (GTX 260, sm_13) and my newer GPU (GTX 460,
> sm_21).
>
> * There is a commented #define that allows dumping the sampled
> background and both parts of the importance map to /tmp for debugging
> purposes.  Those sections of code can be removed, but they could come
> in handy in the future.
>
> I'm going to post some before/after images to morecycles.blogspot.com
> tonight, so you can see the difference in quality.  I apologize for
> this taking longer than I had anticipated.  I had left in a
> __int_as_float(f) where I should have just had an (int)f instead, and
> it manifested itself with a zero PDF for the environment light, just
> causing noise.  It took a while to dig through it and find it.
> Brecht, let me know if you have any issues with the code, and I'll try
> to turn around any suggestions you make ASAP so this can be included
> in 2.62.  I understand the deadline is the 22nd?
>
> -Farny