Hi Toby, >> 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. > > Yes, and cf my other mail!..
In a perfect world we would not have to mess with imperfections of the OpenCL and CUDA compilers - but unfortunately the world is not perfect... There are a few more things we can do to improve the feedback of such failures, though, but we can't magically fix underlying compiler crashes. >> ViennaCL used to dump the build log and the kernel sources. You should >> see the same? > > It still does, but in this case, it never got that far! Hmm, not good... >>> 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. > > Aha. If you can spare the time to add that, that would be great, but if > not, I can add another check to the PyViennaCL dispatch mechanism. I > really don't mind (though of course there's less overhead in C++). I'll try to come up with a fix for that later today, I don't think it requires huge amounts of magic. While we are at it: Finally almost all portability troubles have been addressed, so I will only go through one final round of nightly tests and release tomorrow. Best regards, Karli ------------------------------------------------------------------------------ _______________________________________________ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
