Request 710853 (accepted)

This request supersedes: request 709709 (Show diff), request 710684 (Show diff)

Overview

Request 710853 accepted

- reverted latest change in specfile; it's not needed; llvm8 is
already been chosen on factory/TW by default ...

- use llvm8 on factory/TW

- n_glesv1_cm-glesv2.patch
* reenables build of GLESv1_CM and GLESv2 ...
- readded pkgconfig files for GLESv1_CM and GLESv2 to filelists
- removed again virtual provides for
* pkgconfig(glesv1_cm)
* pkgconfig(glesv2)

- reenable LTO with Mesa 19.1 (boo#1133265, comment#5)
- enabled new gallium drivers
* iris (newer Intel GPUs)
* lima, panfrost on ARM64
- virtually provide
* pkgconfig(glesv1_cm)
* pkgconfig(glesv2)
in libGLESv1_CM-devel/libGLESv2-devel packages, since these files
have been removed from Mesa via git commit #1587586

- Update to 19.1.0:
* Mesa 19.1.0 implements the OpenGL 4.5 API, but the version
reported by glGetString(GL_VERSION) or
glGetIntegerv(GL_MAJOR_VERSION) /
glGetIntegerv(GL_MINOR_VERSION) depends on the particular
driver being used. Some drivers don't support all the features
required in OpenGL 4.5. OpenGL 4.5 is only available if
requested at context creation. Compatibility contexts may
report a lower version depending on each driver.
* The top highlights include:
- GL_ARB_parallel_shader_compile for all drivers.
- GL_EXT_gpu_shader4 on all GL 3.1 drivers.
- GL_EXT_shader_image_load_formatted on radeonsi.
- GL_EXT_texture_buffer_object on all GL 3.1 drivers.
- GL_EXT_texture_compression_s3tc_srgb on Gallium and i965
drivers (ES extension).
- GL_NV_compute_shader_derivatives on Iris and i965 drivers.
- GL_KHR_parallel_shader_compile on all drivers.
- GL_INTEL_conservative_rasterization on Iris.
- Refresh patches with quilt.
- Clean-up spec files for .pc and other files no longer built.

Created by sndirsch almost 5 years ago
In state accepted
Supersedes 709709 710684

Submit Mesa

Comments for request 710853 0
Comments for request 710684 2

Aaron Puchert (aaronpuchert) - almost 5 years ago

That change should not be nescessary at all - since LLVM 8 matches LLVM >= 7.0.0 - and TW should thus alraedy use LLVM8 for Mesa when it can

Technically you're right, but it seems that the update to the llvm metapackage didn't trigger rebuilds in Tumbleweed and some packages still depend on llvm7. We had the same issue with an earlier update: I believe that's because these packages have runtime dependencies on llvm and llvm7, but neither of these packages changed in content. The only thing that changed is a Requires in llvm, but that seems not enough reason to rebuild the package.

Perhaps we need something in the llvm metapackage that triggers rebuilds.

Aaron Puchert (aaronpuchert) - almost 5 years ago

However, I agree that it shouldn't be solved here. More packages depend on llvm, and we can't do this in every package. There is an update to llvm7 on the way that should hopefully trigger rebuilds for all packages that currently depend on it, making them build with llvm8 instead.