From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id DFB6615852A for ; Sat, 17 Aug 2024 12:10:58 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5FB2DE2A6D; Sat, 17 Aug 2024 12:10:53 +0000 (UTC) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 2716BE2A69 for ; Sat, 17 Aug 2024 12:10:52 +0000 (UTC) Received: by mail-lj1-x22a.google.com with SMTP id 38308e7fff4ca-2ef2d96164aso34389611fa.3 for ; Sat, 17 Aug 2024 05:10:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723896651; x=1724501451; darn=lists.gentoo.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=vqxTo2MqRhIqj6An8JTgqXEDo9FFxPqijx97iho2ixE=; b=cqR7gNMOryRiSl8Rmc7cOk9ZicmKh7EX9/fmg+NKkjYy9oAFLbrCRWy1KItqTDy3lm rsGqXJVRivz4bB4ooRPwubg7a9xPu/CDhbil8KZCxoM3s8xu8Y6RR1bC9KV4hcVwVEwR 6KzD/0h9TOF+JQcOYA57LCf/5DJN3zGpiIFd9VY2eLdgiKHB430i83bRLnZip7GTsC73 2OUymOAiUqwaFzt2u7L6DbRvKr97ibQd4crKuy9VJTovcEIsK+2FRvK9HtJ7n0KTSG5x 2+Wm4BVHEKl9AJv4iAJ83k4mDqxAkwB45wjKRj6yp8ESLcQgpzLYnzwFKvRAEZxUvbft GCmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723896651; x=1724501451; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=vqxTo2MqRhIqj6An8JTgqXEDo9FFxPqijx97iho2ixE=; b=kYMfOWMM8JxJNn3Herq8N6qqaqGLf/iJBdP0+RoFhfo7RceDkYzkeFvEvrJfyl4UPx +SfECwsaz7PWbBhIy3VhCS9/JbUktGJwaUXrsSEUvSxK7Qbde3lN42hPnaPDV8Y+rj/r WwHEYoh3ZgyX0pUf9d+S+35gFHrsk6l4DM3WCUJMlOVk0r80BHYwiL/kMNNQVWo0RuzR yzs+TiSumOtH88zTwcknhw1+mGHxOhmWE/mU8Mxyv+/m0WbKVBL7GHkh796HkGfnQ2AY i++EhlmgGbSKq/X56WWzmcX1/xs7FAcQJ+AaLfs4jVQC29TtvYvmwmr2UBl6ibM2mwZZ 2fTQ== X-Gm-Message-State: AOJu0YxXlP1lOo+CHPY3Km1++IJkDhMIFIjCPOS/pVeE+CVH2wTO5j84 MC5ulli1vVgbtxXh8ytdFO6hWPDa1mnXwW+rEhTp8FXv9cApTtqVJw9FsW2aMKZ/mnA64k6Bqe6 pcZ0eSy/1dvP7WpjL7Kw9nT3cezMLcCultuA= X-Google-Smtp-Source: AGHT+IHDLkERv+eMYqUJ7NM8TCCvFX8GsQWHFXQh93l3utw0cYXXN9lioCBN+gsmTQOtG/VG6Nf+FMPdqf+ftOxosBE= X-Received: by 2002:a05:651c:1509:b0:2f3:aed8:aa9b with SMTP id 38308e7fff4ca-2f3be5758f4mr43673591fa.5.1723896650559; Sat, 17 Aug 2024 05:10:50 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 References: In-Reply-To: From: "Sv. Lockal" Date: Sat, 17 Aug 2024 20:10:39 +0800 Message-ID: Subject: [gentoo-dev] Re: [PATCH] rocm.eclass: add rocm_use_hipcc function and update example accordingly To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 191defce-7821-4fce-ad18-54230589982c X-Archives-Hash: 19faddd4f71f86a6b8080834473eb2a5 Following the discussion in https://github.com/gentoo/gentoo/pull/37639, rocm_use_hipcc now creates ROCM_TARGET_LST to prevent GPU access during src_configure phase. Interdiff is below: diff -u b/eclass/rocm.eclass b/eclass/rocm.eclass --- b/eclass/rocm.eclass +++ b/eclass/rocm.eclass @@ -20,7 +20,7 @@ # in /etc/portage/make.conf). Function check_amdgpu can help ebuild ensure # read and write permissions to GPU device in src_test phase, throwing fri= endly # error message if unavailable. However src_configure in general should no= t -# access any GPU devices. If it does, it usually means that CMakeLists.txt +# access any AMDGPU devices. If it does, it usually means that CMakeLists.= txt # ignores AMDGPU_TARGETS in favor of autodetected GPU, which is not desire= d. # # @EXAMPLE: @@ -239,8 +239,23 @@ # @FUNCTION: rocm_use_hipcc # @USAGE: rocm_use_hipcc # @DESCRIPTION: -# switch active C and C++ compilers to hipcc and clean unsupported flags. +# switch active C and C++ compilers to hipcc, clean unsupported flags and setup ROCM_TARGET_LST file. rocm_use_hipcc() { + # During the configuration stage, CMake tests whether the compiler is able to compile a simple program. + # Since CMake checker does not specify --offload-arch=3D, hipcc enumerates devices using four methods + # until it finds at least one device. Last way is by accessing them (via rocminfo). + # To prevent potential sandbox violations, we set the ROCM_TARGET_LST variable (which is checked first). + local target_lst=3D"${T}"/gentoo_rocm_target.lst + if [[ "${AMDGPU_TARGETS[@]}" =3D "" ]]; then + # Expected no GPU code; still need to calm down sandbox + echo "gfx000" > "${target_lst}" || die + else + printf "%s\n" ${AMDGPU_TARGETS[@]} > "${target_lst}" || die + fi + export ROCM_TARGET_LST=3D"${target_lst}" + + # Export updated CC and CXX. Note that CC is needed even if no C code used, + # as CMake checks that C compiler can compile a simple test program= . export CC=3Dhipcc CXX=3Dhipcc strip-unsupported-flags } On Sun, Aug 4, 2024 at 5:09=E2=80=AFAM Sv. Lockal wr= ote: > > This adds a new function rocm_use_hipcc in rocm.eclass to be used in > every src_configure, where the compiler is switched to hipcc (a. k. a. > clang with extra flags). > > Github pull request: https://github.com/gentoo/gentoo/pull/37639 > Bug: https://bugs.gentoo.org/936099 > Signed-off-by: Sv. Lockal > --- > eclass/rocm.eclass | 25 +++++++++++++++++++------ > 1 file changed, 19 insertions(+), 6 deletions(-) > > diff --git a/eclass/rocm.eclass b/eclass/rocm.eclass > index 7039455dec6b5..44ddf4fd09a87 100644 > --- a/eclass/rocm.eclass > +++ b/eclass/rocm.eclass > @@ -15,9 +15,13 @@ > # edit USE flag to control which GPU architecture to compile. Using > # ${ROCM_USEDEP} can ensure coherence among dependencies. Ebuilds can ca= ll the > # function get_amdgpu_flag to translate activated target to GPU compile = flags, > -# passing it to configuration. Function check_amdgpu can help ebuild ens= ure > +# passing it to configuration. Function rocm_use_hipcc switches active c= ompiler > +# to hipcc and cleans incompatible flags (useful for users with gcc-only= flags > +# in /etc/portage/make.conf). Function check_amdgpu can help ebuild ensu= re > # read and write permissions to GPU device in src_test phase, throwing f= riendly > -# error message if unavailable. > +# error message if unavailable. However src_configure in general should = not > +# access any GPU devices. If it does, it usually means that CMakeLists.t= xt > +# ignores AMDGPU_TARGETS in favor of autodetected GPU, which is not desi= red. > # > # @EXAMPLE: > # Example ebuild for ROCm library in https://github.com/ROCmSoftwarePlat= form > @@ -39,14 +43,12 @@ > # " > # > # src_configure() { > -# # avoid sandbox violation > -# addpredict /dev/kfd > -# addpredict /dev/dri/ > +# rocm_use_hipcc > # local mycmakeargs=3D( > # -DAMDGPU_TARGETS=3D"$(get_amdgpu_flags)" > # -DBUILD_CLIENTS_TESTS=3D$(usex test ON OFF) > # ) > -# CXX=3Dhipcc cmake_src_configure > +# cmake_src_configure > # } > # > # src_test() { > @@ -90,6 +92,8 @@ esac > if [[ ! ${_ROCM_ECLASS} ]]; then > _ROCM_ECLASS=3D1 > > +inherit flag-o-matic > + > # @ECLASS_VARIABLE: ROCM_VERSION > # @REQUIRED > # @PRE_INHERIT > @@ -231,3 +235,12 @@ check_amdgpu() { > } > > fi > + > +# @FUNCTION: rocm_use_hipcc > +# @USAGE: rocm_use_hipcc > +# @DESCRIPTION: > +# switch active C and C++ compilers to hipcc and clean unsupported flags= . > +rocm_use_hipcc() { > + export CC=3Dhipcc CXX=3Dhipcc > + strip-unsupported-flags > +}