Cycles CPU Preview Artifact #80736

System Information
Operating system: Xubuntu 19.10
Graphics card: GeForce RTX 2070 SUPER

Blender Version
Broken: 2.90.0, branch: master, 2.91.0 alpha
Worked: 2.83.5

Short description of error
Posing the rig with Rendered Display Viewport Shading causes artifacts to appear.

Exact steps for others to reproduce the error
Load attached file
Switch to Rendered Display preview mode.
Grab/move the T_Arm.L target bone.

  The Skin_Arm_lwr meshes will vanish and/or deform.

Switch to any other Viewport Shading mode.
Switch back to Rendered Display.
The meshes will be correctly displayed.

Other:
There is a hexagonal ngon in Mech_Arm.L. Delete it, and the artifacts go away.
(I applied Grid Fill to the ngon as a test, but no change)
I've simplified the rig considerably to isolate a possible cause.
In the full rig, the artifacts appear all over: arms, legs, torso, head.
Full render is not apparently affected (only preview).

The original project files were created with Blender 2.67, and worked through 2.83.5

B290_cycles_preview_artifact.blend
system-info.txt

Added subscriber: @Cyclotron

Added subscriber: @NRH_BEATS

435.21 very outdated driver, this branch not supported anymore.
Install xUbuntu 20.04.1 LTS with perfect and latest 450.66 driver out of box.
https://xubuntu.org/download

Added subscriber: @iss

Changed status from 'Needs Triage' to: 'Confirmed'

There is corrupted mesh ID3220 but that doesn't seem to be cause of this issue

Added subscriber: @Alaska

@iss I am able to reproduce a bug like this in different scenarios, here are the steps for reproducing. I should note that the issue seems to show up in different places when comparing Blender 2.90.1 and 2.91. I have marked each guide with the versions it shows up in.

System Information:
Operating system: Windows-10-10.0.19041-SP0 64 Bits
CPU: Ryzen 9 3900X
Graphics card: RTX 2060 SUPER 456.38

It should be noted that on Linux I can only reproduce test 3 based on testing so far.
Linux Kernal version: Linux-5.8.0-2-amd64-x86_64-with-debian-bullseye

Blender Version:
Broken: version: Tested 2.90.1 and 2.91.0 Alpha 7ab8d7c939 (2020-10-09 21:39)

Exact steps to reproduce (Test 1 - Reproducible in Blender 2.90.1 and 2.91):

Change your render engine to Cycles and set the rendering device to CPU.
Select the default cube and give it a Particle System set to type Hair.
Give the cube a sub-division surface modifier.
Enter rendered viewport mode then apply the sub-division surface modifier. Now the cube should have some artifacting or missing geometry (depends on sub-division level).

Expected result	Actual result

Exact steps to reproduce (Test 2 - Reproducible in Blender 2.91):

Change your render engine to Cycles and set the rendering device to CPU.
Select the default cube and give it a Particle System set to type Hair.
Select the cube and give it a sub-division surface modifier with the Viewport level set to 4.
Apply the sub-division surface modifier.
Enter rendered viewport mode.
In the property panels for the hair system, change the length from 4 to 1. Notice the artifacts or missing geometry.

Expected result	Actual result

Exact steps to reproduce (Test 3 - Reproducible in Blender 2.90.1 and 2.91):

Download the .blend file found below (This file is a modification of the owl file produced by user Gholm on blendswap released under CC-0)
Enter rendered viewport mode.
Select the armature Owl.arm and move it around. You should notice artifacts on the owl mesh.

Expected result	Actual result

#80736 - Owl.blend

It should be noted that in all these tests doing at least one of these things seems to resolve the issue and stop it from re-occuring:

Setting the rendering device to GPU fixes the issue (suggests it might be caused by Embree).
Exiting and re-entering rendered view also solves the issue.
Enabling Cycles debugging and setting the BVH to BVH2 rather than Embree also solves the issue (another suggestion it may be caused by Embree).
Enabling Cycles debugging and changing Viewport BVH type to Static also seems to solve the issue (Probably narrows it down to Embree's BVH refitting).

@iss I am able to reproduce a bug **like this** in **different scenarios**, here are the steps for reproducing. I should note that the issue seems to show up in different places when comparing Blender 2.90.1 and 2.91. I have marked each guide with the versions it shows up in. **System Information:** Operating system: Windows-10-10.0.19041-SP0 64 Bits CPU: Ryzen 9 3900X Graphics card: RTX 2060 SUPER 456.38 It should be noted that on Linux I can only reproduce test 3 based on testing so far. Linux Kernal version: Linux-5.8.0-2-amd64-x86_64-with-debian-bullseye **Blender Version:** Broken: version: Tested 2.90.1 and 2.91.0 Alpha `7ab8d7c939` (2020-10-09 21:39) **Exact steps to reproduce (Test 1 - Reproducible in Blender 2.90.1 and 2.91):** 1. Change your render engine to `Cycles` and set the rendering device to `CPU`. 2. Select the default cube and give it a `Particle System` set to type `Hair`. 3. Give the cube a `sub-division surface` modifier. 4. Enter rendered viewport mode then apply the `sub-division surface` modifier. Now the cube should have some artifacting or missing geometry (*depends on `sub-division` level*). | Expected result | Actual result| | -- | -- | |![#80736 -2.PNG](https://archive.blender.org/developer/F8975962/T80736_-2.PNG)|![#80736 -1.PNG](https://archive.blender.org/developer/F8975946/T80736_-1.PNG)| --- **Exact steps to reproduce (Test 2 - Reproducible in Blender 2.91):** 1. Change your render engine to `Cycles` and set the rendering device to `CPU`. 2. Select the default cube and give it a `Particle System` set to type `Hair`. 3. Select the cube and give it a `sub-division surface` modifier with the `Viewport level` set to 4. 4. Apply the `sub-division surface` modifier. 5. Enter rendered viewport mode. 6. In the property panels for the hair system, change the length from 4 to 1. Notice the artifacts or missing geometry. | Expected result | Actual result| | -- | -- | |![#80736 - 4.PNG](https://archive.blender.org/developer/F8976097/T80736_-_4.PNG)|![#80736 - 3.PNG](https://archive.blender.org/developer/F8976092/T80736_-_3.PNG)| --- **Exact steps to reproduce (Test 3 - Reproducible in Blender 2.90.1 and 2.91):** 1. Download the .blend file found below (This file is a modification of the owl file produced by user Gholm on [blendswap ](https://www.blendswap.com/blend/7951) released under CC-0) 2. Enter rendered viewport mode. 3. Select the armature `Owl.arm` and move it around. You should notice artifacts on the owl mesh. | Expected result | Actual result| | -- | -- | |![#80736 - 6.PNG](https://archive.blender.org/developer/F8976414/T80736_-_6.PNG)|![#80736 - 5.PNG](https://archive.blender.org/developer/F8976406/T80736_-_5.PNG)| [#80736 - Owl.blend](https://archive.blender.org/developer/F8976373/T80736_-_Owl.blend) --- It should be noted that in all these tests doing at least one of these things seems to resolve the issue and stop it from re-occuring: - Setting the rendering device to `GPU` fixes the issue (suggests it might be caused by Embree). - Exiting and re-entering rendered view also solves the issue. - Enabling Cycles debugging and setting the BVH to BVH2 rather than Embree also solves the issue (another suggestion it may be caused by Embree). - Enabling Cycles debugging and changing `Viewport BVH type` to `Static` also seems to solve the issue (Probably narrows it down to Embree's BVH refitting).

Added subscriber: @EAW

That owl’s corruption looks similar to my Suzanne’s in #81587.

In #80736#1031829, @EAW wrote:
That owl’s corruption looks similar to my Suzanne’s in #81587.

I took a look at your file in that task and played around. Crashing is less frequent on my CPU (Ryzen 9 3900X), however in many cases I'll end up in situations like the "corruption" you've shown in your Suzanne and I've shown in the owl.

Note: I am unable to reproduce crashing in your task (#81587) on Linux (based on testing so far).

Also, while playing around with the owl scene, your Suzanne, my hair scene, I see common crashes like in this report #81102. Might be related?

#81102 is very similar. My crash log used to be almost identical, but there was a commit in the last two or three days that caused some of the TBB calls to change. Thanks for looking into mine and letting me know about #81102 @Alaska!

Added subscriber: @brecht

FYI @Alaska ,@iss, and @brecht,
Test 1 & Test 2 from @Alaska's comment have been fixed by 6d8e03ddd9.
Test 3 is not fixed.

Tested using e4728d0a16 as a control, All three tests produced the artifacts.
Tested using 390b28e338, with the fix, only Test 3 showed artifacts.
Operating system: Windows-10-10.0.18362-SP0 64 Bits
Graphics card: GeForce GTX 470/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 391.35

I can't reproduce the issue with Test 3. Does it happen reliably or randomly?

I also can't reproduce issues with test 3. I rendered on CPU with openCL

System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: Radeon RX550/550 Series ATI Technologies Inc. 4.5.14736 Core Profile Context 20.8.3 27.20.12027.1001

In #80736#1041636, @brecht wrote:
I can't reproduce the issue with Test 3. Does it happen reliably or randomly?

In #80736#1042273, @iss wrote:
I also can't reproduce issues with test 3. I rendered on CPU with openCL

I am also unable to reproduce the issue with Blender 2.92.0 Alpha 7872bcafa0 (2020-11-02 14:36)

I am also unable to reproduce the artifacts shown in the original report for this task (#80736).
Maybe it's an issue with older CPUs? as @EAW does have an older Intel CPU. Note sure.

Changed status from 'Confirmed' to: 'Needs User Info'

I doubt this is related to CPU architecture. Maybe @EAW made a mistake in testing?

Reran test 3 with:
version: 2.92.0 Alpha, branch: master, commit date: 2020-11-04 17:16, hash: 331614e09b, type: Release
build date: 2020-11-04, 17:45:49
platform: Windows

The issue is gone @brecht .

Changed status from 'Needs User Info' to: 'Resolved'

Ok, great.

Added subscriber: @howardt

Out of curiosity, I git bisected the commit that fixed Test 3.

commit b37c40a575663ea42d397d57d3ef902b4d9777ec
Author: Brecht Van Lommel <brecht@blender.org>
Date:   Fri Oct 23 18:54:45 2020 +0200

Fix Cycles unnecessary overhead cancelling finished task pool


 intern/cycles/util/util_task.cpp | 15 ++++++++++-----
 intern/cycles/util/util_task.h   |  4 ++--
 2 files changed, 12 insertions(+), 7 deletions(-)```

Seems reasonable to me as my report #81587 had task pool calls earlier in the stack when mesh corruption occurred.
It looks like I jumped the gun testing 390b28e338 instead of 23eaf3117c, which was commited 30 minutes later. 

Just something interesting I noticed: {b37c40a575663ea42d397d57d3ef902b4d9777ec} on Oct 24 is a re-push (not sure if that's the proper term) by @howardt of 
{23eaf3117c68} from Oct 23.
{594f47ecd2d5} is between those two commits, and still had artifacts when I tested it as a git bisect revision.  I wonder if the "re-push" changed the way the git bisect algorithm sees the git commit history, in effect making the task pool fix only appear to the git bisect algorithm once, and that being the later one on the 24th.  🤷‍♂️

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Cycles CPU Preview Artifact #80736