This is the big Mesa re-org. gbm, libglapi, libglesv2, libGL, and libEGL have been consolidated into mesa-libs and dri is renamed to mesa-dri for consistency/clarity. mesa-dri is now the master port since it builds almost everything anyway and mesa-libs could (eventually) be a subpackage of it. The component specific bits were moved out of Makefile.common which allowed a the builds toi be further pruned. Clover now just builds gallium pipes for supported hardware (r600 and radeonsi) instead of everything, libosmesa builds the gallium version when possible, and a Wayland option has been added to mesa-libs. The separate USE_GL components gl, glesv2, egl, and gbm were preserved, in case mesa-libs should be split into subpackages, and now all just bring a dependency on mesa-libs. The few ports with direct dependencies have been updated.
Details
- Reviewers
swills feld - Group Reviewers
x11 O5: Ports Framework (Owns No Changed Paths) portmgr - Commits
- rP440699: Consolidate the Mesa ports, update to 17.0.4, and add Wayland option
Poudriere 10.3/11.0 amd64/i386 OK, run verified on 11amd64, pkg upgrade scenario verified, exp-run needed
Diff Detail
- Repository
- rP FreeBSD ports repository
- Lint
No Lint Coverage - Unit
No Test Coverage - Build Status
Buildable 9018 Build 9423: arc lint + arc unit
Event Timeline
Hey! Nice work on this.
I have a couple of suggestions that to make way for Wayland.
In Mesa:
- Can we have mesa-libs also generate libwayland-egl.so?
- Wayland also needs to be enabled with --with-egl-platforms flag (previosly in libGL Makefile.common)
- Enable DRI3 by default? (not really needed for wayland)
Outside of Mesa I would like to
- Enable wayland backend by default in gtk30.
- Enable Xwayland in xorg-server
This will add default dependency on wayland for xorg and gtk30 but I think it will be hard to make wayland optional given the dependencies.
That is done when the WAYLAND option is enabled.
- Wayland also needs to be enabled with --with-egl-platforms flag (previosly in libGL Makefile.common)
Also done when the WAYLAND option is enabled.
- Enable DRI3 by default? (not really needed for wayland)
DRI3 support is already enabled at build time. There is an extra runtime switch due to EGL failing to fallback to DRI2 when the system doesn't support DRI3, i.e. stock FreeBSD. I hope that work-around will be short lived but there is not yet any response to the ticket I opened upstream so I might have to be the one to fix it.
Outside of Mesa I would like to
- Enable wayland backend by default in gtk30.
- Enable Xwayland in xorg-server
We have x11-servers/xwayland now. Is there something missing or not enabled in the build?
This will add default dependency on wayland for xorg and gtk30 but I think it will be hard to make wayland optional given the dependencies.
I don't know about gtk30 but hopefully Wayland can be optional for both Xorg and gtk30.
- Can we have mesa-libs also generate libwayland-egl.so?
That is done when the WAYLAND option is enabled.
That means to use Wayland related stuff you still need to build your own ports? (meaning no 'pkg install weston' for those who want to try it)
This will add default dependency on wayland for xorg and gtk30 but I think it will be hard to make wayland optional given the dependencies.
I don't know about gtk30 but hopefully Wayland can be optional for both Xorg and gtk30.
Maybe we can split it up like xorg-server/xwayland. gtk30-wayland?
About GTK3 I will have to look at that. I'm not sure yet how to tackle that since there is also the X backend to consider.
| graphics/mesa-libs/Makefile | ||
|---|---|---|
| 18 | Can the WAYLAND option be enabled by default? While we might not be so far that wayland is able to driver a complete desktop (thinking about GNOME here), simple desktop do work. Although I'm not sure if everything that needed is in ports yet. And seeing the Linux works moving towards it, it really help the people that work on it and want to test it. | |
That is correct, those who wish to try Wayland will n6eed to build some ports with non-default options. The alternative is worse; making everyone using Xorg/Mesa install parts of Wayland regardless of their intent to use it. Unfortunately, we cannot just split off libwayland-egl.so into it's own package because the WAYLAND option also affects the build of gbm (part of the reason to combine the libs was to have a single WAYLAND option affecting both gbm and EGL). I cannot think of a better solution without support for flavors (which would allow packages for mesa-libs and mesa-libs+wayland) but am open to suggestions.
This will add default dependency on wayland for xorg and gtk30 but I think it will be hard to make wayland optional given the dependencies.
I don't know about gtk30 but hopefully Wayland can be optional for both Xorg and gtk30.
Maybe we can split it up like xorg-server/xwayland. gtk30-wayland?
That would be ideal if possible. I do not know much about gtk30 so I cannot comment on the feasibility and will defer to kwm as the expert.
That is correct, those who wish to try Wayland will n6eed to build some ports with non-default options. The alternative is worse; making everyone using Xorg/Mesa install parts of Wayland regardless of their intent to use it. Unfortunately, we cannot just split off libwayland-egl.so into it's own package because the WAYLAND option also affects the build of gbm (part of the reason to combine the libs was to have a single WAYLAND option affecting both gbm and EGL). I cannot think of a better solution without support for flavors (which would allow packages for mesa-libs and mesa-libs+wayland) but am open to suggestions.
When I install X I get a bunch of legacy crap I never use. At least a couple of Wayland files is in the direction we're going and won't hog that much disk space.. Personally I don't see the harm.
- libwayland-egl 4,632 bytes
- libgbm slightly larger size?
- Possibly some header files and a bigger library for GTK.
Are the ones I can think of that you'd get. The rest is in wayland & deps and the compositors.
Xwayland is the big one and that's already a separate port.
It is not the size of libwayland-egl that was the concern, rather that I expect some amount of complaints about Mesa depending on graphics/wayland. Since Xorg depends on Mesa, that would mean Xorg pulls in Wayland even without Xwayland installed. Maybe I am being overly cautious here, but "Why does Mesa depend on LLVM from ports when the same version is provided by the base system?" is a regularly recurring question, sometimes in the form of a complaint. Let's take a poll during the call today to see what the group thinks the option's default state should be.
P.S. I cleaned some of the cruft from the Xorg build, e.g. dropped a handful of legacy libs/extensions that weren't used anymore and pruned the default options in x11-drivers/xorg-drivers, but if there is other truly legacy crap getting installed somewhere down the line from x11/xorg-minimal then please tell me what else you think should not be included in minimal (of course x11/xorg will install almost everything).
It is not the size of libwayland-egl that was the concern, rather that I expect some amount of complaints about Mesa depending on graphics/wayland. Since Xorg depends on Mesa, that would mean Xorg pulls in Wayland even without Xwayland installed. Maybe I am being overly cautious here, but "Why does Mesa depend on LLVM from ports when the same version is provided by the base system?" is a regularly recurring question, sometimes in the form of a complaint. Let's take a poll during the call today to see what the group thinks the option's default state should be.
Hmm I see. Do you really need Wayland for Mesa to build Wayland platform? Can't find any dependency in Mesa makefiles. Even if it depends on it, isn't that only for building? If Xorg would pull in all Wayland stuff (libudev-devd/epoll etc) I can understand your concern and why many people would object.
The WAYLAND option adds graphics/wayland to LIB_DEPENDS because both gbm and libEGL link to libwayland-client.so and libwayland-server.so when the wayland platform is enabled.
To illustrate, I just did a build with the WAYLAND option enabled to compare output from ldd.
WAYLAND OFF
/usr/local/lib/libgbm.so:
libexpat.so.1 => /usr/local/lib/libexpat.so.1 (0x80120b000) libm.so.5 => /lib/libm.so.5 (0x801436000) libdrm.so.2 => /usr/local/lib/libdrm.so.2 (0x801660000) libthr.so.3 => /lib/libthr.so.3 (0x801871000) libc.so.7 => /lib/libc.so.7 (0x800824000)
/usr/local/lib/libEGL.so:
libthr.so.3 => /lib/libthr.so.3 (0x80122d000) libX11-xcb.so.1 => /usr/local/lib/libX11-xcb.so.1 (0x801454000) libX11.so.6 => /usr/local/lib/libX11.so.6 (0x801655000) libxcb-dri2.so.0 => /usr/local/lib/libxcb-dri2.so.0 (0x801997000) libxcb-xfixes.so.0 => /usr/local/lib/libxcb-xfixes.so.0 (0x801b9b000) libxcb.so.1 => /usr/local/lib/libxcb.so.1 (0x801da2000) libxcb-dri3.so.0 => /usr/local/lib/libxcb-dri3.so.0 (0x801fc7000) libxcb-present.so.0 => /usr/local/lib/libxcb-present.so.0 (0x8021c9000) libxcb-sync.so.1 => /usr/local/lib/libxcb-sync.so.1 (0x8023cb000) libxshmfence.so.1 => /usr/local/lib/libxshmfence.so.1 (0x8025d1000) libgbm.so.1 => /usr/local/lib/libgbm.so.1 (0x8027d2000) libexpat.so.1 => /usr/local/lib/libexpat.so.1 (0x8029dd000) libm.so.5 => /lib/libm.so.5 (0x802c08000) libdrm.so.2 => /usr/local/lib/libdrm.so.2 (0x802e32000) libc.so.7 => /lib/libc.so.7 (0x800824000) libXau.so.6 => /usr/local/lib/libXau.so.6 (0x803043000) libXdmcp.so.6 => /usr/local/lib/libXdmcp.so.6 (0x803246000)
WAYLAND ON
/usr/obj/usr/ports/graphics/mesa-libs/work/stage/usr/local/lib/libgbm.so:
libexpat.so.1 => /usr/local/lib/libexpat.so.1 (0x80120d000) libm.so.5 => /lib/libm.so.5 (0x801438000) libwayland-client.so.0 => /usr/local/lib/libwayland-client.so.0 (0x801662000) libwayland-server.so.0 => /usr/local/lib/libwayland-server.so.0 (0x801873000) libdrm.so.2 => /usr/local/lib/libdrm.so.2 (0x801a89000) libthr.so.3 => /lib/libthr.so.3 (0x801c9a000) libc.so.7 => /lib/libc.so.7 (0x800824000) libffi.so.6 => /usr/local/lib/libffi.so.6 (0x801ec1000) libepoll-shim.so.0 => /usr/local/lib/libepoll-shim.so.0 (0x8020c8000) librt.so.1 => /usr/lib/librt.so.1 (0x8022cb000)
/usr/obj/usr/ports/graphics/mesa-libs/work/stage/usr/local/lib/libEGL.so:
libthr.so.3 => /lib/libthr.so.3 (0x801233000) libX11-xcb.so.1 => /usr/local/lib/libX11-xcb.so.1 (0x80145a000) libX11.so.6 => /usr/local/lib/libX11.so.6 (0x80165b000) libxcb-dri2.so.0 => /usr/local/lib/libxcb-dri2.so.0 (0x80199d000) libxcb-xfixes.so.0 => /usr/local/lib/libxcb-xfixes.so.0 (0x801ba1000) libxcb.so.1 => /usr/local/lib/libxcb.so.1 (0x801da8000) libxcb-dri3.so.0 => /usr/local/lib/libxcb-dri3.so.0 (0x801fcd000) libxcb-present.so.0 => /usr/local/lib/libxcb-present.so.0 (0x8021cf000) libxcb-sync.so.1 => /usr/local/lib/libxcb-sync.so.1 (0x8023d1000) libxshmfence.so.1 => /usr/local/lib/libxshmfence.so.1 (0x8025d7000) libwayland-client.so.0 => /usr/local/lib/libwayland-client.so.0 (0x8027d8000) libwayland-server.so.0 => /usr/local/lib/libwayland-server.so.0 (0x8029e9000) libgbm.so.1 => /usr/local/lib/libgbm.so.1 (0x802bff000) libexpat.so.1 => /usr/local/lib/libexpat.so.1 (0x802e0a000) libm.so.5 => /lib/libm.so.5 (0x803035000) libdrm.so.2 => /usr/local/lib/libdrm.so.2 (0x80325f000) libc.so.7 => /lib/libc.so.7 (0x800824000) libXau.so.6 => /usr/local/lib/libXau.so.6 (0x803470000) libXdmcp.so.6 => /usr/local/lib/libXdmcp.so.6 (0x803673000) libffi.so.6 => /usr/local/lib/libffi.so.6 (0x803878000) libepoll-shim.so.0 => /usr/local/lib/libepoll-shim.so.0 (0x803a7f000) librt.so.1 => /usr/lib/librt.so.1 (0x803c82000)
To illustrate, I just did a build with the WAYLAND option enabled to compare output from ldd.
Hmm, that sucks. This is a big negative about the ports system... How far away is 'flavors'? :)
There is a review for flavours but it seems only to be a simple version and only for python yet.
About not enabling wayland by default, I can understand that people don't really like the extra depends of wayland in the mesa-libs port, if they don't use wayland itself.
Personaly I don't really see a problem, wayland itself is tiny, almost non existing, compared to llvm.
Wayland Flat size: 1.44MiB, llvm39 Flat size: 1.08GiB.
Approved, looks fine. The issues found in the exp-run are corrected and I'm fine with the Wayland option being off by default, for now.
I can't comment on the qa.sh patch, so leave that to portmgr@
Just curious, how did you get to the mesa-dri and mesa-libs names?
I will report back after run-time testing.
| Mk/bsd.port.mk | ||
|---|---|---|
| 1773 | These can be converted to LIB_DEPENDS again. Since we don't do the shared lib voodoo because of the nvidia-driver conflict. | |
| graphics/mesa-dri/Makefile | ||
| 12 | This took some digging, I remembered there where patents involved, but it looks like this version isn't hit by those. So there are no problems with using this by default anymore. | |
| graphics/mesa-dri/Makefile.targets | ||
| 1 | Don't forget to reset $FreeBSD$ here and in other files. | |
| graphics/mesa-libs/Makefile | ||
| 18 | Ok I think everyone knows how everyone thinks about wayland, lets keep it like it is now, we can always revisit it later. I'm planning on adding wayland support in gtk30 as a option default-off, but I need this review to land first. | |
Ideally, those would be built as a single port which produces two packages, the drivers and the libraries. The root name is mesa because that's the name upstream and what user's are most likely to look for. I had also considered mesa-drivers but the drivers retained the dri suffix since that is what the port was called previously so it remains easier to find for everyone familiar with that name. It seemed natural to use the libs suffix for the libraries.
| graphics/mesa-dri/Makefile.targets | ||
|---|---|---|
| 1 | Strange, that file does have svn:keywords set but $FreeBSD$ is handled differently than most of the other files in the diff where it is not expanded. It should not be necessary to change, svn should expand it properly on checkout. I notice Makefile.common is similarly affected, both files that were moved more than once in a single changeset, so perhaps that confuses phabricator. I'll reset those before committing to be sure. | |