You are not logged in.
The latest mesa-git/llvm-libs-svn broke Plasma and Plasma-Wayland. The desktop doesn't load anymore. I had to go back to llvm-libs-svn-320552 to get it working again.
Update: As of llvm-libs-svn 321091 Plasma and Plasma-Wayland do work again.
Last edited by raneon (2017-12-20 09:37:52)
Offline
lone_wolf to answer your question im having same situation as above poster only im not using wayland, but downgrading to same svn version fixes, however i switched to non svn llvm for now (version 5) to make daily upgrades easier
Last edited by pr0dukter (2017-12-20 23:53:53)
Offline
I'm getting a dependency problem updating:
clang and clang-svn are in conflict (clang-analyzer). Remove clang-svn? [y/N] y
error: failed to prepare transaction (could not satisfy dependencies)
opencl-mesa-git: removing clang-svn breaks dependency 'clang-svn'
Offline
Will this "-git" version eventually hit the official repository and replace the default mesa once the bugs have been sorted out? I would like this version but it takes awhile to compile on my AMD system.
Order brings discipline, discipline brings strength
Offline
warning: removing 'clang' from target list because it conflicts with 'clang-svn'
error: failed to prepare transaction (could not satisfy dependencies)
qtcreator: requires clang=5.0.1
I guess it needs to provide clang=5.0.1 to satisfy qtcreators requirements?
Offline
Will this "-git" version eventually hit the official repository and replace the default mesa once the bugs have been sorted out? I would like this version but it takes awhile to compile on my AMD system.
Yes, changes in -git master will be in future stable Mesa versions.
https://www.mesa3d.org/releasing.html may help to understand the process.
---------------------------------------------
I guess it needs to provide clang=5.0.1 to satisfy qtcreators requirements?
won't work.
llvm / clang applications need to have runtime libraries installed that match the ones that were used to compile them with (only very minor differences are possible).
Unfortunately several of the used libs are not versioned and afaik llvm / clang don't provide a mechanism to choose between available libraries.
I think this is also part of the reason why AMD GPUOPEN and ROCm initiatives weren't picked up as fast by arch users as typical with new developments.
both needed changes to llvm / clang that hadn't been upstreamed.
(I sometimes wish llvm / clang would be gcc components instead of a separate compiler suite . GNU people figured out how to allow multiple installed versions a long time ago ... )
Kerberizer (aur llvm-svn maintainer) has created an issue to discuss possible solutions, but we haven't found a good way yet.
For now the only reliable solution appears to be having separate installs / VMs for every llvm/clang version you need.
( my main system has had llvm-svn installed since mesa started using it years ago, qt creator used to be on it also but was moved to a VM when qt creator gained llvm as dep)
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
Plasma-Wayland 5.12 beta does't show the desktop anymore with mesa-git-99322.4584c4ef04, kwin starts but there are some issues as well. Had to go back to mesa-git-99311. Same issue on Plasma X11.
Offline
Does it work with latest stable plasma (5.11.5 atm) ?
If yes, the problem could be in plasma and not mesa.
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
Does it work with latest stable plasma (5.11.5 atm) ?
If yes, the problem could be in plasma and not mesa.
I didn't test Plasma 5.11.5, as like in the past I wait a couple of days and then one mesa update does fix it. Now all works again.
Offline
Plasma-Wayland 5.12 beta does't show the desktop anymore with mesa-git-99322.4584c4ef04, kwin starts but there are some issues as well. Had to go back to mesa-git-99311. Same issue on Plasma X11.
It should be fixed with latest mesa-git (https://cgit.freedesktop.org/mesa/mesa/ … 10192432a1)
Offline
Is it normal for glxinfo to not show Gallium? I'm back to linux after almost a year and my performance is abysmal compared to last time with amdgpu and mesa-git. I'm using lcarlier's mesa-git, normal linux kernel and followed the guide in arch wiki to install and enable amdgpu on CIK/SI cards. It is mainly CSGO that I've noticed (only game I've installed so far) while in the past I'd have almost 200 stable FPS now I get like 60 on freezetime and unstable 30 to 45~50 climbing to 60 during the round no matter the settings.
glxinfo | grep OpenGL
OpenGL vendor string: X.Org
OpenGL renderer string: AMD Radeon R7 200 Series (BONAIRE / DRM 3.19.0 / 4.14.15-1-ARCH, LLVM 7.0.0)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.1.0-devel (git-b633999a4e)
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 18.1.0-devel (git-b633999a4e)
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 18.1.0-devel (git-b633999a4e)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
OpenGL ES profile extensions:
lspci | grep VGA
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Bonaire XTX [Radeon R7 260X/360]
dmesg | grep amdgpu
[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-linux root=redact rw quiet amdgpu.audio=0 amdgpu.cik_support=1 amdgpu.si_support=1 radeon.cik_support=0 radeon.si_support=0
[ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-linux root=redact rw quiet amdgpu.audio=0 amdgpu.cik_support=1 amdgpu.si_support=1 radeon.cik_support=0 radeon.si_support=0
[ 1.220492] [drm] amdgpu kernel modesetting enabled.
[ 1.221249] fb: switching to amdgpudrmfb from VESA VGA
[ 1.221609] amdgpu 0000:01:00.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0xffff
[ 1.222553] amdgpu 0000:01:00.0: VRAM: 2048M 0x000000F400000000 - 0x000000F47FFFFFFF (2048M used)
[ 1.222554] amdgpu 0000:01:00.0: GTT: 1024M 0x0000000000000000 - 0x000000003FFFFFFF
[ 1.222624] [drm] amdgpu: 2048M of VRAM memory ready
[ 1.222625] [drm] amdgpu: 3072M of GTT memory ready.
[ 1.223163] amdgpu 0000:01:00.0: amdgpu: using MSI.
[ 1.223186] [drm] amdgpu: irq initialized.
[ 1.223279] [drm] amdgpu: dpm initialized
[ 1.223660] amdgpu 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000000400080, cpu addr 0xffffb2428111d080
[ 1.223694] amdgpu 0000:01:00.0: fence driver on ring 1 use gpu addr 0x0000000000400100, cpu addr 0xffffb2428111d100
[ 1.223736] amdgpu 0000:01:00.0: fence driver on ring 2 use gpu addr 0x0000000000400180, cpu addr 0xffffb2428111d180
[ 1.223781] amdgpu 0000:01:00.0: fence driver on ring 3 use gpu addr 0x0000000000400200, cpu addr 0xffffb2428111d200
[ 1.223824] amdgpu 0000:01:00.0: fence driver on ring 4 use gpu addr 0x0000000000400280, cpu addr 0xffffb2428111d280
[ 1.223865] amdgpu 0000:01:00.0: fence driver on ring 5 use gpu addr 0x0000000000400300, cpu addr 0xffffb2428111d300
[ 1.223903] amdgpu 0000:01:00.0: fence driver on ring 6 use gpu addr 0x0000000000400380, cpu addr 0xffffb2428111d380
[ 1.223945] amdgpu 0000:01:00.0: fence driver on ring 7 use gpu addr 0x0000000000400400, cpu addr 0xffffb2428111d400
[ 1.223982] amdgpu 0000:01:00.0: fence driver on ring 8 use gpu addr 0x0000000000400480, cpu addr 0xffffb2428111d480
[ 1.224057] amdgpu 0000:01:00.0: fence driver on ring 9 use gpu addr 0x0000000000400500, cpu addr 0xffffb2428111d500
[ 1.224229] amdgpu 0000:01:00.0: fence driver on ring 10 use gpu addr 0x0000000000400580, cpu addr 0xffffb2428111d580
[ 1.224584] amdgpu 0000:01:00.0: fence driver on ring 11 use gpu addr 0x000000f40028bd30, cpu addr 0xffffb24282238d30
[ 1.224713] amdgpu 0000:01:00.0: fence driver on ring 12 use gpu addr 0x0000000000400680, cpu addr 0xffffb2428111d680
[ 1.224755] amdgpu 0000:01:00.0: fence driver on ring 13 use gpu addr 0x0000000000400700, cpu addr 0xffffb2428111d700
[ 1.471087] fbcon: amdgpudrmfb (fb0) is primary device
[ 1.549958] amdgpu 0000:01:00.0: fb0: amdgpudrmfb frame buffer device
[ 1.563872] [drm] Initialized amdgpu 3.19.0 20150101 for 0000:01:00.0 on minor 0
Offline
Is it normal for glxinfo to not show Gallium?
yes, glxinfo now shows more details about actual hardware.
What processor do you have ?
Is the R7 the only videocard in this system ?
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
Is it normal for glxinfo to not show Gallium?
yes, glxinfo now shows more details about actual hardware.
What processor do you have ?
Is the R7 the only videocard in this system ?
I use a FX6300 and that is the only card I have
Offline
my r9 380x amdgpu cant load dri2 or dri3 so cant rotate 2 of 3 monitors im ultra-ultra-ultra-wide
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?
Issue: I usually only upgrade them together, but yesterday I did not realize there was no new mesa stuff and installed the new llvm packages, which then broke the system as there seems to be a breaking change in the API or something.
Offline
see https://bbs.archlinux.org/viewtopic.php … 1#p1769571 for mesa-git success 4.15+ linux and linux-ck-bulldozer
Offline
Mesa-git currently has an issue where TTF fonts don't render visible text in many programs.
https://bugs.freedesktop.org/show_bug.cgi?id=105262
https://bbs.archlinux.org/viewtopic.php?id=234852
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
The bug i mentioned has been fixed and the fix was committed to master.
Lordheavy, on mesa maintainers ML emil velikov announced he wanted to get distro patches for mesa upstreamed.
The glvnd-fix-gl-dot-pc.patch arch linux and fedora use is no longer needed, atleast for git master.
No idea if that change will make it in mesa 18.0 , but i suggest you change your mesa-git packages and keep removal of the patch in mind for stable mesa.
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
Hmm, is there a good reason why mesa-git now requires a music player (tizonia) to be installed?
Offline
The OpenMAX IL state tracker was switched from bellagio to tizonia. I guess the tizonia package should be built with only the library needed for mesa and minimal dependencies or at least shipped as a split package.
https://www.phoronix.com/scan.php?page= … nia-Encode
Last edited by progandy (2018-03-12 14:10:41)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
Oh I see. Wasn't that done last summer though? Or maybe a build conf changed recently.
Then, yes I agree, it would make sense to only include the minimum needed, and not libspotify and such...
Offline
The GSoC project first had to be verified and then merged into the git master. That was done in March 2018 and now the arch build of mesa-git has been modified.
https://www.phoronix.com/scan.php?page= … a-H264-Git
Don't expect that this will be the final configuration, mesa-git may change things around to test new features. What lands in the stable arch package is another thing.
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
Oh I see, thank you for the information!
Offline
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
Offline
--enable-omx-bellagio enable OpenMAX Bellagio library [default=disabled]
--enable-omx-tizonia enable OpenMAX Tizonia library [default=disabled]
So now we have 2 possibilities for openmax support in mesa.
I see one applcation in our repos that supports omx-bellagio , ffmpeg .
Are there actually other x86_64 applications (besides this tizonia) that use openmax IL ?
Also there doesn't seem to be a tizonia-library or tizonia-core package in aur/repos yet, so I'll wait with adding omx-tizonia support to AUR mesa-git .
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