Bindings for VexCL about viennacl-dev

[ddemidov]

What kind of examples are you thinking of? Could something like this work?

[karlrupp]

Yep. Basically providing copy() functionality as well as wrappers for the solvers, yes. We could also just keep the wrappers in VexCL if you think this is more appropriate.

[ddemidov]

Can one currently do anything actually useful with vexcl bindings? I mean, are there any preconditioners in viennacl that may use limited functionality (expression templates, inner products, etc) of vexcl? Standalone solvers like CG or BiCGStab are not that useful for large problem sizes.

[karlrupp]

I assume that there will always be some functionality available in one library and not the other, so (in my small world) it makes sense to provide a convenient exchange mechanism

[ddemidov]

I agree with that, I just wanted to understand where is the better place for the exchange code. Currently it seems that VexCL users need ViennaCL algorithms more than ViennaCL users need VexCL types. So it is probably job of VexCL to provide the exchange mechanisms. Anyway, if one wants to use both libraries, then both code bases should be available, so it does not really matter.

I only would like to make sure that as much functionality from ViennaCL is usable with VexCL types as possible. Is inner_prod, prod, norm2, and clear all that could possibly be of need? (https://github.com/ddemidov/vexcl/blob/master/vexcl/external/viennacl.hpp)

[karlrupp]

Yeah, for now these functions are the only ones wrapped for the other bindings as well. Operator overloading is a silent prerequisite at the moment (similar to the default algebra in odeint) and taking care of most of the standard operations. I don't know whether it's worth relaxing this constraint.

[ddemidov]

I see.

When you mentioned copy() functionality, did you mean copying between viennacl::vectors and vex::vectors? This is straightforward if vexcl context only contains single compute device, but in general copy should go through host memory (which is as simple).

Also, it is possible to wrap vex::vector around raw OpenCL buffer, so in case of single compute device same device memory may be operated on both through viennacl and vexcl interfaces.

[karlrupp]

Considering that the interfacing code is in VexCL already and a duplication of bindings would lead to bad behavior, let's keep it as-is. Feel free to reopen if circumstances change.