This patch adds volume rendering to OpenCL split kernel.
Depends on D2299.
Differential D2310
Cycles: OpenCL split kernel volume Authored by Hristo Gueorguiev (nirved) on Oct 18 2016, 9:47 PM.
Details
Diff Detail
Event TimelineComment Actions 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? Comment Actions 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?
This comment was removed by Hristo Gueorguiev (nirved). This comment was removed by James W E Bird (3dLuver). Comment Actions 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? Comment Actions @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 Comment Actions 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? Comment Actions @Mai Lavelle (maiself) Comment Actions 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.
We will need to force enable transparent shadows if volumes are used then.
Not sure why this would be, do you have an explanation or a fix? Comment Actions This was due to a combination of division by zero and unsafe OpenCL optimization options. Already in master rB57e26627c4. | ||||||||||||