Hi Toby, it certainly has to do with your scalar_vector. Have a look at the documentation for fast_copy:
http://viennacl.sourceforge.net/doc/namespaceviennacl.html#a815cf9646ece6cc98ec80b3f925c482d "However, keep in mind that the cpu type MUST represent a linear piece of memory, otherwise you will run into undefined behavior." An ublas::scalar_vector<T> is only a proxy type and does not hold actual data, so you'll run into invalid reads. A great tool for finding such things is valgrind. Best regards, Karli On 08/01/2013 06:56 PM, Toby St Clere Smithe wrote: > Hi, > > Last thing from me for the night, but I've just swapped to using async_ > then fast_copy instead of plain old copy for vectors -- and both give me > a segfault using nvidia's libopencl. Is there anything debuggable in > this case, since the damn thing is closed source? The backtrace is: > > #0 0x00007ffff14def62 in ?? () from > /usr/lib/nvidia-319/libnvidia-opencl.so.319.32 > #1 0x00007ffff14756fd in ?? () from > /usr/lib/nvidia-319/libnvidia-opencl.so.319.32 > #2 0x00007ffff143a113 in ?? () from > /usr/lib/nvidia-319/libnvidia-opencl.so.319.32 > #3 0x00007ffff143a9a9 in ?? () from > /usr/lib/nvidia-319/libnvidia-opencl.so.319.32 > #4 0x00007ffff14e27bd in ?? () from > /usr/lib/nvidia-319/libnvidia-opencl.so.319.32 > #5 0x00007ffff14e4b0d in ?? () from > /usr/lib/nvidia-319/libnvidia-opencl.so.319.32 > #6 0x00007ffff14f4ff9 in ?? () from > /usr/lib/nvidia-319/libnvidia-opencl.so.319.32 > #7 0x00007ffff14f5b23 in ?? () from > /usr/lib/nvidia-319/libnvidia-opencl.so.319.32 > #8 0x00007ffff14ee604 in ?? () from > /usr/lib/nvidia-319/libnvidia-opencl.so.319.32 > #9 0x00007ffff2dec175 in memory_write (async=<optimised out>, > ptr=0x7fffffffd5b8, > bytes_to_copy=8192, dst_offset=0, dst_buffer=...) > at /home/toby/src/viennacl/pyviennacl-dev/viennacl/backend/opencl.hpp:109 > #10 viennacl::backend::memory_write (dst_buffer=..., dst_offset=0, > bytes_to_write=8192, ptr=0x7fffffffd5b8, async=<optimised out>) > at /home/toby/src/viennacl/pyviennacl-dev/viennacl/backend/memory.hpp:235 > #11 0x00007ffff2e0fdde in > fast_copy<boost::numeric::ublas::scalar_vector<double, std::allocator<double> > >::const_iterator, double, 1u> (gpu_begin=..., cpu_end=..., > cpu_begin=...) > at /home/toby/src/viennacl/pyviennacl-dev/viennacl/vector.hpp:1435 > > > I haven't tried not using a boost scalar_vector -- maybe that's got > something to do with it, but I don't know enough about the underlying > implementations to tell a priori. > > > Bonne nuit and schalf gut, > > Toby > > > ------------------------------------------------------------------------------ > Get your SQL database under version control now! > Version control is standard for application code, but databases havent > caught up. So what steps can you take to put your SQL databases under > version control? Why should you start doing it? Read more to find out. > http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk > _______________________________________________ > ViennaCL-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/viennacl-devel > ------------------------------------------------------------------------------ Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk _______________________________________________ ViennaCL-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/viennacl-devel
