Will let @Brecht Van Lommel (brecht) decide here, but pretty sure that there is no bug, the only rotation mode that is 100% OK in interpolation is the one using Quaternions, afaik. All others will hit issues like gimbal lock at some point or another.

the fault is fixed since the built from today. Thanks for your Help.

@Hans-Simon Sagave (wizardx) I read that there are plans for a Metal wrapper for Vulkan in the future. I guess a pure Metal version of Blender would require maintaining a separate macOS branch. But if you already want a taste of Metal-assisted rendering, you can try Radeon ProRender. It's quite well-integrated in Blender and is also free.

In D3998#91498, @Alexander Gavrilov (angavrilov) wrote:

In D3998#91490, @Marco Alamia (Macro) wrote:

It is exactly for edge splits and autosmooth.

Don't mix those two together, they are completely different. Edge split actually splits the mesh completely, while autosmooth only splits the normals. Thus with autosmooth there are still shared vertices and averaged vertex normals.

Cycles: OpenCL on macOS has been disabled

There was a growing payload of bugs in Cycles related on OpenCL on macOS
platform, and those issues were caused by a compiler bug, which we have no
control over.

Surely, it is sometimes possible to work compiler bugs around from a
source, but we are facing some of the issues which are not solvable in this
way. Also, such solutions are usually short-living,. since adding more
features are often kicking compiler to provide buggy binary again.

In this case compiler will not get fixed since Apple decided to discontinue
OpenCL on its platform.

So the decision was made to drop support of OpenCL, keep official features
of Blender stable and predictable, and focus on things we have control over.

P.S. Older Blender releases are always available. Surely, this sounds like
using an ancient software without neat features. But we can't push Cycles
OpenCL on macOS measurably beyond that anyway.

Cycles: OpenCL on macOS has been disabled

There was a growing payload of bugs in Cycles related on OpenCL on macOS
platform, and those issues were caused by a compiler bug, which we have no
control over.

Surely, it is sometimes possible to work compiler bugs around from a
source, but we are facing some of the issues which are not solvable in this
way. Also, such solutions are usually short-living,. since adding more
features are often kicking compiler to provide buggy binary again.

In this case compiler will not get fixed since Apple decided to discontinue
OpenCL on its platform.

So the decision was made to drop support of OpenCL, keep official features
of Blender stable and predictable, and focus on things we have control over.

P.S. Older Blender releases are always available. Surely, this sounds like
using an ancient software without neat features. But we can't push Cycles
OpenCL on macOS measurably beyond that anyway.

Same problem here, in both 2.79 and 2.8

Any updates?

Apple will not longer develop OpenCL... So what about Metal? This is the new one. It's much much faster on Mac and is the new language! Will Blender ever support Metal? This'd be a great idea: much faster render times on Mac, denoising and baking would work as well. Can we expect something like this for 2.81??? It would bring up Blender for a new level on Mac!

The Linux buildbot was using CUDA 9.2 for a while apparently, this is fixed now.

there's some background on the cuda 9.1/10 issue in T56858 but as i said earlier if 9.1 doesn't work for this issue, it's very likely a different issue and we shouldn't be mixing the reports cause that'll just confuse everyone.

@LazyDodo (LazyDodo) it seems to be fixed in the blender 2.8 beta!! @Paul Melis (paulmelis) can you confirm that it also works for you?

Thanks for testing.

Problem of render artefacts of GPU seems to disappeared.
I have recognised first correct render results on 6.12.2018 (official beta build Linux64).
Issue can be closed.

Commit: rBbb0d812d98f.
Link to the mailing list: https://lists.blender.org/pipermail/bf-committers/2018-December/049695.html
Link to the release notes: https://wiki.blender.org/wiki/Reference/Release_Notes/2.80/Cycles#GPU_rendering

Well, guess its finally time to get this tackled. Been delaying this for quite some time, since this is one of the things which doesn't really have a happy end :(

Yeah it would totally be great if this could be fixed! I tried it with 2.8 and 2.79b without success,.. With 2.8 I get the random black tiles. I just tried it again with 2.79b but that made my Mac reboot itself:( Tried it again just to be sure but the second time my whole screen went yellow and I had to unplug my eGPU.
Using a MacBook Pro 2018 i9 32GB ram with AMD Vega56 eGPU running MacOS Mojave.
Really hoping this can get fixed soon. In the meantime, does anyone know a way to still use the denoise function?

The original report is now fixed. Baking in 2.8 is still a bit strange/different when comparing to 2.7. That is a different issue than the reported one though.

Alternatively, we detect this case in mesh_build_data() and don't create new pointer for an evaluated mesh.

@Brecht Van Lommel (brecht), not sure what you mean by "the new dependency graph is duplicating these meshes". There is a single Mesh datablock, and several Object datablocks in such example.

The problem is the new dependency graph is duplicating these meshes before they get to Cycles.

Investigation update: bpy.context.scene.render.bake.cage_object is correct (e.g., "MyCage"), however when you clear it and reassign to the cage object you get leading spaces (e.g., " MyCage").

Super confirmed, and the issue is a bit more strange in fact. I made an example that works in 2.79[*]:

I'll mark this as resolved then

Don't know if it is you or Dalai I should assign this to @Brecht Van Lommel (brecht).

In D3998#91490, @Marco Alamia (Macro) wrote:

It is exactly for edge splits and autosmooth.

Hello Alaska, thank you for responding to my problem first and foremost. And apologize I write the blender build wrong on the OP, i'm having trouble on Blender 2.80 Beta. But i'm glad you get the point.

Just tested it with Blender 2.8 version 497a9ef7a39 on an RX 570 4GB with driver versions 18.12.1 on Windows 10 and I'm unable to recreate this issue.

Thank you for your time and for the review.

In D3998#91266, @Brecht Van Lommel (brecht) wrote:

To me it seems odd that we are using binary search to figure out which face corners share a vertex, when that information is already defined in the mesh. Or is this for modifiers like edge split that split the mesh, where that connectivity information is lost?

Is this different than just setting smooth normals on the low poly base mesh? Is the way the averaging works better in some way? Is it a matter of usability so user don't need to modify the low poly meshes?

OK. Maybe not so much a bug, more a change to adapt to the Collections = Groups scheme....

Any news on this one? I am sort of hoping this will work soon, everything else seem to work fine for me at the moment.

Confirmed crash on playback

1   MEM_lockfree_mallocN_aligned						mallocn_lockfree_impl.c  388 0x3107b88 
2   ccl::GuardedAllocator<char>::allocate					util_guarded_allocator.h 63  0x337f41a 
3   std::allocator_traits<ccl::GuardedAllocator<char>>::allocate		alloc_traits.h           301 0x337ecc4 
4   std::_Vector_base<char, ccl::GuardedAllocator<char>>::_M_allocate		stl_vector.h             296 0x337e6c6 
5   std::_Vector_base<char, ccl::GuardedAllocator<char>>::_M_create_storage	stl_vector.h             311 0x337d7db 
6   std::_Vector_base<char, ccl::GuardedAllocator<char>>::_Vector_base		stl_vector.h             260 0x337c12c 
7   std::vector<char, ccl::GuardedAllocator<char>>::vector			stl_vector.h             429 0x6231f1c 
8   ccl::vector<char, ccl::GuardedAllocator<char>>::vector			util_vector.h            43  0x6231ee8 
9   ccl::string_printf[abi:cxx11](const char *, ...)				util_string.cpp          34  0x62310a0 
10  ccl::Session::update_status_time						session.cpp              933 0x34bea9f 
11  ccl::Session::release_tile							session.cpp              464 0x34bc34b 
12  std::__invoke_impl<void, void (ccl::Session:: *&)(ccl::RenderTile&), ccl::Session *&, ccl::RenderTile&>		invoke.h                 73  0x34c2a77 
13  std::__invoke<void (ccl::Session:: *&)(ccl::RenderTile&), ccl::Session *&, ccl::RenderTile&>			invoke.h                 95  0x34c2767 
14  std::_Bind<void (ccl::Session:: *(ccl::Session *, std::_Placeholder<1>))(ccl::RenderTile&)>::__call<void, ccl::RenderTile&, 0ul, 1ul>(std::tuple<ccl::RenderTile&>&&, std::_Index_tuple<0ul, 1ul>) functional               400 0x34c23f1 
15  std::_Bind<void (ccl::Session:: *(ccl::Session *, std::_Placeholder<1>))(ccl::RenderTile&)>::operator()<ccl::RenderTile&, void>(ccl::RenderTile&)                                                  functional               484 0x34c1e2b 
16  std::_Function_handler<void (ccl::RenderTile&), std::_Bind<void (ccl::Session:: *(ccl::Session *, std::_Placeholder<1>))(ccl::RenderTile&)>>::_M_invoke(std::_Any_data const&, ccl::RenderTile&)   std_function.h           297 0x34c172b 
17  std::function<void (ccl::RenderTile&)>::operator()(ccl::RenderTile&) const	std_function.h           687 0x33303b5 
18  ccl::CPUDevice::thread_render 						device_cpu.cpp           816 0x332b212

ASAN heap-buffer-overflow (see P859)

When images are packed, Cycles loads them through Blender like EEVEE. So it's the same issue.

This issue has nothing to do with differences between cycles or eevee. It's not an issue between the two render engines, but rather an issue that sort of affects both equally.

It's a color space issue, Cycles and EEVEE use different settings and this will be fixed as part of T54659: Move and share Eevee / Cycles render settings.

Quick floor is probably worth fixing, but it's a pretty low priority corner case.

Can confirm.
(Only the case though we you are already in rendered view -- does not crash if you plug in the volume shader prior to going into rendered view)