Thanks for the tests… But am afraid we cannot much here.

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

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?

Could you please paste your system-info.txt so I can list your gpu for the workaround.

It work perfectly. No more issue on viewport and on render with "--debug-gpu-force-workarounds".

ill fix the materials code so you can view objects clear.

What do I have to do in the file to make the bug appear?

Seems like it crashes now when i try to move anything else to the nodes for it.
Kinda sucks but i guess this is a crash report too.

It seems to not work with any other projects i use it on either. So must be more of a bug then a simple problem. (Tried fireflys fix but no luck).

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

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?

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.

As far as I know GPU render crashes should be fixed since this was reported.

I remember having fixed this problem... I think it was rB117bc96ce88474d3c6b28e669e6ee339441051fb but if this is back, that means your GPU passes through the
detection somehow.

Thanks for being so quick in the response.
I tried everything you said, and I attached the error messages for the -d and --debug-gpu command line arguments, nothing really surprising by the way.
opengl32.dll doesn't seem to do much except it slows blender down quite a lot.
Every other thing you told me doesn't seem to have any effect, anyway now I know that it doesn't crash at a random time, but about after 30 seconds I open it. The same error goes again and again: EXCEPTION_ACCESS_VIOLATION

More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.

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.

Thanks for the report, but there is pretty much nothing we can do with such info, besides stating that issue is most likely due to something in your specific hardware/software config… Some things you can try to narrow it down:

problem still around in build blender-2.80.0-git.925380050d0-windows64

@Brecht Van Lommel (brecht)
I've rendered the scene (it was missing textures so the test wasn't identical) and the total time of render was roughly 15 hours on my Ryzen 5 2600. I believe the issue may be on the users end (E.G. Other programs using the CPU, overheating and thermal throttling on the CPU, etc) but more testing would need to be done to ensure this isn't the case. I'll leave this task with you.

I have the latest recommended driver from Dell.

Cannot confirm (linux 970m), might be tied to Intel 620...

The same scene which yesterday would crash is now rendering fine. :)

@Bohdan Lvov (ostapblender), that sounds like a different issue, to be handled in a new report.

Now it's better and I can render once crashing scene, but if I increase texture size it will show buckets on renderframe and then crash

Confirmed.
Not the case for Eevee though.

@Brecht Van Lommel (brecht): can you have a look?