Hi Toby, >> >> thanks for the reports. I'll run the respective functions through a >>>> valgrind-like environment today, but I don't expect something to show up >>>> at this point. The direct solve kernels for dense matrices are unchanged >>>> for quite some time and haven't shown anything suspicious in the nightly >>>> tests for *months* now. Thus, I'm very tempted to assume that this is a >>>> problem with beignet - yet I'll double-check. >>> >>> Yes, I think so, too, now. But it is weird that I received a segfault on >>> nVidia initially, too. I haven't studied the kernel caching mechanism: >>> at the moment, the PyViennaCL cache directory is versioned, but should >>> it also be separate for different devices? (And I will need to remember >>> to clear out the cache directory for different viennacl git revisions, >>> or add a mechanism to include the git reference..) >> >> The caching mechanism computes a hash of the source code and uses that >> hash to access the binary object. I doubt that there is binary >> compatibility across different OpenCL SDKs. > > Yes, having now updated my beignet installation to the latest point > release and tested various combinations of stale and clean caches, it > seems like the tests pass successfully and without segfaults when there > is no overlap of the cached objects across devices.
Thanks, this is good news. I'm fighting with some low-level hardware here right now, pretty challenging to get this to work properly :-( >> Philippe, does the caching mechanism take that into account and store >> separate binaries for each OpenCL SDK? Or is the SDK name part of the hash? > > It seems not to do so. I can change this in PyViennaCL, but I don't know > if it might be good to do as you suggest and have the SDK name part of > the hash in the core. I can always change it in PyViennaCL for this > release, and this could be postponed for the core till later. A change of the OpenCL platform is fairly unlikely, so we may be able to go without. But on the other hand, it may lead to some hard-to-debug failures, just like you observed now. I leave this decision up to you... Best regards, Karli ------------------------------------------------------------------------------ _______________________________________________ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
