Sorry, disregard the previous comment. Was confused between Camera, BlenderCamera, and BL::Camera. From testing it seems to work fine.
Wouldn't mind second pair of eyes though.

I need to amend my previous with the fact that I have updated the operating system one or more times and that an Apple update may have affected this outcome. I am running the current updated Big Sur from the screen capture:

Phillip,
I am optimistic after just downloading << Blender-3.0.0-0e581f619670-macOS.app>> and trying everything I could think of to get Blender to crash. I am still using the same equipment of when I first reported the bug. I turned the screensaver to sleep after 1 minute and minimized Blender and after waking the screen Blender worked normally. I did some preemptory screen blanks and waited several minutes before coming back on with a key press knowing the screen saver would have come on. It won't crash. Let's see if others have the same experience !
Paul

Thanks for the report, but are not handling bug reports for cycles-x (or any other branch for that matter). There are too many known issues that will be resolved still.

If this bug got fixed it would greatly benefit my [[ VisionBlender add-on| https://github.com/Cartucho/vision_blender ]].

There are some minor things we can address before committing the change, but overall I think is a good and useful improvement.
Not sure if @Brecht Van Lommel (brecht) wants to have a pass of review here as well?

Update Tileable property description

Added Braces to single line ifs

oh man, what a show stopping problem. Can anyone recommend a good python package for controlling the mouse that works on windows, mac and linux without the user having to grant any permissions at OS level?

Just for the record, the shadow catcher has been refactored in the cycles-x branch and the support of indirect light should be there. There are still some remaining topics about the shadow catcher mentioned in T87837. We are working on them.

We are currently not taking bug reports for Cycles-X on developer.blender.org. Hence why I'm archiving your report.

This looks correct.

Note this was improved in rBaed9b6faee39: Fix some Cycles random walk SSS precision issues with small radius but not fully fixed.

FYI, this behaviour is not seen in cycles-x. I've not finished reading the code so I'm not yet certain how it's been fixed.

Multiple people with non-AMD/non-Windows tested and the issue was not happening for them

Current progress on trying to eliminate the megakernel is in P2111, still not where I want it to be.

Testing with the binary Blender 2.930 Beta. Rendering with cycle engine seems fine with the tested RyzenGraphic file originally from AMD.
It would be interesting to get the source file and see if the resulted

Seeing this as well.

• Remove useless line

Until amd or blender fixes this, I suggest you try this:
Go into render view until you get the kernel errors. THen click on solid mode and wait several minutes until blender responds. It may seem its not responsive but it might be compiling the renders under the hood. After some minutes the kernels might be compiled and you blender becomes responsive again. Go again into render mode and it should work ( or maybe you should do this a couple of times. Volumetrics though don't work no matter what you do in my exp.

Thanks for the report.
We are aware of this problem.
It has been reported before in T84461: Cycles: Split kernel error with OpenCL.

This seems to be a duplicate of T79836: Cycles slowdown and disk reading issues with large textures

Not sure how much this is related to the Depsgraph.
Not sure how much this is related to the AMD GPU.

System Information
Operating system: Linux-5.12.1-custom-x86_64-AMD_Ryzen_5_5600X_6-Core_Processor-with-slackware-14.2 64 Bits
Graphics card: AMD Radeon (TM) RX 480 Graphics (POLARIS10, DRM 3.40.0, 5.12.1-custom, LLVM 11.1.0) AMD 4.6 (Core Profile) Mesa 21.0.3

System Information
Operating system: Linux-5.12.1-custom-x86_64-AMD_Ryzen_5_5600X_6-Core_Processor-with-glibc2.33 64 Bits
Graphics card: AMD Radeon (TM) RX 480 Graphics (POLARIS10, DRM 3.40.0, 5.12.1-custom, LLVM 11.1.0) AMD 4.6 (Core Profile) Mesa 21.0.3

Task superseded by T87836: Cycles X - GPU Performance.

As you can imagine, if you shift the ray way above the surface it can fly over another object and its shadow will disappear.

The comment was indeed wrong, I fixed it now to be:

integrate cos(x) * (1 - tan(x) * tan(a)) * sin(x) from x = 0 to pi/2 - a

Which yields:

1/4 (2 + 2 a tan(a) - π tan(a))

Thanks for the details. I'll run some tests in production scenes to see what the impact is.

You don't actually need to offset the ray on a triangle facing the light (to save calculations). On the other hand, if the cutoff is set to zero, in some cases you can notice on a triangle, that switches from a properly lit to a terminated state, a shadow that suddenly disappears or jumps. To make this behavior smooth and less noticeable, cutoff is used to set fading out width. At the same time there are some ill cases that require offset on a close to be terminated triangles, and that is where the cutoff comes handy.

• Fixed ear darkening, as well as regression (introduced by me by a mistake) similar to T43835: ray offsetting giving precission problems / render artifacts / cracks on far away geometry.
• Moved logic to a separate function ray_offset_shadow().

I am also getting a segmentation fault when using cycles, however under CPU rendering not GPU. Running fedora 33 (kernel 5.11.13-200.fc33.x86_64) on an Intel® Core™ i5-8350U CPU under wayland.

The megakernel was a clear win with CUDA when we added it to speed up the last 2% of paths. But benchmarking this with OptiX now it's a mixed bag:

                              no-megakernel                 cycles-x                      
bmw27.blend                   10.0372                       10.0984                       
classroom.blend               13.3341                       13.3774                       
pabellon.blend                7.34786                       7.3563                        
monster.blend                 8.51194                       9.12812                       
barbershop_interior.blend     9.55334                       9.77131                       
junkshop.blend                12.8547                       13.2737                       
pvt_flat.blend                14.8002                       13.0439

In a simple queue based system with fixed queue size for each kernel, memory usage increases as the number of kernels goes up, and much of the queue memory remains unused. However it does have the benefit that memory reads/writes may be faster due to coalescing.