public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Chung-Lin Tang <chunglin_tang@mentor.com>
To: "Maciej W. Rozycki" <macro@codesourcery.com>, <gcc-patches@gcc.gnu.org>
Cc: Thomas Schwinge <thomas@codesourcery.com>,
	Chung-Lin Tang	<cltang@codesourcery.com>,
	Jakub Jelinek <jakub@redhat.com>,
	Catherine Moore	<clm@codesourcery.com>,
	Tom de Vries <tdevries@suse.de>
Subject: Re: [PATCH, og8] Add OpenACC 2.6 `acc_get_property' support
Date: Wed, 05 Dec 2018 10:12:00 -0000	[thread overview]
Message-ID: <50db7b32-5227-7ad9-f3bc-ca032f447b0c@mentor.com> (raw)
In-Reply-To: <alpine.DEB.2.21.9999.1812031551070.55818@build7-trusty-cs.sje.mentorg.com>

Hi Maciej, please see below:

On 2018/12/4 12:51 AM, Maciej W. Rozycki wrote:
> +module openacc_c_string
> +  implicit none
> +
> +  interface
> +    function strlen (s) bind (C, name = "strlen")
> +      use iso_c_binding, only: c_ptr, c_size_t
> +      type (c_ptr), intent(in), value :: s
> +      integer (c_size_t) :: strlen
> +    end function
> +  end interface
> +
> +end module

> +subroutine acc_get_property_string_h (n, d, p, s)
> +  use iso_c_binding, only: c_char, c_int, c_ptr, c_f_pointer
> +  use openacc_internal, only: acc_get_property_string_l
> +  use openacc_c_string, only: strlen
> +  use openacc_kinds
...> +  pint = int (p, c_int)
> +  cptr = acc_get_property_string_l (n, d, pint)
> +  clen = int (strlen (cptr))
> +  call c_f_pointer (cptr, sptr, [clen])

AFAIK, things like strlen are already available in iso_c_binding, in forms like "C_strlen".
Can you check again if that 'openacc_c_string' module is really necessary?

> +union gomp_device_property_value
> +GOMP_OFFLOAD_get_property (int n, int prop)
> +{
> +  union gomp_device_property_value propval = { .val = 0 };
> +
> +  pthread_mutex_lock (&ptx_dev_lock);
> +
> +  if (!nvptx_init () || n >= nvptx_get_num_devices ())
> +    {
> +      pthread_mutex_unlock (&ptx_dev_lock);
> +      return propval;
> +    }
> +
> +  switch (prop)
> +    {
> +    case GOMP_DEVICE_PROPERTY_MEMORY:
> +      {
> +	size_t total_mem;
> +	CUdevice dev;
> +
> +	CUDA_CALL_ERET (propval, cuDeviceGet, &dev, n);
> +	CUDA_CALL_ERET (propval, cuDeviceTotalMem, &total_mem, dev);
> +	propval.val = total_mem;
> +      }
> +      break;
> +    case GOMP_DEVICE_PROPERTY_FREE_MEMORY:
> +      {
> +	size_t total_mem;
> +	size_t free_mem;
> +	CUdevice ctxdev;
> +	CUdevice dev;
> +
> +	CUDA_CALL_ERET (propval, cuCtxGetDevice, &ctxdev);
> +	CUDA_CALL_ERET (propval, cuDeviceGet, &dev, n);
> +	if (dev == ctxdev)
> +	  CUDA_CALL_ERET (propval, cuMemGetInfo, &free_mem, &total_mem);
> +	else if (ptx_devices[n])
> +	  {
> +	    CUcontext old_ctx;
> +
> +	    CUDA_CALL_ERET (propval, cuCtxPushCurrent, ptx_devices[n]->ctx);
> +	    CUDA_CALL_ERET (propval, cuMemGetInfo, &free_mem, &total_mem);
> +	    CUDA_CALL_ASSERT (cuCtxPopCurrent, &old_ctx);
> +	  }
> +	else
> +	  {
> +	    CUcontext new_ctx;
> +
> +	    CUDA_CALL_ERET (propval, cuCtxCreate, &new_ctx, CU_CTX_SCHED_AUTO,
> +			    dev);
> +	    CUDA_CALL_ERET (propval, cuMemGetInfo, &free_mem, &total_mem);
> +	    CUDA_CALL_ASSERT (cuCtxDestroy, new_ctx);
> +	  }

(I'm CCing Tom here, as he is maintainer for these parts)

As we discussed earlier on our internal list, I think properly using GOMP_OFFLOAD_init_device
is the right way, instead of using the lower level CUDA context create/destroy.

I did not mean for you to first init the device and then immediately destroy it by
GOMP_OFFLOAD_fini_device, just to obtain the property, but for you to just take the opportunity to initialize
it for use, and leave it there until program exit. That should save resources overall.
(BTW, CUDA contexts should be quite expensive to create/destroy, using a cuCtxCreate/Destroy pair is probably
almost as slow)

Tom, do you have any comments on how to best write this part?

Thanks,
Chung-Lin

  reply	other threads:[~2018-12-05 10:12 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-03 16:51 Maciej W. Rozycki
2018-12-05 10:12 ` Chung-Lin Tang [this message]
2018-12-05 18:17   ` Maciej W. Rozycki
2018-12-10  9:06     ` Chung-Lin Tang
2018-12-20 14:25       ` Maciej W. Rozycki
2019-01-08 17:42 ` Thomas Schwinge
2019-10-07 18:41 ` Thomas Schwinge
2019-11-05 15:09   ` Harwath, Frederik
2019-11-14 15:41   ` [PATCH] " Frederik Harwath
2019-12-16 23:06     ` Thomas Schwinge
2019-12-17  9:39       ` Martin Jambor
2019-12-17  9:47       ` Andrew Stubbs
2019-12-20 17:11       ` Harwath, Frederik
2019-12-21 23:01         ` Thomas Schwinge
2019-12-22 22:20           ` Harwath, Frederik
2020-01-10 23:44           ` Thomas Schwinge
2020-01-30 16:14             ` Make OpenACC 'acc_get_property' with 'acc_device_current' work (was: [PATCH] Add OpenACC 2.6 `acc_get_property' support) Thomas Schwinge
2020-02-03 12:16               ` Harwath, Frederik
2020-02-03 14:41               ` Make OpenACC 'acc_get_property' with 'acc_device_current' work Tobias Burnus
2020-01-16 16:03         ` [PATCH] Add OpenACC 2.6 `acc_get_property' support Thomas Schwinge
2020-01-20 14:20           ` Harwath, Frederik
2020-01-23 15:08             ` Thomas Schwinge
2020-01-24  9:36               ` Harwath, Frederik
2020-01-27 14:57         ` Fortran 'acc_get_property' return type (was: [PATCH] Add OpenACC 2.6 `acc_get_property' support) Thomas Schwinge
2020-01-28 15:31         ` [PATCH] Add OpenACC acc_get_property support for AMD GCN Harwath, Frederik
2020-01-28 16:14           ` Andrew Stubbs
2020-01-29 10:10             ` Harwath, Frederik
2020-01-29 11:07               ` Andrew Stubbs
2020-01-29 11:47                 ` Harwath, Frederik
2020-01-29 17:58               ` Thomas Schwinge
2020-01-29 18:12                 ` Andrew Stubbs
2020-01-30  8:04                 ` Harwath, Frederik
2020-01-30 16:28               ` Thomas Schwinge
2020-01-30 16:54                 ` Andrew Stubbs
2020-01-31  9:32                   ` Thomas Schwinge
2020-01-31 12:32                 ` Harwath, Frederik
2020-01-31 14:49                   ` Thomas Schwinge
2020-04-29  9:19       ` [PATCH] Add OpenACC 2.6 `acc_get_property' support Thomas Schwinge

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50db7b32-5227-7ad9-f3bc-ca032f447b0c@mentor.com \
    --to=chunglin_tang@mentor.com \
    --cc=clm@codesourcery.com \
    --cc=cltang@codesourcery.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=macro@codesourcery.com \
    --cc=tdevries@suse.de \
    --cc=thomas@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).