On 03 Feb 13:00, Julian Brown wrote: > On Tue, 3 Feb 2015 14:28:44 +0300 > Ilya Verbin <iver...@gmail.com> wrote: > > On 27 Jan 14:07, Julian Brown wrote: > > > On Mon, 26 Jan 2015 17:34:26 +0300 > > > Ilya Verbin <iver...@gmail.com> wrote: > > > > Here is my current patch, it works for OpenMP->MIC, but obviously > > > > will not work for PTX, since it requires symmetrical changes in > > > > the plugin. Could you please take a look, whether it is possible > > > > to support this new interface in PTX plugin? > > > > > > I think it can probably be made to work. I'll have a look in more > > > detail. > > > > Do you have any progress on this? > > I'm still working on a patch to update OpenACC support and the PTX > backend to use load/unload_image and to unify initialisation/"opening". > So far I think the answer is basically "yes, the new interface can be > supported", though I might request a minor tweak -- e.g. that > load_image takes an extra "void **" argument so that a libgomp backend > can allocate a block of generic metadata relating to the image, then > that same block would be passed (void *) to the unload hook so the > backend can use it there and deallocate it when it's finished with. > > Would that be possible? (It'd mostly be for a "CUmodule" handle: this > could be stashed away somewhere within the nvptx backend, but it might > be neater to put it in generic code since it'll probably be useful for > other backends anyway.)
An extra argument is not a problem, however I don't quite get the idea. PTX plugin allocates some data while loading, and needs this data while unloading? Then why not to create a hash table with image_ptr -> metadata mapping inside the plugin? In this case, to the unload hook can deallocate metadata using the image_ptr key. Since this metadata is target-specific, I believe it would be better to keep it inside the plugin. -- Ilya
