I think for the current time, we need to disable the optimization that
would introduce Op that support only cuda. That way, we OpenCL back-end
will work, but will have only a few ops working.

Don't forget, the multi-GPU is more important then OpenCL. So we should
focus on that before.

As said previously, when we will annouce in beta the new back-end, I'll ask
for help on the conversion to OpenCL.


On Thu, Apr 24, 2014 at 1:49 PM, abergeron <notifications@github.com> wrote:

> In theano/sandbox/gpuarray/opt.py:
>
> > @@ -241,6 +244,23 @@ def local_gpua_incsubtensor(node):
> >      return GpuIncSubtensor(node.op.idx_list, node.op.inplace,
> >                             node.op.set_instead_of_inc,
> >                             node.op.destroyhandler_tolerate_aliased)
> > +
> > +
> > +@register_opt()
> > +@op_lifter([tensor.AdvancedIncSubtensor1])
> > +def local_gpua_advanced_incsubtensor(node):
> > +    x, y = node.inputs[0:2]
> > +    coords = node.inputs[2:]
> > +    set_instead_of_inc = node.op.set_instead_of_inc
> > +    active_device_no = theano.sandbox.cuda.active_device_number()
> > +    compute_capability = device_properties(active_device_no)['major']
>
> I should add that I don't like adding cuda-only code traps like that since
> I feel that the more we pile on, the less chance there is that we will ever
> support OpenCL.
>
> Also, if there is a need for new abstractions for things like making sure
> that atomicAdd is supported on the device (which is what this is testing
> for even if it's not obvious), I'm open to adding those to libgpuarray, but
> I would have to know about it.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/Theano/Theano/pull/1816/files#r11961377>
> .
>