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 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
