This is like delaying the problem to happen. While initial startup of Blender might happen fine, at the moment someone would try to enable GPU compute Blender will crash. Or even worse, after initial setup is done and something was updated in the OS Blender will crash again.

So to me it seems to fully address root of the issue querying devices in a subprocess is the only reliable way.

Letting a process crash each time Blender starts up is not good either in my opinion. If the user did not enable GPU rendering in the preferences, we should not be querying it.

We can do the separate process in addition to this.

Letting a process crash each time Blender starts up is not good either in my opinion.

If Windows will show an "Application has crashed, send report to developers?" message box then sure. Otherwise i don't see big issue.

If the user did not enable GPU rendering in the preferences, we should not be querying it.

But we do query other things. Like tablets, space navigators, audio system. Guess the main difference is that those are not crashing that often.

Not saying i'm advocating leaving crash here, but here are my thoughts:

• From the user perspective, is a bit weird to require them to bother about OpenCL/CUDA. In an ideal world just show them compute devices.
• Before this change users almost never saw both CUDA and OpenCL, so that wasn't too much of a confusion.
• What if we ever support OptiX? We would need to merge CUDA and OptiX devices anyway, and initialize both libraries. Which also potentially increases probability of crashes.
• Even if we solve the initial startup crash, this doesn't solve issue of drivers *becoming* "corrupted" (windows update *shrug*). That will lead to constant crashes of Cycles and user Preferences again.
• This doesn't seem to be solving crash on a buggy system when one generates system info? Not sure how good of an idea of not including platform information about potentially usable but not enabled devices.

Do we know which exact part crashes? Is it dlopen of OpenCL IDC? Enumerating platforms? Enumerating specific platform? There is some binary compiled by myself a while back to help nailing down such issues: https://download.blender.org/ftp/sergey/clinfo/

Can you reproduce crash on your system?

In D4265#96503, @Sergey Sharybin (sergey) wrote:

If Windows will show an "Application has crashed, send report to developers?" message box then sure. Otherwise i don't see big issue.

I don't trust crashing the OpenCL drivers right before starting Blender. Ideally it's all safe and isolated, but graphics drivers are not that predictable.

• From the user perspective, is a bit weird to require them to bother about OpenCL/CUDA. In an ideal world just show them compute devices.
• Before this change users almost never saw both CUDA and OpenCL, so that wasn't too much of a confusion.
• What if we ever support OptiX? We would need to merge CUDA and OptiX devices anyway, and initialize both libraries. Which also potentially increases probability of crashes.

I don't think there will be confusion, users can click the settings and see where the devices are. It's slightly less convenient, but not a real problem. We can still have a GPU rendering on/off toggle in the future where we detect both types of devices.

• Even if we solve the initial startup crash, this doesn't solve issue of drivers *becoming* "corrupted" (windows update *shrug*). That will lead to constant crashes of Cycles and user Preferences again.
• This doesn't seem to be solving crash on a buggy system when one generates system info? Not sure how good of an idea of not including platform information about potentially usable but not enabled devices.

Yes, it doesn't solve those problems. System info still includes all devices. But at least it will crash doing a specific action that gives a clue about where the problem is, and keeps the rest of Blender usable.

Do we know which exact part crashes? Is it dlopen of OpenCL IDC? Enumerating platforms? Enumerating specific platform? There is some binary compiled by myself a while back to help nailing down such issues: https://download.blender.org/ftp/sergey/clinfo/

Can you reproduce crash on your system?

We've never been able to reproduce the problem ourselves, nor do we know the extent of the problem. It might be very rare and not worth the code complexity of running a separate process. We regularly get "Blender crashes on startup" reports, and it would be nice to exclude this possibility.

In one case it crashed in clGetPlatformIDs() doing some kind of internal initialization. This is the very first function we call.

This was a simple change to make. Either it solves startup crashes for a bunch of users and tells us that this is in fact a common problem, and we can spend time to make it better. Or it makes no difference and we save time.

@Brecht Van Lommel (brecht) @Sergey Sharybin (sergey) Do the changes here resolve this as well --> https://developer.blender.org/T57813 ?

Yes, they resolve that as well.

@Brecht Van Lommel (brecht) Is it possible to have this in Blender 2.8 as well?

Everything in 2.7 ends up in 2.8, just not always immediately.

Hmm, this all doesn't sound exactly like the problem i have in mind... but just in case:
There is a Windows feature called Timeout Detection and Recovery (TDR) causing a complete GPU reset.
The SubstancePainter people wrote a nice explanation and fix for that:
https://docs.substance3d.com/spdoc/gpu-drivers-crash-with-long-computations-128745489.html

It seems not so well know accross the deveopers (i found this problem across various projects on the internet) and
it often leads to month long bug searching, wasting the precious developers time.

So, please spread the word to all Blender developers!

This code review is unrelated to TDR.