Review OpenCL format's non-calling of init() in loader when using --fork

[magnumripper]

#4426 (comment)

How/why do we get away with not calling fmt_init when options.acc_devices->count && options.fork && strstr(alt->params.label, "-opencl"), or in plain english "running soon-to-be-forked with a GPU format" (a.k.a poor man's multi-GPU support)?

Is it just post-poned? Are we relying on some undocumented (non-)property of all current OpenCL formats? What property? I think many formats don't actually require an init() but we should document what we are relying on here.

[magnumripper]

OK so it's origin is 1a3fa73. We post-pone init until right after forking. I can see why that is/was needed, but indeed it puts some requirements on the format: Basically their binary() and salt() need to be usable without init(). That's usually not a problem.

This might all be obsolete though: At the time we did this, all OpenCL formats had heavy init functions, building kernels and performing the auto-tune (and that auto-tune could take ages compared to nowadays). Current formats postpones all that anyway, until reset() (I'm not sure about ztex formats but I guess they'll better mimic OpenCL in that regard). The only thing left in init() is opencl_prepare_dev();. Perhaps we can now drop this special code in loader? We should try. Or maybe that call to opencl_prepare_dev() still needs to be made after forking.

[solardiz]

it puts some requirements on the format: Basically their binary() and salt() need to be usable without init(). That's usually not a problem.

Yet we should document it in the comment in formats.h.

Perhaps we can now drop this special code in loader? We should try. Or maybe that call to opencl_prepare_dev() still needs to be made after forking.

I guess some OpenCL backends could be confused by initialization from one process followed by use from a forked child. I seem to vaguely recall you mentioning such issues before, but it could be a false memory.