Hi, > This has been a nightmare to make the opencl kernels device-specific. > I'm facing a dependency problem which traits cannot solve. The reason is > the following: > > -> The kernel generator requires some traits (row_major(), size(), > internal_size2(), etc.) > -> The generator is now included in linalg/opencl/kernels/vector.hpp, > hence it is included from viennacl/vector.hpp > -> There is no dependency between vector.hpp and matrix.hpp, which is a > very good thing.
I noticed this somewhat circular dependency when I checked that all headers are self-sufficient. It could be resolved via removing unnecessary includes back then, but it wasn't easy. > Considering all these informations, vector-only files such as > vector_float_double-test-opencl will fail to compile because the > generator uses e.g. traits:row_major(), and matrix.hpp is not included > (so matrix_base is declared but not defined). > > An extremly bad solution would be to have two versions of the generator > (one for vector-only statements, one for other). Yes, this is indeed bad ;-) > A better option would > be to split matrix.hpp into two files, one containing the definition of > the class only, to make the traits usable without having to include the > whole library. > > What do you think about it? Is it enough to split off the class definition in matrix.hpp? There are some operator overloads defined inside the class definition right now for reasons of implicit conversions, so it may be quite hard to split them off. In the end, it may not even be enough to split the files, because the circular dependency is a data type dependency, not just a file level dependency. I thought about splitting matrix_base into a type that takes care of the user interface (operator overloads, etc.) and a type which only holds the data (and can be included by the generator to get information such as row-major, etc.). As this would probably be a good share of the preparation for linking with external BLAS libraries, we might as well want to go down that route anyway. Either way, I'm afraid that this is not just a tiny refactoring, but touches larger (internal) parts of the library. If a simple file split is enough, I'm not against it - just don't expose it to the user. Best regards, Karli ------------------------------------------------------------------------------ The best possible search technologies are now affordable for all companies. Download your FREE open source Enterprise Search Engine today! Our experts will assist you in its installation for $59/mo, no commitment. Test it for FREE on our Cloud platform anytime! http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clktrk _______________________________________________ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
