This is a basic update of Mesa ports to 17.0.3. Default LLVM is now llvm40, and llvm39 remains a valid option along with libclc 0.2.0 (this is the combination I tested prior to release of LLVM 4.0) so those requirements were not bumped. The VDPAU option was un-restricted, a similar VAAPI option was added, and the handling of those as well as TEXTURE was moved into graphics/dri and made to use options helpers. Since these options were only declared in dri, they have always been effectively off for the other porths thus there is no reason to have them cluttering the common makefile. Support for Wayland, and collecting the Mesa libraries into a single port so that there may a single WAYLAND option, has been postponed to the next update in order to allow a quick and low-risk update to Mesa 17 with LLVM 4.0.
Details
- Reviewers
swills feld - Group Reviewers
x11 - Commits
- rP438198: Update Mesa to 17.0.3
Poudriere 10.3/11.0 amd64/i386 OK, builds on 11-STABLE PPC64, run verified on 11amd64 with Intel and Radeon graphics hardware
Diff Detail
- Repository
- rP FreeBSD ports repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Couple of comments
- why was the removal of unwanted flags moved?
- why is enable-gbm gone?
For drm-next
- we would like to enable wayland (there are commented entries in pkg-plist for wayland parts, but no enabling of wayland)
- (amdgpu) we need to fix CC/CXX/... properly
- (amdgpu) we have reports that stock mesa does not load radeonsi correctly, so we do likely need libudev-devd
libcrypto is no longer used for sha1, so we don't need USES=ssl anymore.
Upstream moved the flag stripping in their configure script, I am just following along. The post-patch action was not really correct as jbeich pointed out to me, so I backported the fix he upstreamed from 17.1-dev to 17.0. Further, I put back the removal of -fno-exceptions, which upstream inexplicable dropped in one of those "how does this work?" moments. Their configure script includes a blurb that checks if "-fno-rtti -fno-exceptions" is valid to add to the compiler flags, which is bad for C++ (unless you like a lot of errors about use of throw with exceptions disabled), so they were stripping those as in this function, but then dropped the removal of -no-exceptions while retaining removal of -fno-rtti for reasons unknown.
- why is enable-gbm gone?
Cleaning cruft; gbm is enabled by default so that is redundant.
For drm-next
- we would like to enable wayland (there are commented entries in pkg-plist for wayland parts, but no enabling of wayland)
Yes, I am very much aware of that. After you said you were concerned that Mesa 17 would be delayed by bike-shedding, I felt it best to offer up a simple upgrade to Mesa 17 that doesn't make significant changes, but does deliver VAAPI and VDPAU options for drm-next since those only affect one port (dri), so that we could then work out details of how to add Wayland support and anything else without delaying the delivery of Mesa 17 to users. As I stated in the summary, I do intend to add a WAYLAND option, but as that affects both gbm and libEGL, I would like to combine the mesa libraries into a common port to have one consistent set of library options and reduce the build duplication.
- (amdgpu) we need to fix CC/CXX/... properly
What needs to be fixed with CC/CXX? Is there a problem with the system compiler (I presume Clang/LLVM 4.0) on drm-next that requires uses of clang from llvm40?
- (amdgpu) we have reports that stock mesa does not load radeonsi correctly, so we do likely need libudev-devd
All use of libudev was removed from Mesa in v13, using libudev in Mesa is not the solution. It works on Linux with libdrm (which can use use libudev). Have you tested with libdrm from D10184? If there is any issue with probing amdgpu or loading the driver, we need to fix it in libdrm and then send it upstream when we are confident.
Add a work-around for the DRI3 problem. The root cause is insufficient checking in libEGL. Applications using GLX are ok because libGL verifies the screen is DRI3 capable before completing initialization, but libEGL does no such checks instead doing an indentical screen init as for DRI2 so we don't know DRI3 fails until the driver asserts when the app tries to draw on a NULL surface, which is well past the end of the init routine so too late to fall back to DRI2. There is already an option to disable DRI3 at runtime by setting LIBGL_DRI3_DISABLE in the environment, but it would be better to not require all users of FreeBSD to do so. The compromise solution so that Mesa can always be built with DRI3 support (which would be a messy option because every Mesa port would need it) without undue inconvenience, is to alter the runtime checks and default behavior. When compiled for a stock FreeBSD kernel, which does not support DRI3, there is an additional check so that LIBGL_DRI3_ENABLE must be set and LIBGL_DRI3_DISABLE must not be set in order for DRI3 to be activre, so the default behavior with no variable set is DRI2 and there is still the possibility to enable DRI3 for testing by setting one variable. When compiled for DRM-next the behavior is unchanged, the default is DRI3 and it may be disableed if needed by setting LIBGL_DRI3_DISABLE. Also, while adding and adjusting patches, rename all those with "legacy" names to what makepatch would have used but without any change of content.