[Bf-cycles] Environment/lightprobe importance sampling patch

[Mike Farnsworth]

Okay, one more update.  This version hopefully fixes an issue where
any changes to nearly any setting were causing a re-render, because I
wasn't checking for opportunities to skip the background light sync.
This version seems to trigger fewer progressive render updates, but
still updates at the right times.

Brecht, let me know when you think this might make it into trunk.

Thanks,
Farny

On Tue, Jan 17, 2012 at 10:59 PM, Mike Farnsworth
<mike.farnsworth at gmail.com> wrote:
> I've updated the patch to include the task split (max of 16384 shader
> evaluations per task), as well as turn off the background
> sample_as_light switch by default to not adversely impact performance
> for those who haven't set a custom environment.  I don't know of any
> other outstanding issues.
>
> -Farny
>
> On Tue, Jan 17, 2012 at 6:18 AM, Brecht Van Lommel
> <brechtvanlommel at pandora.be> wrote:
>> Great work! I'll do a proper review of it later.
>>
>> Regarding the task size, there's a function to split up tasks in the
>> device code. It's used in device_opencl.cpp, task_add, if there's a
>> CUDA issue with maximum size being exceeded a similar thing could be
>> done there.
>>
>> Brecht.
>>
>> On Mon, Jan 16, 2012 at 6:16 PM, Mike Farnsworth
>> <mike.farnsworth at gmail.com> wrote:
>>> 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
>>> _______________________________________________
>>> Bf-cycles mailing list
>>> Bf-cycles at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-cycles
>> _______________________________________________
>> Bf-cycles mailing list
>> Bf-cycles at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-cycles
-------------- next part --------------
A non-text attachment was scrubbed...
Name: env_mis_r3.patch
Type: text/x-patch
Size: 34657 bytes
Desc: not available
Url : http://lists.blender.org/pipermail/bf-cycles/attachments/20120119/086f7631/attachment.bin