You are not logged in.
gee wrote:Hmm, is there a good reason why mesa-git now requires a music player (tizonia) to be installed?
Because mesa-git will now be built with tizonia support instead of openmax
Thank you for getting a core package now, that makes more sense to me than my GPU driver depending on libspotify
Offline
@lordheavy: just an idea because of an issue I had with current llvm-svn, but wouldn't it be better to only offer the newer llvm packages if the mesa packages compile fine with it?
Similarly it's kind of weird to see lib32-mesa-git offered an update but not mesa-git.
Offline
gee wrote:@lordheavy: just an idea because of an issue I had with current llvm-svn, but wouldn't it be better to only offer the newer llvm packages if the mesa packages compile fine with it?
Similarly it's kind of weird to see lib32-mesa-git offered an update but not mesa-git.
You can't update llvm after you build mesa packages otherwise you could have broken rendering with radeonsi drivers. Currently opencl is broken because of llvm-svn, so i have temporary disabled the building of opencl package (opencl-mesa-git package is empty) until it's fixed upstream
Offline
You can't update llvm after you build mesa packages otherwise you could have broken rendering with radeonsi drivers.
I don't understand what you mean, I currently can clearly update only llvm from your repository, even if may break radeonsi.
(I usually don't, until I forget and that's of course when I must follow by a pacman -Sc )
Currently opencl is broken because of llvm-svn, so i have temporary disabled the building of opencl package (opencl-mesa-git package is empty) until it's fixed upstream
I assumed it was some stuff that was not in 32b, but I did not feel confident enough to install it anyway.
Offline
lordheavy wrote:You can't update llvm after you build mesa packages otherwise you could have broken rendering with radeonsi drivers.
I don't understand what you mean, I currently can clearly update only llvm from your repository, even if may break radeonsi.
(I usually don't, until I forget and that's of course when I must follow by a pacman -Sc )
Oh, yes, i mean when i build mesa-git, i need to build llvm-svn first because radeonsi depends on some bytecode generated by llvm (and this bytecode can change after an update of llvm),
so you can't know if mesa-git building will fail because of a change in llvm-svn.
Offline
Oh, yes, i mean when i build mesa-git, i need to build llvm-svn first because radeonsi depends on some bytecode generated by llvm (and this bytecode can change after an update of llvm),
so you can't know if mesa-git building will fail because of a change in llvm-svn.
Yes I understand that, but you could delay the offering of the llvm package, or make mesa depend on the exact package it was built against.
The latter seems better, yet it would mean that right now it'd be impossible to install mesa-git, so maybe not.
It's not a big deal, that was just a suggestion of course.
Offline
@lordheavy I think the GPU drivers need their PKGBUILD updated to show support for the new Xorg 1.20 release. I'm pretty sure the ABI should already be supported and just need to be recompiled but I definately could be wrong on that one.
Offline
Second build failure with opencl / llvm-svn changes in a few weeks, see https://bugs.freedesktop.org/show_bug.cgi?id=106619
LordHeavy, you may want to delay updating llvm-svn in your repo.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
I cannot install the mesa-git-debug package anymore. Is it still getting updated?
Offline
mesa-git-debug-102413.58fb613a51-1-x86_64.pkg.t..> 27-May-2018 15:35 109807156
Looks like that's latest version in LordHeavy's unoffical repo.
What do you mean by "cannot install", what error messages do you get ?
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
I had to translate the messages:
$ sudo pacman -S mesa-git-debug
Resolve dependencies...
Warning: Cannot resolve "mesa-git=102413.58fb613a51-1" (a dependency of "mesa-git-debug")
:: The following package cannot be updated as of unresolved dependencies:
mesa-git-debug
:: Do you want to skip the package during this update? [j/N]
It seems like mesa-git-debug still depends from the older mesa-git package, which is not anymore available on my system.
Offline
http://pkgbuild.com/~lcarlier/mesa-git/ … t/PKGBUILD is the latest version posted by LordHeavy, and it doesn't show a *-debug package.
You could try building a debug version yourself by modifying the PKGBUILD, see https://wiki.archlinux.org/index.php/De … ing_Traces
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
http://pkgbuild.com/~lcarlier/mesa-git/ … t/PKGBUILD is the latest version posted by LordHeavy, and it doesn't show a *-debug package.
You could try building a debug version yourself by modifying the PKGBUILD, see https://wiki.archlinux.org/index.php/De … ing_Traces
Thanks I try to avoid compiling Mesa as last time I failed ;-) But the today's update fixed it for me, I could install mesa-git-debug now.
Offline
Hope this is the right place to post info that might help other users:
if you are having issues using mesa-git with Firefox and OpenGL enabled (see https://wiki.archlinux.org/index.php/Fi … 28OMTC.29), you might experience crashes for some FF tabs that use OpenGL (i.e.: Google Sheets, Maps etc).
The bug and workaround are here: https://bugzilla.mozilla.org/show_bug.cgi?id=1480755#c0
Simply go to FF about:config > security.sandbox.content.read _path_whitelist and add /sys/
Hope this helps other folks
Offline
Posted this on the AUR package, but for reference I'll post it here too:
Not sure if this is deliberate, but this Mesa package no-longer seems to be installing "/etc/drirc" which is needed for 3D workarounds and other things. The default system package still installs this file and AFAIK this package should be installing it too.
Offline
It seems that the default configuration moved to "/usr/share/drirc.d/"
https://github.com/mesa3d/mesa/commit/3 … 727bd3a6dd
https://github.com/mesa3d/mesa/commit/0 … 2007776f80
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
So it has, thanks for that. Guess it's fine then as those files are there.
Offline
Hi everyone, is anyone else unable to compile lib32-mesa-git? Thanks for your input.
[495/2265] Linking target src/amd/vulkan/libvulkan_radeon.so.
FAILED: src/amd/vulkan/libvulkan_radeon.so
g++ -m32 -o src/amd/vulkan/libvulkan_radeon.so 'src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/meson-generated_.._radv_entrypoints.c.o' 'src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/meson-generated_.._radv_extensions.c.o' 'src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/meson-generated_.._vk_format_table.c.o' 'src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/winsys_amdgpu_radv_amdgpu_bo.c.o' 'src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/winsys_amdgpu_radv_amdgpu_cs.c.o' 'src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/winsys_amdgpu_radv_amdgpu_surface.c.o' 'src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/winsys_amdgpu_radv_amdgpu_winsys.c.o' 'src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/radv_cmd_buffer.c.o' 'src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/radv_debug.c.o' 'src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/radv_device.c.o' 'src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/radv_descriptor_set.c.o' 'src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/radv_formats.c.o' 'src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/radv_image.c.o' 'src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/radv_llvm_helper.cpp.o' 'src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/radv_meta.c.o' 'src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/radv_meta_blit.c.o' 'src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/radv_meta_blit2d.c.o' 'src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/radv_meta_buffer.c.o' 'src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/radv_meta_bufimage.c.o' 'src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/radv_meta_clear.c.o' 'src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/radv_meta_copy.c.o' 'src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/radv_meta_decompress.c.o' 'src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/radv_meta_fast_clear.c.o' 'src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/radv_meta_resolve.c.o' 'src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/radv_meta_resolve_cs.c.o' 'src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/radv_meta_resolve_fs.c.o' 'src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/radv_nir_to_llvm.c.o' 'src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/radv_pass.c.o' 'src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/radv_pipeline.c.o' 'src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/radv_pipeline_cache.c.o' 'src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/radv_shader.c.o' 'src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/radv_shader_info.c.o' 'src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/radv_query.c.o' 'src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/radv_util.c.o' 'src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/radv_wsi.c.o' 'src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/si_cmd_buffer.c.o' 'src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/radv_wsi_x11.c.o' 'src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/radv_wsi_wayland.c.o' 'src/amd/vulkan/src@amd@vulkan@@vulkan_radeon@sha/radv_wsi_display.c.o' -Wl,--no-undefined -Wl,--as-needed -shared -fPIC -Wl,--start-group -Wl,-soname,libvulkan_radeon.so -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now src/amd/common/libamd_common.a src/amd/addrlib/libaddrlib.a src/vulkan/util/libvulkan_util.a src/vulkan/wsi/libvulkan_wsi.a src/util/libmesa_util.a src/compiler/nir/libnir.a src/compiler/libcompiler.a -Wl,-Bsymbolic -Wl,--gc-sections -lLLVM-8svn /usr/lib32/libdrm_amdgpu.so /usr/lib32/libelf.so -ldl -lm -lLLVM-8svn /usr/lib32/libxcb.so /usr/lib32/libX11-xcb.so /usr/lib32/libX11.so /usr/lib32/libxcb-dri2.so /usr/lib32/libxcb-dri3.so /usr/lib32/libxcb-present.so /usr/lib32/libxcb-sync.so /usr/lib32/libxshmfence.so /usr/lib32/libwayland-client.so /usr/lib32/libxcb-randr.so /usr/lib/libXrandr.so /usr/lib32/libdrm.so /usr/lib32/libz.so -Wl,--end-group -pthread
/usr/bin/ld: /usr/lib/libXrandr.so: error adding symbols: file in wrong format
collect2: error: ld returned 1 exit status
[510/2265] Compiling C++ object 'src/intel/compiler/src@intel@compiler@@intel_compiler@sta/brw_fs_nir.cpp.o'.
../mesa/src/intel/compiler/brw_fs_nir.cpp:1720:1: warning: ‘brw_reg_type get_image_base_type(const glsl_type*)’ defined but not used [-Wunused-function]
get_image_base_type(const glsl_type *type)
^~~~~~~~~~~~~~~~~~~
[512/2265] Compiling C++ object 'src/intel/compiler/src@intel@compiler@@intel_compiler@sta/brw_fs.cpp.o'.
ninja: build stopped: subcommand failed.
==> ERROR: A failure occurred in build().
Aborting...
Error making: lib32-mesa-git
"Normal's Overrated"
Offline
If you're using my AUR lib32-mesa-git , try building again.
latest git master revision ac0856ae41 (pkgver 18.3.0_devel.104543.ac0856ae41-1 ) builds fine.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
I had to go back to libdrm-git-6416.28328298 and mesa-git-104815.08103c5f65, as libdrm-git-6433.1e3fcc49 and mesa-git-104860.18a6e426f3 broke OpenGL acceleration my my system, SDDM and GDM didn't start anymore and showed only a black screen on my Radeon RX480.
Last edited by raneon (2018-09-21 18:29:42)
Offline
Had to do the same thing with the mostly same card, an RX580. Open GL broke.
Offline
Those version numbers suggest raneon & vaporeon both use Lord Heavy mesa-git repo.
I don't use that, but did have problems with libdrm-git recently that forced me to downgrade to a slightly older version.
Try reverting to stock libdrm.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
With the latest update all is good again, OpenGL works with libdrm-git 6438.4ec31fc3.
Offline
Updating lib32-mesa seems to break everything.
AIGLX error: dlopen of /usr/lib/dri/swrast_dri.so failed (libsensors.so.4: cannot open shared object file: No such file or directory)
For some reason this never happened before todays update. Only libsensors.so.5 is on my system.
Offline
lmsensors was updated today and apparently had a soname bump.
If you're using my aur *-mesa-git packages , try rebuilding them.
Incase you're using Lord Heavy's mesa-git repo, you'll have to wait until he rebuilds the packages (or you could try contacting him directly) .
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline