Hello On Wed, Jul 8, 2020 at 5:08 AM Jakub Jelinek <ja...@redhat.com> wrote:
> On Tue, Jul 07, 2020 at 02:52:37PM -0400, y2s1982 . via Gcc-patches wrote: > > I have re-read the documentation trying to find a different solution. > > In particular, ompd_device_initialize states that > > ompd_device_t kind, ompd_size_t sizeof_id, and void *id represents > > a device identifier. To dig further, I read up on the ompd_device_t. A > > passage from ompd_device_t says that the OMPD library and a tool that > uses > > it must agree on the format of the object that is passed. > > It also says that ompd_device_t is a pointer to where the device > identifier > > is stored and the size of the device identifier. I am not sure how this > > works to ompd_device_initialize as those two information seems to be > > supplied separately: *id and sizeof_id. In fact, ompd-type.h provides 4 > > examples, 2 of which are host and cuda, and they all simply contain > unique > > numerical values. So does this mean that I should just decide on what > the > > library and tool will use for device id data type and simply stick to it? > > > > Otherwise, Is it possible to know the proper data type to cast the void > *id > > based on the device type (host/cuda)? > > Looking at libompd, it ignores sizeof_id completely and saves id (the > pointer) in its device context, but doesn't ever do anything with it, so > effectively ignores it completely. > > I think starting with devices it not a good idea, just return failure from > ompd_device_initialize for now and get back to it much later, when > handling of parallel, host teams, task etc. is all done. > Because communicating with devices will need also communication with the > libgomp plugins. > Thank you for the guidance. I have uploaded an updated patch where ompd_device_initialize() ultimately returns an error. I have also added FIXME for future planning. Tony > > Jakub > >
