From patchwork Thu May 21 15:49:27 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Thomas Schwinge X-Patchwork-Id: 475073 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id C0830140187 for ; Fri, 22 May 2015 01:51:05 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=u9n4bP51; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:in-reply-to:references:date:message-id :mime-version:content-type; q=dns; s=default; b=WAtuNWzIq7OTxz/C Tua8T+HSHCxss9cJdUyzALjhEvFgEkNJGpMq5e8t6hH6YJMxNwb6owqW79FwgWLB zteO8/2QC8ROM6VlD/sIkvHh5pwppVJdeq4Ssoxyeh1kY8VJ+dWlD+wt2VmVL4bz 2GjX3ONmdguL1nxI281SEuBsTDw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:in-reply-to:references:date:message-id :mime-version:content-type; s=default; bh=yrATzL+Q3D26Rn3CfEp8rB 7JhQ4=; b=u9n4bP51xA0PRs/D5WO+9AiG3XYtLdUORK79mPshUnMFWeq3vyatCe sgPJXpnlsfo7JMruUduZEnD6sUPqG8DQH6TPPk1AxyU7vMNtLyPb7WLMVmHvQ/D9 J4KgSaVDHi+EQ5BqBqktpTjZ1jJ4dXpn7FmmvUyY5UtOt9G/7jk3I= Received: (qmail 19401 invoked by alias); 21 May 2015 15:50:28 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 19342 invoked by uid 89); 21 May 2015 15:50:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 21 May 2015 15:50:25 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-02.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1YvSjm-0006yj-A9 from Thomas_Schwinge@mentor.com for gcc-patches@gcc.gnu.org; Thu, 21 May 2015 08:50:22 -0700 Received: from feldtkeller.schwinge.homeip.net (137.202.0.76) by SVR-IES-FEM-02.mgc.mentorg.com (137.202.0.106) with Microsoft SMTP Server id 14.3.224.2; Thu, 21 May 2015 16:49:43 +0100 From: Thomas Schwinge To: Julian Brown CC: Subject: Re: [gomp4] Lack of OpenACC NVPTX devices is not an error during scanning In-Reply-To: <20150519113658.20df46ff@octopus> References: <20150519113658.20df46ff@octopus> User-Agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/24.4.1 (i586-pc-linux-gnu) Date: Thu, 21 May 2015 17:49:27 +0200 Message-ID: <871tiand6g.fsf@kepler.schwinge.homeip.net> MIME-Version: 1.0 Hi Julian! On Tue, 19 May 2015 11:36:58 +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. 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 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(-) Grüße, Thomas 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)