Cycles: OpenCL split kernel volume
AbandonedPublic

Authored by Hristo Gueorguiev (nirved) on Oct 18 2016, 9:47 PM.

Details

Summary

This patch adds volume rendering to OpenCL split kernel.

Depends on D2299.

Diff Detail

Repository
rB Blender
Hristo Gueorguiev (nirved) retitled this revision from to Cycles: OpenCL split kernel volume.Oct 18 2016, 9:47 PM
Hristo Gueorguiev (nirved) updated this object.
Hristo Gueorguiev (nirved) set the repository for this revision to rB Blender.

Currently it's buggy (default cube with quick smoke+fire at frame 30):

It works :) The buggy render seems to be due to the flame attribute having another value mapping than on CPU. Maybe it's not due to this patch?

Minor changes: added missing rays state in queue_enqueue.

Brecht Van Lommel (brecht) requested changes to this revision.Oct 23 2016, 1:43 AM

What is the reason for adding tmp_rng and state_shadow globals? As far as I can tell they don't contain any state that is passed between kernels, so I would expect them to just be stored on the stack. Is this for working around address space mismatches?

intern/cycles/device/opencl/opencl_split.cpp
543–544

There seem to be some indentation mismatches here and in other places.

intern/cycles/kernel/kernel_shadow.h
299–309

Not sure it's worth adding a function for this, it's only used in one place so could have this code inline.

This revision now requires changes to proceed.Oct 23 2016, 1:43 AM
This comment was removed by Hristo Gueorguiev (nirved).

Fixed indentation, a typo, removed shadow_blocked_addrspace.

Patch needs to be updated to work with current master

Updated to work with current master.

Fixed missing ccl_fetch.

Patch still doesn't apply

The patch had wrong newline characters.

This comment was removed by James W E Bird (3dLuver).

Was testing the patch on NVidia card, and some very simple scene renders with artifacts:

Is that NVidia-specific or someone can manage to reproduce on AMD as well?

@surgey, This was renderered from your file with no changes on AMD Firepro W9100 16GB GDDR5 with windows 10 64 build.

Donr run linux so cant so 100% this is just a Nvdia issue without trying the same on linux build but would say 99% sure it's nvidia related

Same scene as above with transparent{F407134} shadows turned off:

Update against latest master.

Did some quick tests, doesn't seem to be working.

On AMD OpenCL volume absorption is working correctly, but scattering doesn't work at all. Subsurface scattering sort of works, but has shading artifacts.

On Nvidia OpenCL, 90% of the time nothing renders, which is very odd. The other 10% of the time anything with a volume or subsurface shader renders black.

Is there something missing from these patches to make them work correctly?

@Mai Lavelle (maiself)
Volume scattering doesn't work due to NO_TRANSPARENT_SHADOWS.
Subsurface scattering works ok when using a single program - all kernels in one file.

Did some more testing with this scene:

The test has three cubes: left is subsurface scattering, middle is absorption, right is volume scatting.

Rendered in three different configurations: CPU, GPU with transparent shadows, GPU no transparent shadows

Same cubes and settings but from inside the volume scattering cube.

Its close, but we need all configurations to match CPU before we can accept these patches.

Volume scattering doesn't work due to NO_TRANSPARENT_SHADOWS.

We will need to force enable transparent shadows if volumes are used then.

Subsurface scattering works ok when using a single program - all kernels in one file.

Not sure why this would be, do you have an explanation or a fix?

Subsurface scattering works ok when using a single program - all kernels in one file.

Not sure why this would be, do you have an explanation or a fix?

This was due to a combination of division by zero and unsafe OpenCL optimization options.

Already in master rB57e26627c4.