From nobody Mon Feb 24 14:44:24 2025 X-Original-To: freebsd-arm@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 4Z1k5w1Thxz5pGDT for ; Mon, 24 Feb 2025 14:44:36 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Z1k5w0CjTz3DxP; Mon, 24 Feb 2025 14:44:36 +0000 (UTC) (envelope-from eduardo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1740408276; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=shjrYcEXPVj2iqKkzNtMS/8heWMnQphPu8zlJoWQWHk=; b=GjFwC8Qnmv440Z1mmCXBEO/L8oMaoLNy4YmWWeTqADntg/C4wE3jNaTyCpEhiee9F7YIjx tfzcLOozfFzSzkuu0gvIyGm3L0Pgsvzdxk2lLIDjXTOo9to2uQ3XDozwVHbFseBoZCVHcF 8/orlMw/b4WuNIdBBaXQLvMQL46Rm6Ia3yJ6jsW/s6+6Z7hUW0XKMpIom0dBgwCJP5pisx M7AQpO0EK24A/CbDlr7vaDcmgezhVho1H0c+t4tA56sNYnFbzHi0BMEPLbUvkT4DY357hS mnvpoUsPBsV5KRlVY7LLw3tSbZbjm3U1QiZVnnVFdQEeMxDJzlnBxpGlH6I0sw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1740408276; a=rsa-sha256; cv=none; b=aouaiSTrL5g6ShMWrV2F7glG5UYTEmdvds1qTkiwBKw4MtMZoFEpOTEeTH5U+ZT4DqiAZU gs/ouGY3Tr9YATr0GE8SxDEDZpGn7AapIqiy3Yw8sdCzebUnSHPEFqgU4hXLCsJSlONTnF Yqq+UBtErHCNoGIGSqYie2RHKXWfc5lcR9eSmRjZbORXcIzcsSMeBV3D9E0fBnTEc/eoU9 6K6d1jb6KOJZWINI0PrghEFPdhK0LHyDWnjzSO7AH/SvSCIAaI01bUhZbgzKC6cyK+FsKd H7SZeVpkxANfOVwOSh7vAXz0WVUhwblPLRA58PELhuj0AsYTW6aNIq3KZKidIw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1740408276; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=shjrYcEXPVj2iqKkzNtMS/8heWMnQphPu8zlJoWQWHk=; b=gJJ44+2IEU8F7tKpgVgge2Vc9aKBJuYChx7CdCx/g6d7Fw66Jk0P1DKG0gsS0gMnoNdZL6 4zxpwS8URf9wZXZehTdNZDoGYp5diR7TqdQMB77Bpzb+YfsrBfRz2/CObMLgQmk4kp+l0J rQxoCRZpjbPdZHfzGzoLvgaBGXqSJhk2d90+0lNTaU/iJS3avzii9hjpJRdIV817Z7if5O mwHOceTDZa6Y4aMChqD2XcsKRMqIM2aZvXxa1DfUVLsYUptAkayFYv4I95qA6PG1yH9ZVZ Czq1ExTiW56HxIpOgRuQAeff3snjK6fAOgyiWKL5mqrwiPpdbvwMVnNvQnjrSQ== Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com [209.85.160.172]) (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 "WR4" (verified OK)) (Authenticated sender: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Z1k5v61vNznwM; Mon, 24 Feb 2025 14:44:35 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-qt1-f172.google.com with SMTP id d75a77b69052e-4702181a59aso3537091cf.0; Mon, 24 Feb 2025 06:44:35 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCXgPktTN+pBfDd12r62gvgQf0HQN5SIOTgW2InCOEKWmQ1HqCWDSYm+HGCaUPHJQWmazosBY6MDsKQ3hg==@freebsd.org X-Gm-Message-State: AOJu0YzxwoxWPYsWyg1wDiXwBrtiwAp+Ep0bs0TGmAc3zkYY38PIDU3h wQHyMZVVGZi0n/U60kHU8VYpXAWq9EBeL6mhtIDJH7cc4RhgffYGC/SRmhJL0Y6Mg0IFi6t5sZt rBQmt8i0U9VYsgrJLwhuE4+9J0vo= X-Google-Smtp-Source: AGHT+IH7keV0WBphHayczgrgfBEz80jNqeD8rqWYWG2KmFlpDvbsnH3KAvaPjxRcMelmr4ddR9VlKmkUG12EL97hTY4= X-Received: by 2002:ac8:5786:0:b0:472:7e8:a773 with SMTP id d75a77b69052e-472228ab2abmr72717311cf.1.1740408275338; Mon, 24 Feb 2025 06:44:35 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@FreeBSD.org MIME-Version: 1.0 References: <41144AE6-2C81-4762-84C7-57CEB81F448C@yahoo.com> <43C70901-A871-4044-9353-89A82DB2F2E6@yahoo.com> <722e1fd5-f969-4856-b8af-84046ddd896a@freebsd.org> <5B72C2FD-1C24-4B81-B6CB-F6993ED136B5@yahoo.com> <3377C812-42B3-41CA-A07D-3153E3FAB2DB@yahoo.com> In-Reply-To: <3377C812-42B3-41CA-A07D-3153E3FAB2DB@yahoo.com> From: Nuno Teixeira Date: Mon, 24 Feb 2025 14:44:24 +0000 X-Gmail-Original-Message-ID: X-Gm-Features: AWEUYZnduFQ-pvfMFB5hY0Ma07BUYYr9HBS0Cx0Nbn6N7YzEXWhQb8wUQDk2AwY Message-ID: Subject: Re: Avoiding llvm from ports on rpi4 To: Mark Millard Cc: Charlie Li , FreeBSD ARM List Content-Type: multipart/alternative; boundary="0000000000000419cf062ee461f6" --0000000000000419cf062ee461f6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello all, Well this was a good exercise of better understanding about clang and llvm. As I understand better how things works now, thats make not much sense to hack mesa-{dri,libs} at least for my use case of x11/i3/firefox test. I will try other ways of dealing with port llvm to reduce build time by removing options not needed for my use case. Build pkgs on a second system with more resources makes all sense too. Thanks all and sorry for the noise :) Cheers, Mark Millard escreveu (segunda, 24/02/2025 =C3=A0(s) 04= :08): > On Feb 23, 2025, at 17:51, Nuno Teixeira wrote: > > > Hello, > > > > OPTIONS ZSTD+X11+WAYLAND ON and rest *OFF* > > > > =3D=3D> Original port (llvm) > > > > [1] ZSTD+X11+WAYLAND > > meson.build:456:3: ERROR: Feature egl cannot be enabled: EGL requires > DRI, Haiku, Windows or Android > > > > **[2] ZSTD+X11+WAYLAND+swrast > > OK > > > > [3] ZSTD+X11+WAYLAND+swrast_vk > > meson.build:328:2: ERROR: Problem encountered: swrast vulkan requires > gallium swrast > > > > [4] ZSTD+X11+WAYLAND+swrast +swrast_vk > > OK (same performance as [2]) > > swrast is for OpenGL programs using the OpenGL API. > swrast_vk is for Vulkan programs using the Vulkan API. > > Having both might mean ending up with support for > both types of programs (at least at this level). > > I'll note that replacing swrast and/ior swrast_vk > with the modern LLVMpipe puts LLVM back into the > build requirements for this level of material. > > > =3D=3D> Port patched (no llvm): > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238906#c24 > > > > graphics/mesa-dri/Makefile > > -USES+=3D llvm:lib,noexport > > > > graphics/mesa-dri/Makefile.common > > -MESON_ARGS+=3D -Dllvm=3Denabled \ > > +MESON_ARGS+=3D -Dllvm=3Ddisabled \ > > > > mesa-libs/Makefile > > -USES=3D llvm:noexport > > > > **[2] ZSTD+X11+WAYLAND+swrast > > OK > > > > main-n275605-dbbcbaae1d7b arm64 (rpi4): > > > > > https://people.freebsd.org/~eduardo/logs/mesa-nollvm/mesa-dri-24.1.7_4.lo= g > > > https://people.freebsd.org/~eduardo/logs/mesa-nollvm/mesa-libs-24.1.7_1.l= og > > > > ** The minimum software accel for a working graphics > > ------- > > > > Next test will be build firefox with base compiler to achieve > x11+i3+firefox collection without ports llvm. > > That means needing to have rust built and in use during the build. > Having rust involves having LLVM as rust uses LLVM infrastructure. > rust's port has an option for if rust uses an internel LLVM vs. > if it uses a LLVM package. rust can be very picky about which > vintage of LLVM is needed. > > If you are trying to build a somewhat normal desktop environment > based on any of the major desktop software variants, then you are > unlikely to avoid much to get it all in place. You could avoid > support for targeting other CPU/core families. You likely can > avoid support for targetting BE_AMDGPU. But, for > firefox/thunderbird, you need WASI (and the packages that put > WASI to use) and you need clang/clang++ (so: a substantial LLVM > package overall), and you need rust (that you might be able to > resuse the LLVM for instead of building a rust-internal one as > well). > > The (un?)reasonableness of your activity is very dependent on > what your overall goals require. Referencing the likes of > firefox needing to be involved likely suggests painful time > frames for using a RPi4 as the builder machine. Even more so > if keeping up with security updates is part of the requirements. > > May be having 2 systems, with one being the builder that can be > building while the other system uses the prior build materials? > > > Thanks, > > > > Mark Millard escreveu (domingo, 23/02/2025 =C3=A0(s= ) > 03:04): > > On Feb 22, 2025, at 17:12, Charlie Li wrote: > > > > > Mark Millard wrote: > > >> On Feb 22, 2025, at 11:08, Nuno Teixeira wrote= : > > >>> Good point! I forgot to check options on port that are suitable for > an rpi4! > > >>> I was straight to hacking stuff :) > > >>> > > >>> As I don't know if any graphics acceleration is working on rpi4, I'= m > building with: > > >>> > > >>> _OPTIONS_READ=3Dmesa-dri-24.1.7_4 > > >>> _FILE_COMPLETE_OPTIONS_LIST=3DZSTD panfrost r300 r600 radeonsi swra= st > zink X11 WAYLAND radv swrast_vk > > >>> OPTIONS_FILE_SET+=3DZSTD > > >>> OPTIONS_FILE_UNSET+=3Dpanfrost > > >>> OPTIONS_FILE_UNSET+=3Dr300 > > >>> OPTIONS_FILE_UNSET+=3Dr600 > > >>> OPTIONS_FILE_UNSET+=3Dradeonsi > > >>> OPTIONS_FILE_UNSET+=3Dswrast > > >>> OPTIONS_FILE_UNSET+=3Dzink > > >>> OPTIONS_FILE_SET+=3DX11 > > >>> OPTIONS_FILE_SET+=3DWAYLAND > > >>> OPTIONS_FILE_UNSET+=3Dradv > > >>> OPTIONS_FILE_UNSET+=3Dswrast_vk > > >>> > > >>> While I'm really don't sure is panfrost os working or not... > > >> Warning that I'm not literate in the subject area overall. > > >> You have panfrost UNSET . You only have ZSTD, X11, and > > >> WAYLAND SET. > > >> It does not look to me like any of the lowercase names > > >> apply to the RPi4's VideoCore VI hardware from Broadcom. > > >> If true, then the UNSET's would seem to be right for > > >> what is listed above. (Unsure for swrast and swrast_vk > > >> which seem to be software-rasterization instead of > > >> hardward tied. Also, zink is "OpenGL on top of Khronos=E2=80=99 > > >> Vulkan API" instead of being hardware.) > > > swrast has been deprecated for over four years now, despite the code > still existing in the current mesa source tree. Those options should have > been removed from the port already. LLVMpipe and softpipe are the > recommended software rasteriser drivers, in that order. > > > > I do not see a LLVMpipe option in any mesa-dri/Makefile* . May be the > > swrast is there because the port does not yet support LLVMpipe and > > removal of swrast would eliminate the category completely? > > > > >> https://docs.mesa3d.org/drivers/panfrost.html does not > > >> indicate VideoCore VI hardware from Broadcom as a > > >> "Model". So I expect that it does not apply to a > > >> VideoCore VI context. > > > Correct, panfrost has nothing to do with VideoCore. > > >>> I will see if I get working graphics this way and check if llvm dep > is gone. > > >> So you are only intending to build: ZSTD, X11, WAYLAND ? > > >> (But I do not see how that gets into potential acceleration > > >> specific to the RPi4 VideoCore VI hardware from Broadcom. > > >> So I'm confused relative to the wording.) > > >> It does seem that the hardware names I recognize are UNSET > > >> and do not seem likely to be involved with VideoCore VI > > >> hardware. I'm assuming the video context is the native RPi4 > > >> context, and not any somehow added alternative video > > >> hardware. > > > For all VideoCore (Raspberry Pi) you need the VC4 mesa driver. For > Raspberry Pi >=3D 4 you also need the V3D mesa driver. > > > > The mesa-dri port does not seem to have these as options > > (yet?), per also the notes below. > > > > > The mesa drivers communicate directly with the Linux kernel > counterparts, which we currently do not expose in, or even support > building, drm-kmod for aarch64. Additional port options to expose buildin= g > these mesa drivers do not make sense until the kernel bits are ported. > > > > > > > It seems that Nuno's attempt to avoid large build times > > for lack of any notable benefit is reasonable for the > > current status of things for the RPi4 (and related), even > > if swrast ends up involved in order to do that. > > > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > > --=20 Nuno Teixeira FreeBSD UNIX: Web: https://FreeBSD.org --0000000000000419cf062ee461f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all,

Well this was a g= ood exercise of better understanding about clang and llvm.
As I u= nderstand better how things works now, thats make not much sense to hack
mesa-{dri,libs} at least for my use case of x11/i3/firefox test.

I will try other ways of dealing with port llvm to r= educe build time by removing
options not needed for my use case.<= br>
Build pkgs on a second system with more resources makes a= ll sense too.

Thanks all and sorry for the noise :)
=

Cheers,

Mark Millard <marklmi@yahoo.com> escreveu (segun= da, 24/02/2025 =C3=A0(s) 04:08):
On Feb 23, 2025, at 17:51, Nuno Teixeira <eduardo@freebsd.org> wro= te:

> Hello,
>
> OPTIONS ZSTD+X11+WAYLAND ON and rest *OFF*
>
> =3D=3D> Original port (llvm)
>
> [1] ZSTD+X11+WAYLAND
> meson.build:456:3: ERROR: Feature egl cannot be enabled: EGL requires = DRI, Haiku, Windows or Android
>
> **[2] ZSTD+X11+WAYLAND+swrast
> OK
>
> [3] ZSTD+X11+WAYLAND+swrast_vk
> meson.build:328:2: ERROR: Problem encountered: swrast vulkan requires = gallium swrast
>
> [4] ZSTD+X11+WAYLAND+swrast +swrast_vk
> OK (same performance as [2])

swrast is for OpenGL programs using the OpenGL API.
swrast_vk is for Vulkan programs using the Vulkan API.

Having both might mean ending up with support for
both types of programs (at least at this level).

I'll note that replacing swrast and/ior swrast_vk
with the modern LLVMpipe puts LLVM back into the
build requirements for this level of material.

> =3D=3D> Port patched (no llvm): https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238906#c24
>
> graphics/mesa-dri/Makefile
> -USES+=3D=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0llvm:lib,noexport
>
> graphics/mesa-dri/Makefile.common
> -MESON_ARGS+=3D=C2=A0 =C2=A0-Dllvm=3Denabled \
> +MESON_ARGS+=3D=C2=A0 =C2=A0-Dllvm=3Ddisabled \
>
> mesa-libs/Makefile
> -USES=3D=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 llvm:noexport
>
> **[2] ZSTD+X11+WAYLAND+swrast
> OK
>
> main-n275605-dbbcbaae1d7b arm64 (rpi4):
>
> https://people.freebs= d.org/~eduardo/logs/mesa-nollvm/mesa-dri-24.1.7_4.log
> https://people.freeb= sd.org/~eduardo/logs/mesa-nollvm/mesa-libs-24.1.7_1.log
>
> ** The minimum software accel for a working graphics
> -------
>
> Next test will be build firefox with base compiler to achieve x11+i3+f= irefox collection without ports llvm.

That means needing to have rust built and in use during the build.
Having rust involves having LLVM as rust uses LLVM infrastructure.
rust's port has an option for if rust uses an internel LLVM vs.
if it uses a LLVM package. rust can be very picky about which
vintage of LLVM is needed.

If you are trying to build a somewhat normal desktop environment
based on any of the major desktop software variants, then you are
unlikely to avoid much to get it all in place. You could avoid
support for targeting other CPU/core families. You likely can
avoid support for targetting BE_AMDGPU. But, for
firefox/thunderbird, you need WASI (and the packages that put
WASI to use) and you need clang/clang++ (so: a substantial LLVM
package overall), and you need rust (that you might be able to
resuse the LLVM for instead of building a rust-internal one as
well).

The (un?)reasonableness of your activity is very dependent on
what your overall goals require. Referencing the likes of
firefox needing to be involved likely suggests painful time
frames for using a RPi4 as the builder machine. Even more so
if keeping up with security updates is part of the requirements.

May be having 2 systems, with one being the builder that can be
building while the other system uses the prior build materials?

> Thanks,
>
> Mark Millard <marklmi@yahoo.com> escreveu (domingo, 23/02/2025 =C3=A0(s) 03:04):=
> On Feb 22, 2025, at 17:12, Charlie Li <vishwin@freebsd.org> wrote:
>
> > Mark Millard wrote:
> >> On Feb 22, 2025, at 11:08, Nuno Teixeira <eduardo@freebsd.org> wrote:=
> >>> Good point! I forgot to check options on port that are su= itable for an rpi4!
> >>> I was straight to hacking stuff :)
> >>>
> >>> As I don't know if any graphics acceleration is worki= ng on rpi4, I'm building with:
> >>>
> >>> _OPTIONS_READ=3Dmesa-dri-24.1.7_4
> >>> _FILE_COMPLETE_OPTIONS_LIST=3DZSTD panfrost r300 r600 rad= eonsi swrast zink X11 WAYLAND radv swrast_vk
> >>> OPTIONS_FILE_SET+=3DZSTD
> >>> OPTIONS_FILE_UNSET+=3Dpanfrost
> >>> OPTIONS_FILE_UNSET+=3Dr300
> >>> OPTIONS_FILE_UNSET+=3Dr600
> >>> OPTIONS_FILE_UNSET+=3Dradeonsi
> >>> OPTIONS_FILE_UNSET+=3Dswrast
> >>> OPTIONS_FILE_UNSET+=3Dzink
> >>> OPTIONS_FILE_SET+=3DX11
> >>> OPTIONS_FILE_SET+=3DWAYLAND
> >>> OPTIONS_FILE_UNSET+=3Dradv
> >>> OPTIONS_FILE_UNSET+=3Dswrast_vk
> >>>
> >>> While I'm really don't sure is panfrost os workin= g or not...
> >> Warning that I'm not literate in the subject area overall= .
> >> You have panfrost UNSET . You only have ZSTD, X11, and
> >> WAYLAND SET.
> >> It does not look to me like any of the lowercase names
> >> apply to the RPi4's VideoCore VI hardware from Broadcom.<= br> > >> If true, then the UNSET's would seem to be right for
> >> what is listed above. (Unsure for swrast and swrast_vk
> >> which seem to be software-rasterization instead of
> >> hardward tied. Also, zink is "OpenGL on top of Khronos= =E2=80=99
> >> Vulkan API" instead of being hardware.)
> > swrast has been deprecated for over four years now, despite the c= ode still existing in the current mesa source tree. Those options should ha= ve been removed from the port already. LLVMpipe and softpipe are the recomm= ended software rasteriser drivers, in that order.
>
> I do not see a LLVMpipe option in any mesa-dri/Makefile* . May be the<= br> > swrast is there because the port does not yet support LLVMpipe and
> removal of swrast would eliminate the category completely?
>
> >> https://docs.mesa3d.org/drivers/panfrost.= html does not
> >> indicate VideoCore VI hardware from Broadcom as a
> >> "Model". So I expect that it does not apply to a > >> VideoCore VI context.
> > Correct, panfrost has nothing to do with VideoCore.
> >>> I will see if I get working graphics this way and check i= f llvm dep is gone.
> >> So you are only intending to build: ZSTD, X11, WAYLAND ?
> >> (But I do not see how that gets into potential acceleration > >> specific to the RPi4 VideoCore VI hardware from Broadcom.
> >> So I'm confused relative to the wording.)
> >> It does seem that the hardware names I recognize are UNSET > >> and do not seem likely to be involved with VideoCore VI
> >> hardware. I'm assuming the video context is the native RP= i4
> >> context, and not any somehow added alternative video
> >> hardware.
> > For all VideoCore (Raspberry Pi) you need the VC4 mesa driver. Fo= r Raspberry Pi >=3D 4 you also need the V3D mesa driver.
>
> The mesa-dri port does not seem to have these as options
> (yet?), per also the notes below.
>
> > The mesa drivers communicate directly with the Linux kernel count= erparts, which we currently do not expose in, or even support building, drm= -kmod for aarch64. Additional port options to expose building these mesa dr= ivers do not make sense until the kernel bits are ported.
> >
>
> It seems that Nuno's attempt to avoid large build times
> for lack of any notable benefit is reasonable for the
> current status of things for the RPi4 (and related), even
> if swrast ends up involved in order to do that.



=3D=3D=3D
Mark Millard
marklmi at yahoo.com



--
Nuno Teixeira
=
FreeBSD UNIX:=C2=A0 <eduardo@FreeBSD.org>=C2=A0 =C2=A0Web:=C2=A0 https://Fr= eeBSD.org
--0000000000000419cf062ee461f6--