From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa4.mentor.iphmx.com (esa4.mentor.iphmx.com [68.232.137.252]) by sourceware.org (Postfix) with ESMTPS id 7009F385E45D for ; Tue, 5 Apr 2022 15:14:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7009F385E45D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-IronPort-AV: E=Sophos;i="5.90,236,1643702400"; d="scan'208";a="74050173" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa4.mentor.iphmx.com with ESMTP; 05 Apr 2022 07:14:47 -0800 IronPort-SDR: 08XQ42z5qgrOw7WDuSUCTVdSYV9eAmbvsKfz8O6EGNTTg6SnI0KgF+K4q0xNXqJLEkky3v6h73 Vu3YtkS4iyMIaWhZ1joN8gUAmhI5jbIVmDSqAQ/VsG9HGSiWddAwi6KefASrZX9i5obxXJ9DI9 mPh9u+rYNzzdQPY9ynZR80H8TzNHOmzLOCwKnGEHT7WUr7CUGB9tODVKcQioECD7HJBQ2w2fKl BVkNP4bU2OkIa5ZA4XZDbjBAR+hpsTdqpnh9sXhwgl71YfRK3kQ2R0hN4T16fIq5xjNmWyEip8 2/Q= From: Thomas Schwinge To: Tom de Vries , Jakub Jelinek CC: , Tobias Burnus , "Roger Sayle" Subject: Proposal to remove '--with-cuda-driver' (was: [wwwdocs][patch] gcc-12: Nvptx updates) In-Reply-To: References: <1ffa4e66-af1a-4392-795a-31a8f0047c92@codesourcery.com> User-Agent: Notmuch/0.29.3+94~g74c3f1b (https://notmuchmail.org) Emacs/27.1 (x86_64-pc-linux-gnu) Date: Tue, 5 Apr 2022 17:14:27 +0200 Message-ID: <87ee2bh8a4.fsf@euler.schwinge.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: SVR-IES-MBX-07.mgc.mentorg.com (139.181.222.7) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2022 15:14:50 -0000 Hi! Still catching up with GCC/nvptx back end changes... %-) In the following I'm not discussing the patch to document "gcc-12: Nvptx updates", but rather one aspect of the "gcc-12: Nvptx updates" themselves. ;-) On 2022-03-30T14:27:41+0200, Tom de Vries wrote: > +
  • The -march flag has been added. The -misa > + flag is now considered an alias of the -march flag. > +
  • Support for PTX ISA target architectures sm_53, > + sm_70, sm_75 and sm_80 has be= en > + added. These can be specified using the -march flag. > +
  • The default PTX ISA target architecture has been set back > + to sm_30, to fix support for sm_30 boards.=
    • > +
  • The -march-map flag has been added. The > + -march-map value will be mapped to an valid > + -march flag value. For instance, > + -march-map=3Dsm_50 maps to -march=3Dsm_35. > + This can be used to specify that generated code is to be executed on= a > + board with at least some specific compute capability, without having= to > + know the valid values for the -march flag.
    • Regarding the following: >
  • The -mptx flag has been added to specify the PTX ISA = version > for the generated code; permitted values are 3.1 > - (default, matches previous GCC versions) and 6.3. > + (matches previous GCC versions), 6.0, 6.3, > + and 7.0. If not specified, the used version is the mi= nimal > + version required for -march but at least 6.0. >
    • For "the PTX ISA version [used is] at least '6.0'", per , this means we now require "CUDA 9.0, driver r384" (or more recent). Per : "CUDA Toolkit 9.0 (Sept 2017)", so ~4.5 years old. Per , I'm guessing a similar timeframe for the imprecise "r384" Driver version stated in that table. That should all be fine (re not mandating use of all-too-recent versions). Now, consider doing a GCC/nvptx offloading build with '--with-cuda-driver' pointing to CUDA 9.0 (or more recent). This means that the libgomp nvptx plugin may now use CUDA Driver features of the CUDA 9.0 distribution ("driver r384", etc.) -- because that's what it is being 'configure'd and linked against. (I say "may now use", because we're currently not making a lot of effort to use "modern" CUDA Driver features -- but we could, and probably should. That's a separate discussion, of course.) It then follows that the libgomp nvptx plugin has a hard dependency on CUDA Driver features of the CUDA 9.0 distribution ("driver r384", etc.). That's dependency as in ABI: via '*.so' symbol versions as well as internal CUDA interface configuration; see doing different '#define's for different '__CUDA_API_VERSION' etc.) Now assume one such dependency on "modern" CUDA Driver were not implemented by: > +
  • An mptx-3.1 multilib was added. This allows using ol= der > + drivers which do not support PTX ISA version 6.0.
    • ... this "old" CUDA Driver. Then you do have the '-mptx-3.1' multilib to use with "old" CUDA Driver -- but you cannot actually use the libgomp nvptx plugin, because that's been built against "modern" CUDA Driver. Same problem, generally, for 'nvptx-run' of the nvptx-tools, which has similar CUDA Driver dependencies. Now, that may currently be a latent problem only, because we're not actually making use of "modern" CUDA Driver features. But, I'd like to resolve this "impedance mismatch", before we actually run into such problems. Already long ago Jakub put in changes to use '--without-cuda-driver' to "Allow building GCC with PTX offloading even without CUDA being installed (gcc and nvptx-tools patches)": "Especially for distributions it is undesirable to need to have proprietary CUDA libraries and headers installed when building GCC.", and I understand GNU/Linux distributions all use that. That configuration uses the GCC-provided 'libgomp/plugin/cuda/cuda.h', 'libgomp/plugin/cuda-lib.def' to manually define the CUDA Driver ABI to use, and then 'dlopen("libcuda.so.1")'. (Similar to what the libgomp GCN (and before: HSA) plugin is doing, for example.) Quite likely that our group (at work) are the only ones to actually use '--with-cuda-driver'? My proposal now is: we remove '--with-cuda-driver' (make its use a no-op, per standard GNU Autoconf behavior), and offer '--without-cuda-driver' only. This shouldn't cause any user-visible change in behavior, so safe without a prior deprecation phase. Before I prepare the patches (GCC, nvptx-tools): any comments or objections? Gr=C3=BC=C3=9Fe Thomas >
  • The new __PTX_SM__ predefined macro allows code to ch= eck the > - compute model being targeted by the compiler.
    • > + PTX ISA target architecture being targeted by the compiler. > +
  • The new __PTX_ISA_VERSION_MAJOR__ > + and __PTX_ISA_VERSION_MINOR__ predefined macros allow= s code > + to check the PTX ISA version being targeted by the compiler.
    • > ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstra=C3=9Fe 201= , 80634 M=C3=BCnchen; Gesellschaft mit beschr=C3=A4nkter Haftung; Gesch=C3= =A4ftsf=C3=BChrer: Thomas Heurung, Frank Th=C3=BCrauf; Sitz der Gesellschaf= t: M=C3=BCnchen; Registergericht M=C3=BCnchen, HRB 106955