CPU render will look different to GPU render and fails randomly #52625

New Issue

Michael Klein · 2017-09-02T16:27:35+02:00

Michael Klein commented

2017-09-02 16:27:35 +02:00

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.

170902_Blender_279_Cycles_CPU_Issue.zip

**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. [170902_Blender_279_Cycles_CPU_Issue.zip](https://archive.blender.org/developer/F766811/170902_Blender_279_Cycles_CPU_Issue.zip) ![GPU_vs_GPU_279_Render.jpg](https://archive.blender.org/developer/F766838/GPU_vs_GPU_279_Render.jpg)

Michael Klein commented

2017-09-02 16:27:35 +02:00

Changed status to: 'Open'

Michael Klein commented

2017-09-02 16:27:35 +02:00

Added subscriber: @Renderbicks

Ray molenkamp commented

2017-09-02 20:28:07 +02:00

Added subscriber: @LazyDodo

Ray molenkamp commented

2017-09-02 20:28:08 +02:00

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.

Even without the de-noiser on there quite a difference in the lighting of that tree between osl and svm. ![svm.png](https://archive.blender.org/developer/F767067/svm.png) ![osl.png](https://archive.blender.org/developer/F767068/osl.png) 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.

Nahuel Belich commented

2017-09-02 21:38:29 +02:00

Added subscriber: @NahuelBelich

Nahuel Belich commented

2017-09-02 21:38:29 +02:00

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.

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.

Nahuel Belich commented

2017-09-02 22:30:31 +02:00

In #52625#456556, @LazyDodo wrote:

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

> In #52625#456556, @LazyDodo wrote: > 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

Michael Klein commented

2017-09-03 00:09:33 +02:00

In #52625#456566, @NahuelBelich wrote:
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.

> In #52625#456566, @NahuelBelich wrote: > 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.

Michael Klein commented

2017-09-03 00:34:44 +02:00

CPU vs GPU.

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

CPU vs GPU. Please note: GPU is not rendering the OSL bevels. But there are differences in the background. ![Minecraft Animal Farm with Detailed Scene Renderbricks_v03_CPU.jpg](https://archive.blender.org/developer/F767251/Minecraft_Animal_Farm_with_Detailed_Scene_Renderbricks_v03_CPU.jpg) ![Minecraft Animal Farm with Detailed Scene Renderbricks_v03_GPU.jpg](https://archive.blender.org/developer/F767250/Minecraft_Animal_Farm_with_Detailed_Scene_Renderbricks_v03_GPU.jpg)

Nahuel Belich commented

2017-09-03 01:18:57 +02:00

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

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

Ray molenkamp commented

2017-09-03 01:22:52 +02:00

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.

Brecht Van Lommel commented

2017-09-03 02:06:23 +02:00

Added subscriber: @brecht

Brecht Van Lommel commented

2017-09-03 02:06:23 +02:00

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.

Michael Klein commented

2017-09-03 10:36:38 +02:00

In #52625#456607, @brecht wrote:
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.

> In #52625#456607, @brecht wrote: > 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. ![170904_Blender_279_Cycles_CPU_Issue.jpg](https://archive.blender.org/developer/F768695/170904_Blender_279_Cycles_CPU_Issue.jpg)

Brecht Van Lommel commented

2017-09-03 11:51:58 +02:00

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.

Michael Klein commented

2017-09-04 13:52:17 +02:00

In #52625#456656, @brecht wrote:
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 :-)

> In #52625#456656, @brecht wrote: > 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 :-)

Michael Klein commented

2020-02-13 09:21:06 +01:00

This issue still exists. CPU and GPU create different results.

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

CPU render will look different to GPU render and fails randomly #52625