break OpenCL calculations into smaller chunks.

[pkienzle]

OpenCL fails if the kernel takes too long to execute. Need to restructure the kernel so that it does the polydispersity calculation in chunks.

The technique will be similar to what is used in the python kernel: increment through the polydispersity hypercube item by item, and determine the cube coordinates with combinations of div and mod. Add an offset and length parameter to the kernel call, and put a for loop around the call stepping offset by N with a length of N until you have traversed the entire set of coordinates. Instead of setting ret[i] each time, increment it with the partial result. If offset starts with 0, then set ret[i]=0 before the loop. Each kernel call should be queued to wait_for the previous kernel call so that you don't get collisions when updating ret[i]. Obviously, offset 0 needs to be called first to initialize the result.

Probably an afternoon of programming.

[butler]

This is part of sasmodels project so should move to that release

[butler]

part of requirements for 4.0 so make blocker

[pkienzle]

Despite feeding only 100 PD steps at a time in sasmodels/kernelcl, the 2-D barbell with 35x35 polydispersity on radius and length caused my macbook pro to reboot.

sasmodels/kernelcl.py(566) Maybe we could add last_call.wait() at the end of the loop in GpuKernel.call()?

[pkienzle]

possible fix, but with a 10% performance penalty

[pkienzle]

The above patch sleeps for 50ms every 500ms, leaving time for OS X to deal with other window events.

Checking every 50 steps introduces a 10% performance penalty for the 1D cylinder model with 35x35 polydispersity on my machine (107 ms to 118 ms); when running barbell 2D with this step size, performance is very laggy. Dropping step to 10 rather than 50 increases the 1D performance penalty to 50% (107 ms to 168 ms), but makes other windows much more responsive.

Would you rather wait 50% less for a fit rather than having responsive behaviour on a model that is otherwise unusable? The top end gaming card calculates the full model in 500 ms with no problems, even without the built-in naps, so the advice to those doing serious 2-D fitting is to get a better machine.

We could probably make steps a function self.q_input.nq and avoid this problem. Even better would be to have an estimate of the compute cost of the kernel, so we could tune this value to be close to 100ms without having to check the clock each cycle.

[pkienzle]

Indeed, setting

    step = 1000000//self.q_input.nq + 1

gives the best of both worlds. The patch needs to be updated.

[pkienzle]

Turned into a pull request:

​https://github.com/SasView/sasmodels/pull/9