From: Michael Olbrich <m.olbrich@pengutronix.de>
To: Christian Melki <christian.melki@t2data.com>
Cc: ptxdist@pengutronix.de
Subject: Re: [ptxdist] mesalib 2021.11 broken kmsro driver?
Date: Tue, 9 Nov 2021 16:42:06 +0100 [thread overview]
Message-ID: <20211109154206.GO22301@pengutronix.de> (raw)
In-Reply-To: <25725d78-9185-200e-c116-dda70751a16f@t2data.com>
On Mon, Nov 08, 2021 at 03:28:39PM +0100, Christian Melki wrote:
> On 11/8/21 15:08, Lucas Stach wrote:
> > Am Montag, dem 08.11.2021 um 14:37 +0100 schrieb Christian Melki:
> >> On 11/8/21 14:03, Michael Olbrich wrote:
> >>> Hi,
> >>>
> >>> On Mon, Nov 08, 2021 at 11:16:11AM +0100, Christian Melki wrote:
> >>>> The kmsro driver doesn't seem to create any .so files.
> >>>> According to people on #dri-devel it's builtin in other .so files?
> >>>> So the idea of kmsro library names to copy will fail in the current .make.
> >>>
> >>> What exactly is broken?
> >>
> >> ptxdist: error: missing gallium driver armada-drm_dri.so
> >>
> >>> In general, all gallium drivers are built into a
> >>> single file. 'make install' creates hardlinks for all drivers that are
> >>> built. In ptxdist we just create one gallium_dri.so and symlinks for all
> >>> drivers.
> >>> The 'kmsro' argument for the meson 'gallium-drivers' options just means,
> >>> build all KMS only drivers. So the list of hardlinks/softlinks ist
> >>> different. That's why we have the '$(subst kmsro, ....'.
> >>
> >> kmsro doesn't create any library hardlinks named according to whatever
> >> list ptxdist has. Actually, adding kmsro doesn't change built number of
> >> objects or generated library hardlinks at all.
> >>
> >> with kmsro:
> >> Gallium drivers: kmsro virgl r600 nouveau swrast svga
> >>
> >> [1621/1621] Linking target src/mesa/drivers/dri/libmesa_dri_drivers.so
> >>
> >> $ ls -1gG platform-secplatform/packages/mesa-21.2.3/usr/lib/dri/*
> >> -rwxr-xr-x 2 94331520 nov 8 14:25
> >> platform-secplatform/packages/mesa-21.2.3/usr/lib/dri/i965_dri.so
> >> -rwxr-xr-x 12 127009440 nov 8 14:25
> >> platform-secplatform/packages/mesa-21.2.3/usr/lib/dri/kms_swrast_dri.so
> >> -rwxr-xr-x 12 127009440 nov 8 14:25
> >> platform-secplatform/packages/mesa-21.2.3/usr/lib/dri/nouveau_dri.so
> >> -rwxr-xr-x 12 127009440 nov 8 14:25
> >> platform-secplatform/packages/mesa-21.2.3/usr/lib/dri/r600_dri.so
> >> -rwxr-xr-x 12 127009440 nov 8 14:25
> >> platform-secplatform/packages/mesa-21.2.3/usr/lib/dri/swrast_dri.so
> >> -rwxr-xr-x 12 127009440 nov 8 14:25
> >> platform-secplatform/packages/mesa-21.2.3/usr/lib/dri/virtio_gpu_dri.so
> >> -rwxr-xr-x 12 127009440 nov 8 14:25
> >> platform-secplatform/packages/mesa-21.2.3/usr/lib/dri/vmwgfx_dri.so
> >>
> >>
> >> without kmsro:
> >> Gallium drivers: virgl r600 nouveau swrast svga
> >>
> >> [1621/1621] Linking target src/mesa/drivers/dri/libmesa_dri_drivers.so
> >> $ ls -1gG platform-secplatform/packages/mesa-21.2.3/usr/lib/dri/*
> >> -rwxr-xr-x 2 94331520 nov 8 14:34
> >> platform-secplatform/packages/mesa-21.2.3/usr/lib/dri/i965_dri.so
> >> -rwxr-xr-x 12 127009440 nov 8 14:34
> >> platform-secplatform/packages/mesa-21.2.3/usr/lib/dri/kms_swrast_dri.so
> >> -rwxr-xr-x 12 127009440 nov 8 14:34
> >> platform-secplatform/packages/mesa-21.2.3/usr/lib/dri/nouveau_dri.so
> >> -rwxr-xr-x 12 127009440 nov 8 14:34
> >> platform-secplatform/packages/mesa-21.2.3/usr/lib/dri/r600_dri.so
> >> -rwxr-xr-x 12 127009440 nov 8 14:34
> >> platform-secplatform/packages/mesa-21.2.3/usr/lib/dri/swrast_dri.so
> >> -rwxr-xr-x 12 127009440 nov 8 14:34
> >> platform-secplatform/packages/mesa-21.2.3/usr/lib/dri/virtio_gpu_dri.so
> >> -rwxr-xr-x 12 127009440 nov 8 14:34
> >> platform-secplatform/packages/mesa-21.2.3/usr/lib/dri/vmwgfx_dri.so
> >>
> >> .. or something else that's apparently magic is happening.
> >
> > kmsro just wraps around other drivers that support the render GPU being
> > different from the scanout GPU. From the list above you have not
> > enabled any of those drivers (e.g. etnaviv, freedreno, panfrost, ...),
> > so there isn't anything to wrap around for kmsro, so you don't get any
> > libraries built.
> >
>
> In that case ptxdist makes a static assumption that libraries are being
> built and named, regardless what is selected?
> Problem is that $(firstword) from the GALLIUM_LIBS is expected to exist
> if kmsro is selected?
>
> MESALIB_DRI_GALLIUM_LIBS-y = \
> $(subst kmsro, \
> armada-drm \
> exynos \
> hx8357d \
> ili9225 \
> ili9341 \
> imx-dcss \
> imx-drm \
> ingenic-drm \
> mali-dp \
> mcde \
> mediatek \
> meson \
> mi0283qt \
> mxsfb-drm \
> pl111 \
> repaper \
> rockchip \
> st7586 \
> st7735r \
> stm \
> sun4i-drm \
So I looked into this:
'kmsro' is listed as a possible option for '-Dgallium-drivers='. But that's
actually ignored. Instead, we have:
with_gallium_kmsro = with_gallium_v3d or with_gallium_vc4 or with_gallium_etnaviv or with_gallium_panfrost or with_gallium_lima or with_gallium_freedreno
So kmsro is only built when at least on of the drivers listed here is
built. If that is the case, then all the kmsro hardlinks (for armada-drm
etc.) are created.
In your case: just disable MESALIB_DRI_KMSRO. You don't need it.
I'll turn it into a noprompt option with the correct dependencies to avoid
this in the future.
Michael
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
To unsubscribe, send a mail with subject "unsubscribe" to ptxdist-request@pengutronix.de
next prev parent reply other threads:[~2021-11-09 15:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-08 10:16 Christian Melki
2021-11-08 13:03 ` Michael Olbrich
2021-11-08 13:37 ` Christian Melki
2021-11-08 14:08 ` Lucas Stach
2021-11-08 14:28 ` Christian Melki
2021-11-09 15:42 ` Michael Olbrich [this message]
2021-11-09 15:46 ` Christian Melki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211109154206.GO22301@pengutronix.de \
--to=m.olbrich@pengutronix.de \
--cc=christian.melki@t2data.com \
--cc=ptxdist@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox