From nobody Tue Feb 6 00:29:50 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TTPKg5q4Vz59MW9 for ; Tue, 6 Feb 2024 00:30:31 +0000 (UTC) (envelope-from estrabd@gmail.com) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TTPKg448Lz4Cc9; Tue, 6 Feb 2024 00:30:31 +0000 (UTC) (envelope-from estrabd@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-x133.google.com with SMTP id 2adb3069b0e04-5114cd44fdbso3340215e87.2; Mon, 05 Feb 2024 16:30:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707179428; x=1707784228; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Z0qM6lb7rOoAcv0gky20M5M+WkkbzWQnfUmflR98ETo=; b=NTuG1Icj5hTRLG06AfKr25TL9XtTJ43Rj+VblVXt49Xec61YXn+tipIwAotWcAP7Pg S6RpnlaWsS2SXxQ7aerbH8GcPqAxTgA+u5c6KP6L8pvZ+HEUWLvKI18EdPe0ZyBRsooe KGaqGUukIrJyOMPQ+bBqdVDPLp2iMj9dkgh25CyRsx13PT5rrWyve81gFIxryW44Llhg wS8agKB1fCCLZSSAREhp/Gviv8g8bLRzVCiWtfEXu5qWpKc6QPTRFFDh4ipT90CDorB3 oh2JPn99G350snRNXKOamUtFakDNHB8Fo327UIX2L71A7UAnj/EdZnWf9qn6L9blujJ1 T5pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707179428; x=1707784228; h=cc: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=Z0qM6lb7rOoAcv0gky20M5M+WkkbzWQnfUmflR98ETo=; b=itdn/lx6NrQrcM8tcXZldqla3dqQrkmAplCb9GU8Af0SiIaqWTfJ+LNbu9yLHx0FpY +4AoQHyae6JYbmZoX78LsaBoYbFN0Ukw6XaFmZ3EgHIJcmZBDrCj6SYyIgn7oGopjwp2 12PBY2dIgXQouoX8gO1Vd2wkhOQflRS6ytkFZ8KjDvI8kX1nJD/aKunBW7JzeK+egigY TcHgJV+IsX+kYGIvdlh8QjZrF/5bqe1QVJucMN+PN2K3FggqVq0FARvbUV5sf8BEf70V ayLKV1rrkyYCdYXxkIqtnFTK+38bo7wNOucnLY39RWyC2gIMc6m2Q9IJOOjpSpSzQVGr RC+Q== X-Gm-Message-State: AOJu0YxYYqwyA+AVAkqfrqPpbhXNpcheWkA7RcClhNsJRozJhpdhdGE4 QVWuM1z4ufnFqsIyrV14kxLBi9/nvAGxVBXpwwTx5kUKYg5nK5KkvO1RTb6k3rjQ1EHwYtWrMu/ 7DRJJMW5lpR8l3lSOVqfrX1Rkl3ZQn2HK X-Google-Smtp-Source: AGHT+IGPW7kPfxx+SA3PwbfI9aRNftB9Z2V8gRARlhZ7wBhagwbUX5fMDWLXBPH8FLdr06AupIX0ITKeaAyxdlHkIQs= X-Received: by 2002:ac2:547a:0:b0:511:4808:c714 with SMTP id e26-20020ac2547a000000b005114808c714mr765395lfn.61.1707179427494; Mon, 05 Feb 2024 16:30:27 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <90ea0dd91b760b0b6f92065d09396545@Leidinger.net> In-Reply-To: From: "B. E." Date: Mon, 5 Feb 2024 18:29:50 -0600 Message-ID: Subject: Re: GPU programming? To: sgk@troutmask.apl.washington.edu Cc: Jan Beich , Alexander Leidinger , freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="00000000000057ff800610abafce" X-Rspamd-Queue-Id: 4TTPKg448Lz4Cc9 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] --00000000000057ff800610abafce Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Not surprising since most academic HPCs and HPC-enabled clouds (Oracle, Azure) are generally running some version of RHEL. The former is where the largest GPU resources are available to most folks (e.g., TACC), as I am sure you already know. OTOH, someone doing with FreeBSD is likely just wanting it for a workstation or some single node, many-core server they picked up cheap off of eBay or an e-cycler; (basically me, but I focus on OpenMP and standard CPU SMP). If you're doing AI related things, then a lot of sites are starting to spring up that sell GPU heavy single box builds, but those are also assuming some kind of Linux. Brett On Mon, Feb 5, 2024 at 11:10=E2=80=AFAM Steve Kargl < sgk@troutmask.apl.washington.edu> wrote: > On Mon, Feb 05, 2024 at 12:17:57PM +0100, Jan Beich wrote: > > Alexander Leidinger writes: > > > > > ROCm: No idea. I have not seen any report about it working or even > > > being tried. But there was at least some discussion about it: > > > https://github.com/ROCm/ROCm/issues/138 > > > https://github.com/ROCm/ROCm/issues/1913 > > > > AFAIU (never owned an AMD GPU): > > - ROCm requires amdkfd.ko which drm-kmod doesn't provide since > > https://github.com/freebsd/drm-kmod/commit/a381f46adf8b > > - ROCm has poor *consumer* GPU support thus unattractive for > > volunteers/community to spend time porting > > > > > Intel: Maybe. We have spirv ports in the tree, and my limited > > > understanding is, that SPIR-V comes into play when someone wants to d= o > > > GPU compute there. CCing Jan as the port maintainer for the two spirv > > > ports. Maybe he can shed some light on this part. > > > > - Vulkan Compute works fine on every modern GPU (used at least by ncnn) > > - OpenCL works fine on Intel + AMD via Rusticl (Mesa), see > > https://cgit.freebsd.org/ports/commit/?id=3Dd8990eff958b > > - OpenCL + oneAPI Level Zero via lang/intel-compute-runtime requires > userptr, see > > https://github.com/FreeBSDDesktop/kms-drm/issues/197 > > > > As a volunteer I've burned out porting Intel stuff, so hopefully Rustic= l > > kills Intel NEO (intel-compute-runtime) while Vulkan Video kills VA-API > > (libva-intel-media-driver) and QuickSyncVideo (intel-media-sdk + onevpl= ) > > > > Related https://www.phoronix.com/news/David-Airlie-oneAPI-Meetup > > Alexander, Jan, > > Thanks for the info. I'll check out the various links. > This somewhat confirms my suspicion that little is being > done with scientific numerical GPU computing in the FreeBSD. > > -- > Steve > > --00000000000057ff800610abafce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Not surprising since most academic HPCs and HPC-enabled cl= ouds (Oracle, Azure) are generally running some version of RHEL. The former= is where the largest GPU resources are available to most folks (e.g., TACC= ), as I am sure you already know. OTOH, someone doing with FreeBSD is likel= y just wanting it for a workstation or some single node, many-core server t= hey picked up cheap off of eBay or an e-cycler; (basically me, but I focus = on OpenMP and standard CPU SMP). If you're doing AI related things, the= n a lot of sites are starting to spring up that sell GPU heavy single box b= uilds, but those are also assuming some kind of Linux.

B= rett

On Mon, Feb 5, 2024 at 11:10=E2=80=AFAM Steve Kargl <sgk@troutmas= k.apl.washington.edu> wrote:
On Mon, Feb 05, 2024 at 12:17:57PM +0100, Jan Beich wro= te:
> Alexander Leidinger <Alexander@Leidinger.net> writes:
>
> > ROCm: No idea. I have not seen any report about it working or eve= n
> > being tried. But there was at least some discussion about it:
> >=C2=A0 =C2=A0 =C2=A0https://github.com/ROCm/ROCm/iss= ues/138
> >=C2=A0 =C2=A0 =C2=A0https://github.com/ROCm/ROCm/is= sues/1913
>
> AFAIU (never owned an AMD GPU):
> - ROCm requires amdkfd.ko which drm-kmod doesn't provide since
>=C2=A0 =C2=A0https://github.com/freebsd/d= rm-kmod/commit/a381f46adf8b
> - ROCm has poor *consumer* GPU support thus unattractive for
>=C2=A0 =C2=A0volunteers/community to spend time porting
>
> > Intel: Maybe. We have spirv ports in the tree, and my limited
> > understanding is, that SPIR-V comes into play when someone wants = to do
> > GPU compute there. CCing Jan as the port maintainer for the two s= pirv
> > ports. Maybe he can shed some light on this part.
>
> - Vulkan Compute works fine on every modern GPU (used at least by ncnn= )
> - OpenCL works fine on Intel + AMD via Rusticl (Mesa), see
>=C2=A0 =C2=A0https://cgit.freebsd.org/po= rts/commit/?id=3Dd8990eff958b
> - OpenCL + oneAPI Level Zero via lang/intel-compute-runtime requires u= serptr, see
>=C2=A0 =C2=A0https://github.com/FreeBSDDeskt= op/kms-drm/issues/197
>
> As a volunteer I've burned out porting Intel stuff, so hopefully R= usticl
> kills Intel NEO (intel-compute-runtime) while Vulkan Video kills VA-AP= I
> (libva-intel-media-driver) and QuickSyncVideo (intel-media-sdk + onevp= l)
>
> Related https://www.phoronix.com/news/D= avid-Airlie-oneAPI-Meetup

Alexander, Jan,

Thanks for the info.=C2=A0 I'll check out the various links.
This somewhat confirms my suspicion that little is being
done with scientific numerical GPU computing in the FreeBSD.

--
Steve

--00000000000057ff800610abafce--