Hey, 2014-11-06 8:59 GMT-05:00 Karl Rupp <r...@iue.tuwien.ac.at>:
> 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. > > It is hard to tell whether the problem is on our part or not. Very subtle corruptions can cause any weird thing to happen, such as a segfault in strlen... It is not unlikely that the developer of the OpenCL compilers think the same way, ie "In a perfect world we would not have to mess with applications imperfections" :-p Toby, can you run dmesg | NVRM and see if anything weird is happening when it segfaults? > >> 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 >
------------------------------------------------------------------------------
_______________________________________________ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
