Hey,

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.

Philippe

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

Reply via email to