* [gomp4] Lack of OpenACC NVPTX devices is not an error during scanning @ 2015-05-19 10:40 Julian Brown 2015-05-19 11:02 ` Jakub Jelinek 2015-05-21 15:57 ` Thomas Schwinge 0 siblings, 2 replies; 3+ messages in thread From: Julian Brown @ 2015-05-19 10:40 UTC (permalink / raw) To: gcc-patches [-- Attachment #1: Type: text/plain, Size: 452 bytes --] Hi, This patch fixes an oversight whereby if the CUDA libraries are available for some reason on a system that doesn't actually contain an nVidia card, an OpenACC program will raise an error if the NVPTX backend is picked as a default instead of falling back to some other device instead. OK for gomp4 branch? For trunk? Thanks, Julian ChangeLog libgomp/ * plugin/plugin-nvptx.c (nvptx_get_num_devices): Return zero on cuInit failure. [-- Attachment #2: no-ptx-devices-not-error-1.diff --] [-- Type: text/x-patch, Size: 839 bytes --] commit 696a0d7e22bb8217ff581886cdf0979bfc2e85bb Author: Julian Brown <julian@codesourcery.com> Date: Fri May 15 03:22:56 2015 -0700 Lack of PTX devices is not an error during scanning. diff --git a/libgomp/plugin/plugin-nvptx.c b/libgomp/plugin/plugin-nvptx.c index b36691a..d09a91c 100644 --- a/libgomp/plugin/plugin-nvptx.c +++ b/libgomp/plugin/plugin-nvptx.c @@ -781,7 +781,13 @@ nvptx_get_num_devices (void) until cuInit has been called. Just call it now (but don't yet do any further initialization). */ if (instantiated_devices == 0) - cuInit (0); + { + r = cuInit (0); + /* This is not an error: e.g. we may have CUDA libraries installed but + no devices available. */ + if (r != CUDA_SUCCESS) + return 0; + } r = cuDeviceGetCount (&n); if (r!= CUDA_SUCCESS) ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [gomp4] Lack of OpenACC NVPTX devices is not an error during scanning 2015-05-19 10:40 [gomp4] Lack of OpenACC NVPTX devices is not an error during scanning Julian Brown @ 2015-05-19 11:02 ` Jakub Jelinek 2015-05-21 15:57 ` Thomas Schwinge 1 sibling, 0 replies; 3+ messages in thread From: Jakub Jelinek @ 2015-05-19 11:02 UTC (permalink / raw) To: Julian Brown; +Cc: gcc-patches On Tue, May 19, 2015 at 11:36:58AM +0100, Julian Brown wrote: > This patch fixes an oversight whereby if the CUDA libraries are > available for some reason on a system that doesn't actually contain an > nVidia card, an OpenACC program will raise an error if the NVPTX > backend is picked as a default instead of falling back to some other > device instead. > > OK for gomp4 branch? For trunk? > > Thanks, > > Julian > > ChangeLog > > libgomp/ > * plugin/plugin-nvptx.c (nvptx_get_num_devices): Return zero > on cuInit failure. LGTM. Jakub ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [gomp4] Lack of OpenACC NVPTX devices is not an error during scanning 2015-05-19 10:40 [gomp4] Lack of OpenACC NVPTX devices is not an error during scanning Julian Brown 2015-05-19 11:02 ` Jakub Jelinek @ 2015-05-21 15:57 ` Thomas Schwinge 1 sibling, 0 replies; 3+ messages in thread From: Thomas Schwinge @ 2015-05-21 15:57 UTC (permalink / raw) To: Julian Brown; +Cc: gcc-patches [-- Attachment #1: Type: text/plain, Size: 2866 bytes --] Hi Julian! On Tue, 19 May 2015 11:36:58 +0100, Julian Brown <julian@codesourcery.com> wrote: > This patch fixes an oversight whereby if the CUDA libraries are > available for some reason on a system that doesn't actually contain an > nVidia card, an OpenACC program will raise an error if the NVPTX > backend is picked as a default instead of falling back to some other > device instead. Thanks for fixing this! (Has already been committed to trunk in r223352, and to gomp-4_0-branch in r223351.) Your patch: > --- a/libgomp/plugin/plugin-nvptx.c > +++ b/libgomp/plugin/plugin-nvptx.c > @@ -781,7 +781,13 @@ nvptx_get_num_devices (void) > until cuInit has been called. Just call it now (but don't yet do any > further initialization). */ > if (instantiated_devices == 0) > - cuInit (0); > + { > + r = cuInit (0); > + /* This is not an error: e.g. we may have CUDA libraries installed but > + no devices available. */ > + if (r != CUDA_SUCCESS) > + return 0; > + } > > r = cuDeviceGetCount (&n); > if (r!= CUDA_SUCCESS) In early March, I had noticed the same problem, and came up with the following patch -- but :-( unfortunately never got around to pushing it upstream. I'm now posting my patch just for completeness; I think yours is sufficient/better: no safe-guard should be needed to the cuInit call in nvptx_init, because when that is called, we're rightfully expecting to be able to initialize a PTX device, and in nvptx_get_num_devices, yours is "more conservative" in doing the right thing ("no PTX offloading device available") for all kinds of cuInit errors. commit 6032dde185d0d45d779a1bbf0a5baee7131c0b8c Author: Thomas Schwinge <thomas@codesourcery.com> Date: Sun Mar 1 14:36:02 2015 +0100 libgomp nvptx plugin: Gracefully handle CUDA_ERROR_NO_DEVICE. --- libgomp/plugin/plugin-nvptx.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git libgomp/plugin/plugin-nvptx.c libgomp/plugin/plugin-nvptx.c index 78e705f..0c1e826 100644 --- libgomp/plugin/plugin-nvptx.c +++ libgomp/plugin/plugin-nvptx.c @@ -592,6 +592,8 @@ nvptx_init (void) return -1; r = cuInit (0); + if (r == CUDA_ERROR_NO_DEVICE) + r = CUDA_SUCCESS; if (r != CUDA_SUCCESS) GOMP_PLUGIN_fatal ("cuInit error: %s", cuda_error (r)); @@ -715,7 +717,13 @@ nvptx_get_num_devices (void) until cuInit has been called. Just call it now (but don't yet do any further initialization). */ if (!ptx_inited) - cuInit (0); + { + r = cuInit (0); + if (r == CUDA_ERROR_NO_DEVICE) + return 0; + if (r != CUDA_SUCCESS) + GOMP_PLUGIN_fatal ("cuInit error: %s", cuda_error (r)); + } r = cuDeviceGetCount (&n); if (r!= CUDA_SUCCESS) Grüße, Thomas [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 472 bytes --] ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-05-21 15:50 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-05-19 10:40 [gomp4] Lack of OpenACC NVPTX devices is not an error during scanning Julian Brown 2015-05-19 11:02 ` Jakub Jelinek 2015-05-21 15:57 ` Thomas Schwinge
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).