Hey hey, Philippe Tillet <phil.til...@gmail.com> writes: > I cannot reproduce the bug on my machine, so it's probably better if you > patch it :) Because a context may be attached to multiple devices, the fix > should concatenate the information of each device. > >>>>> line 402 > std::string prefix; > for(std::vector< viennacl::ocl::device >::const_iterator it = > devices_.begin() ; it != devices_.end() ; ++it) > prefix += it->name() + it->vendor() + it->driver_version() > std::string sha1 = prefix + tools::sha1(source); > > I can't think of any other place where a change would be necessary
There was another place further down the same file (where the cache files are written). It now works nicely, and this is clearly an improvement over the haphazard state before; but I have a small concern before committing the patch: I presume it is SDK-dependent, but are there any guarantees about program binary compatibility? To make this more concrete: do we really need a separate binary for every combination of devices in a context? I can envisage a situation where a user has (eg) two AMD devices in a context one day, but another day has just one. Do we need to build separate binaries for these cases, or can we just keep them separate for contexts associated with different platforms? Best, Toby > 2014-11-04 16:32 GMT-05:00 Toby St Clere Smithe <m...@tsmithe.net>: > >> 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 >> > ------------------------------------------------------------------------------ > > _______________________________________________ > 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
