[Bf-cycles] Environment/lightprobe importance sampling patch

Brecht Van Lommel brechtvanlommel at pandora.be
Tue Jan 17 15:18:53 CET 2012


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


More information about the Bf-cycles mailing list