Hi Toby, > OK, so 2 more weird problems. The rest of my tests pass (but I still > don't quite have complete test coverage).
I fixed a couple of minor problems today, which should finally result in practically full success of the nightly test suite. One of them might be the cause of your first item, which showed up as build errors on NVIDIA GPUs. > 1. Cache issues continue: > > On both nVidia and Beignet, I get some error and a segfault like this on > sparse gemv: > > Build Status = -2 ( Err = -11 ) > > The segfault happens when calling (in ocl/context.hpp): > > 443 err = clGetProgramBuildInfo(temp, devices_[0].id(), > CL_PROGRAM_BUILD_LOG, 0, NULL, &ret_val_size); > > Now, the cache prefix seems correct (at least inspecting it with 'info > locals' in gdb doesn't give a cross-device collision), and this happens > even with a clean cache. > > source_text = 0x1c8b828 "__kernel void vec_mul( \n __global const unsigned > int * coords, \n __global const float * elements, \n __global const float * > x, \n uint4 layout_x, \n __global float * result, \n uint4 layout_result, > ".. > > But the preceding call (before the failed buildProgram) works: > > 427 temp = clCreateProgramWithSource(h_.get(), 1, (const char > **)&source_text, &source_size, &err); > > So I'm not sure what to make of this.. ViennaCL used to dump the build log and the kernel sources. You should see the same? > 2. I get a lot of failures from test_matrix_operations.py, too, which > did not happen before. One time, I also got a segfault, but because I > was outside of a debugger, I did not catch it; I cannot yet reliably > reproduce it. The failures are all of the form > > Assign(Matrix:float64, ElementFabs(Sub(Matrix:float64, > Sub(Mul(Trans(Matrix:float64)=>Matrix:float64, > Scalar:float64)=>Matrix:float64, > Trans(Matrix:float64)=>Matrix:float64)=>Matrix:float64)=>Matrix:float64)=>Matrix:float64) > > and they produce this exception: > > ViennaCL: Internal error: The scheduler encountered a problem with the > operation provided: Cannot deal with unary operations on vectors > > I think the defining feature is the ElementFabs of some expression > involving a Trans, and I think these are now occurring because I > disabled an old bit of code: previously, I dispatched the matrix > transposition before the rest of the statement, because expressions > involving trans weren't supported by the scheduler. But then Philippe > pointed out that this made autotuning such expressions impossible, so I > disabled that dispatch. It seems there are some bits where this remains > unsupported, so I'll have a think about what to do. The core does not support composite expressions involving trans(), e.g A + trans(A) What is currently supported is: A = prod(trans(B), C); A = prod(B, trans(C)); A = prod(trans(B), trans(C)); A = solve(trans(B), C, (unit_)upper_tag or (unit_)lower_tag); A = solve(B, trans(C), (unit_)upper_tag or (unit_)lower_tag); A = solve(trans(B), trans(C), (unit_)upper_tag or (unit_)lower_tag); y = prod(trans(A), x); A = trans(B); I could fix up the scheduler such that it creates a temporary when encountering trans() in any other operation, though. Best regards, Karli ------------------------------------------------------------------------------ _______________________________________________ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
