Can you try running blender with the arguments -b --debug-cycles --python-expr "import _cycles; print(_cycles.available_devices())" from the command line and posting the output here?

@Alaska (Alaska) a clean install was made multiple times, with no difference on the number of recognized GPU's

It's supposed to, but it's not happening currently.

Just had a similar issue in T59226

I had the exact same issue. Two RX 570's reported and Blender crashes if the "false" GPU is enabled while rendering. Doing a clean install of the drivers fixed it for me.

@Lukas Stockner (lukasstockner97), looks like you did the last larger refactor in that area. Do you know what is going on?

I can confirm the issue. The problem is we don't offset the vertex color lookup position when doing the bump mapping, like we do for texture coordinates.

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.

@Alexander Gavrilov (angavrilov)
Are you sure about the averaged normals being there when using autosmooth? I have created a simple mesh that I have autosmoothed but the mesh (struct Mesh in code) doesn't seem to have them. Am I looking at the wrong data structure? Is there another way to access per vertex information that has averaged normals?
I have attached an image to detail what the mesh looks like and the Mesh vertex data that goes with it.

My new Target Normal Projection mode in the shrinkwrap modifier (basically intended to address a vaguely similar mapping continuity problem to this) simply uses the vertex normals and thus won't be smooth with edge split either.

The Edge Split modifier is from before Autosmooth worked in the viewport and supported sharp edges and custom normal editing. There are not a lot of people using the modifier anymore, as far as I know. It is mostly there for legacy reasons.

Can confirm, T54133 is related?

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)

Ha, that is right, I tried that, added a sub-surf modifier before the particles as well as a wave modifier and if the "Use Modifier Stack" check box is on, it messes up the colors, but not when its not on like mentioned the particles don't look right (rotation wise) but the colors are right with it off. Also tested in 2.8 and same, it still doesn't work with or without the "Use Modifier Stack" check on...

After checking again, it seems to work on F12 render (cycles). I doesnt work for rendered viewport though (cycles).

Thank you for checking into this Philipp, I have a model I've been working very hard for the past 3 - 4 months on, and I'd love for that to work in 2.8 (everything works but the feathers due to that). It'd be nice to also work in Eevee, not just cycles (eevee is so awesome and fast to render with!!!)

T57922 is related (and there the basic case was working, so this probably broke somewhere along the way...)

Apologies, I was looking at the wrong CUDA version I think. My driver version was still 10.0 and my runtime version was 9.1. But here is the problem I have.. The driver versions are coupled with the graphics driver somehow, I can't figure out how to install the CUDA driver version to a year older version without downgrading my graphics driver to a year old version...

@LazyDodo (LazyDodo) So just to get some clearity, the known CUDA bug you mentioned only applies to 2.80 (while 2.79 used different CUDA code and isn't affected)? And it's now up to NVIDIA to fix this? How does that go together with Blender's apparent policy of trying to keep the used CUDA version low, so older GPUs can still be used? NVIDIA won't release any fix in CUDA 9.x anymore, I suspect.

Also tried the latest hash: a205493426b

Is it worth mentioning this too? Changes to quick_floor?
https://github.com/imageworks/OpenShadingLanguage/pull/912

@Prasanth G (gp), Works with the demo shader on Linux. Could be something platform specific or specific to your setup.

Also tested in the latest 2.8 version Hash: cf18eb2de39 re;eased on 2018-12-02 at 21:35

The smoke domain appearing black was caused by the fact that you'd plugged the "Principled Volume Shader" into the "Surface" output and not the "Volume" output. (Note: Blender crashes for me when switching the "Principled Volume Shader" to the "Volume" output while viewport rendering is activated om frame 1, I'll try to find the cause for this and report it as a bug)

No changes from the previous revision - I have a feeling that I did something wrong when submitting the previous time since I have flagged some of the review as "Done" but the tool insist they are "Unsubmitted". I am not clear if it's my fault but it should be harmless to resubmit the same review.

Couple more comments, might help..

Thanks for the extra files