Bisecting points to rBbbe6d4492823: Cycles: optimize device updates as the cause. CC @Kévin Dietrich (kevindietrich)

Hi. I was working and saw is in any moment no matter the addons

In T84954#1099100, @Dylan Bailey (wavestorm) wrote:

In any case, many thanks for clarifying this. I might look into cloning the cycles driver and experimenting with the SHADOW_STACK_MAX_HITS setting, if I can get the tool-sets set up on my system.

I had a suspicion this was the case, but then it needs to be made very clear in the documentation (I searched pretty thoroughly but found no mention of it), especially if blender is to be more widely adopted for commercial projects. Would it not be possible to add an option in a future build that would allow us to bypass this limitation? Perhaps an additional feature set option?

And here goes the OCIO v2.0.0-rc1! The official release is coming ; )
https://github.com/AcademySoftwareFoundation/OpenColorIO/releases

Linked Copy and Fully Copy do copy the view layers and associated lineset for me.

That makes sense but should not full scene copy also copy those settings to the new scene? That seems to be the main confusion I personally had.

Hi.
If this is a limitation, then something would have to be done to make the Optix GPU + CPU Hybrid render give similar/compatible results in tiles? Limit CPU to the same GPU OptiX capabilities? I think @Brecht Van Lommel (brecht) has done something like that for volumetrics for CPU and GPU.

This is expected behavior: There is a limit of 64 transparent hits supported for a single ray until it hits a light source (see SHADOW_STACK_MAX_HITS in Cycles source code) on the GPU. On the CPU it can dynamically allocate more memory to extend that range, and with CUDA there is a slow fallback implementation using a loop. In OptiX that fallback implementation is disabled for better general performance, so you can't do more than 64. We could enable the fallback there as well, but that would come at a performance hit even if no more than 64 hits are encountered, so decided against it for now.

I can confirm.

I am able to reproduce the bug. System specifications below.

In D10153#254443, @Brecht Van Lommel (brecht) wrote:

Can we get some more info on the impact on the build system, limitations, etc.

• The code appear to be Windows only, but the build option exists on all platforms.

Update: Blender also crash when rendering viewport so this is not related to baking textures as I thought.

I just tried again today with Blender 2.91.1 and 2.92 beta, it crashed after 1-3 attempts to bake textures (AO and Lightmap). I also noticed that the problem only occurs when all objects are selected for rendering, Blender doesn't seem to hang when ignoring objects from the render and baking 1 by 1.

Can confirm the difference between 2.7 and 2.92.

I'm unable to reproduce this, testing:

• 2.90.1 and latest 2.92 master
• CPU and CUDA baking
• Baking multiple objects in the scene multiple times

I think this could be closed, since this is now implemented?

Not supported by the current baking system, not considered a bug.

Yeah, right! At first it looked too easy because I didn't notice that Denoising Data was enabled and I could easily reproduce it with an empty scene file (which I assumed was a bit stupid to upload). But in the end it would've helped.

Ah, that's right, with Denoising Data here hybrid render with default cube does not finish, it hangs and I can't cancel render either.

Can we get some more info on the impact on the build system, limitations, etc.

• The code appear to be Windows only, but the build option exists on all platforms.
• Loading of the library uses a delayload mechanism, which is different than we do for CUDA, OptiX and OpenCL. Preferably we could use the same mechanism for all since it's hard to understand potential failure cases and all side effects of these mechanisms.
• Can this denoising system be used together with a CPU or even CUDA render, or does it only work in combination with OpenCL?

Testing with the patch seems to greatly reduced the differences between CPU rendering and GPU (CUDA). Thank you @Brecht Van Lommel (brecht)

@Brecht Van Lommel (brecht) This was fast. Good job!

Fixes based on feedback.

There's an infinite recursion here. Rendering itself will change the frame causing this handled to be called.

This bug report is about adaptive subdivision, and for that this is already listed in T53901: Cycles adaptive subdivision tasks.

The default scene comes with a freestyle lineset, but a new empty scene or new empty view does not have one.

@Falk David (filedescriptor) Not exactly what i’m looking for. I want to render the scene for the active camera at the resolution set for the final render, e.g. 32x32 pixels. The viewport renders at th e viewport/display resolution, not the render setting resolution. Why would I need 32x32 resolution you may ask? because I am working on a technique to voxelize a surface via rendering and I need to see the final render at the specified resolution. Besides, why does this event handler crash blender is the question. How can this be normal behavior?