CPU render will look different to GPU render and fails randomly
Open, ConfirmedPublic

Description

System Information
Win 10, GTX 880M, GTX 1080TI Founders Edition

Blender Version
Broken: blender-2.79.0-git.2ca1f29-windows64
Worked: na

Short description of error
Attached you'll finde a scene what has issues with GPU rendering. The scene is using the old shaders with a bevel shader (OSL).

The preview will not start or maybe it takes a very long time. Here nothing happened.
In GPU mode the preview starts as expected.

When I try to render with F12 in CPU mode it doesn't start or maybe it will start after a long time. Here nothing happened after 10 minutes.
When I render a small region with CPU it takes a long time till it starts to render.
When I start rendering in GPU mode it starts fast as expected ignoring OSL of course.

In the ZIP and attached you'll see a picture with a split screen. Left side is GPU. Right CPU. The results are different. Transparent parts with DOF will have extreme noise.

Exact steps for others to reproduce the error
Load the scene and press F12. Here CPU render will not start as expected.
Switch to GPU and press F12. Rendering will start.
Define a small region where the transparent parts are. Press F12. It will take really long but start. Result has noise at the transparent parts.
This might be a bug in the Cycles render engine or an issue with the shader tree.


Details

Type
Bug
LazyDodo (LazyDodo) triaged this task as "Confirmed" priority.Sat, Sep 2, 8:28 PM
LazyDodo (LazyDodo) edited projects, added Cycles; removed BF Blender.

Even without the de-noiser on there quite a difference in the lighting of that tree between osl and svm.

The slow starting speed with osl has something to do with the environment map. i've noticed this before, updating the importance map with osl on takes *forever*

NOTE: This file won't reproduce the issue until you go to File->External data->Unpack all, in the packed state render will start virtually instantly.

i have to be honest, not a developer im a user testing, downloaded the file started the render in cpu but didnt finish it i have to cancel, the render its huge and not sure where it is a transparent area. . .
That said.. . .
Tested on
I7 2600 16gb ram nvidia 1070 - Blender 2ca1f29
Render on cpu:
Start normal, didn't finish because of the long render time it would naturally a 2K image would take, so i canceled the render.
Render on Gpu:
Starts and renders and denoises, there is evident difference on the edges but couldn't notice anything particularly different.

Maybe a developer notice it right away or maybe a simpler smaller example its needed to test, not sure.

The slow starting speed with osl has something to do with the environment map. i've noticed this before, updating the importance map with osl on takes *forever*

NOTE: This file won't reproduce the issue until you go to File->External data->Unpack all, in the packed state render will start virtually instantly.

Yep, unpacking the blend file makes slowwwww start, if starts at all

Render on cpu:
Start normal, didn't finish because of the long render time it would naturally a 2K image would take, so i canceled the render.
Render on Gpu:
Starts and renders and denoises, there is evident difference on the edges but couldn't notice anything particularly different.

Maybe a developer notice it right away or maybe a simpler smaller example its needed to test, not sure.

Thanks for looking into it. Yes, the packed file works with CPU. That's interesting.

With GPU you will have differences at the edges because GPU isn't supporting OSL what does here a bevel edge shader.

The main issue here is the slow-down/freeze of CPU rendering and the differences described in the above pictures. When you render the pcitures with GPU and CPU you will notice differences when comparing them.

CPU vs GPU.

Please note: GPU is not rendering the OSL bevels.
But there are differences in the background.

Im just theorizing here, but could you setup a render side by side like the last one, but setting the bevel to 0 in OSL or directly disabling it.
Again im not a developer, but my instinct in production its telling me that the difference in value its because of the lac of high lights cause by the bevel that's missing in the gpu side that not support OSL.

Could be that or also my screen covers less colors than yours and im not noticing it, this last case happens to in a studio once, its not a crazy possibility

This last comment its not probably related to the long render times reported in the initial report its just to remove variables

Guys, i know you're trying to help, but this is a bug tracker, not a forum, lets try to keep the hypothesizing and chatter to a minimum. The issue is reproducible on our end. So for now just sit back and relax, nothing is required from your end at this point in time.

From profiling this looks like a performance issue with the OpenImageIO texture cache and .hdr files, the workaround would be to save the background image texture as a .exr file.

The render differences look like they're just bevel differences, there can also be some differences in image texture filtering when rendering with OSL.

From profiling this looks like a performance issue with the OpenImageIO texture cache and .hdr files, the workaround would be to save the background image texture as a .exr file.

The render differences look like they're just bevel differences, there can also be some differences in image texture filtering when rendering with OSL.

Not only. Or the marked areas in my attached picture are caused by the bevels? You'll see (as shown in my original post) differences in the blurred orange and yellow part (CPU result is sharp grained) and some reflections in the brown parts. Maybe it's an effect caused by the OSL bevels.

You can remove the bevel node on those materials if you want to verify it. To me it looks like specular highlights from bevel blurred by depth of field, which can be quite noisy.

You can remove the bevel node on those materials if you want to verify it. To me it looks like specular highlights from bevel blurred by depth of field, which can be quite noisy.

Affirmative. I turned off OSL and that was the reason. i will wait for your future built in "rounded edge" feature :-)