Hej Philippe, Philippe Tillet <phil.til...@gmail.com> writes: > Sorry for the late answer. I've been extremely busy with my stats homework > lately. > The caching mechanism indeed doesn't account for the device. This is pretty > easy to add, ie append the device name + platform version + platform name > when doing the hashing.
Yes -- this is precisely what I was thinking of doing. If no one gets there first, I'll knock up a patch early tomorrow afternoon (CET). Cheers, Toby > > 2014-11-04 16:12 GMT-05:00 Karl Rupp <r...@iue.tuwien.ac.at>: > >> 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 >> > ------------------------------------------------------------------------------ > > _______________________________________________ > ViennaCL-devel mailing list > ViennaCL-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/viennacl-devel > -- Toby St Clere Smithe http://tsmithe.net ------------------------------------------------------------------------------ _______________________________________________ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
