You are not logged in.
hi, about the repo [mesa-git] I have this issue for the last update:
Yes, i've made a small typo in the lib32-mesa-git package, i will fix this ASAP
Offline
@lordheavy ... wow ! thanks.. was really quickly ! update was fine :-)
KF5 & Plasma5 (git versions) - Awesome WM
ASUS Sabertooth 990FX - AMD FX8350 - ATI Radeon HD 7970
[testing] repo
Offline
Lordheavy,
while building 65917.ca824e6 in my mesa-r* git packages i got a file conflict between the 64-bit & lib32 version.
I checked it out and noticed a new file under $pkgdir/usr/lib/dri/gallium_drv_video.so .
(both x86_64 & lib32 build put it there).
I don't know what it is good for or which component it belongs to , but it wasn't present in 65840.204dd73c revision .
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
Lordheavy,
while building 65917.ca824e6 in my mesa-r* git packages i got a file conflict between the 64-bit & lib32 version.
I checked it out and noticed a new file under $pkgdir/usr/lib/dri/gallium_drv_video.so .
(both x86_64 & lib32 build put it there).I don't know what it is good for or which component it belongs to , but it wasn't present in 65840.204dd73c revision .
This file is created with for the vaapi support, disabling libva support for 32-bit package should do the trick.
Offline
Thanks for the info, it seems this new library ignores --with-dri-driverdir setting .
I've filed https://bugs.freedesktop.org/show_bug.cgi?id=84711 to report that.
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
Hello,
well first thanks for the [mesa-git] repo.
So i'm playing around with mpv(-git) and vdpau and now vaapi. (just decocde for now)
vdpau works.
vaapi giving me some problems:
mpv --vo=opengl-hq --hwdec=vaapi someh264file.mp4
will decode the video, but it is only grayscale and some blocking.
Some Intel CPU + HD6970 repos: [all testing] + [mesa-git]
Offline
Lordheavy,
my bug report was solved, it turns out the gallium_drv_video.so is supposed to be placed in the directory set by pkgconfig libva, which is default /usr/lib/dri on arch.
The reason for the file conflict between x86_64 & lib32 files is that arch doesn't have a lib32 libva package, so there's no separate entry for lib32 stuff.
for x86-64 & i686 /usr/lib/dri is the correct location for libva related files, for lib32 the --with-va-dir paramter of ./configure can be used to get the lib32 file in /usr/lib32/dri .
If you haven't done already, I suggest you include this file in your mesa-git packages.
That way arch will support people wishing to use the new va backend for gallium drivers.
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
Would you apply this patch and compile at least lib32-llvm-svn with gcc? http://lists.cs.uiuc.edu/pipermail/llvm … 22509.html
I ask because of this problem I have with the nine d3d9 state tracker that the llvm developers don't seem to be interested in http://llvm.org/bugs/show_bug.cgi?id=21097 (or maybe the nine mesa or wine does something weird with the stack, I don't know).
Offline
@haagch
applied for some times now
Offline
I have noticed it started working a while ago. Thanks. Still, somewhere something is broken and should be fixed. Possibly clang...
Offline
Also, would you mind building the pkgbuild for the nine state tracker?
That would be of use to people using wine.
name is: mesa-d3d9-git
(You woudn't have to provide a wine-nine build, that can be done somewhere else)
It just got merged in mesa-git, please enable it in your daily builds
Offline
gee wrote:Also, would you mind building the pkgbuild for the nine state tracker?
That would be of use to people using wine.
name is: mesa-d3d9-git
(You woudn't have to provide a wine-nine build, that can be done somewhere else)It just got merged in mesa-git, please enable it in your daily builds
Of course, now i will enable it asap
Offline
Thank you!
As a little warning though:
I have built many versions since yesterday, and so far I've been unable to get it working.
I've been on IRC with some nine guys, and we haven't found why yet either...
It builds fine, but running is a different story...
Also, if the code for xf86-video-ati-git has also been merged in fdo's git, you'll need to have a build for this too (I don't know if you have daily builds for these or not).
Last edited by gee (2014-11-18 09:04:22)
Offline
Alright, I got my bug fixed, so now I have no warning left for you
Offline
Lordheavy,
my bug report was solved, it turns out the gallium_drv_video.so is supposed to be placed in the directory set by pkgconfig libva, which is default /usr/lib/dri on arch.
The reason for the file conflict between x86_64 & lib32 files is that arch doesn't have a lib32 libva package, so there's no separate entry for lib32 stuff.
for x86-64 & i686 /usr/lib/dri is the correct location for libva related files, for lib32 the --with-va-dir paramter of ./configure can be used to get the lib32 file in /usr/lib32/dri .
If you haven't done already, I suggest you include this file in your mesa-git packages.
That way arch will support people wishing to use the new va backend for gallium drivers.
Any way to go around this without building everything from source? I'd like to use mesa-git repo.
Offline
gutigen,
I've looked at mesa-git-66588.bc5f542-1-x86_64.pkg.tar.xz from mesa-git repo and that does have the gallium_drv_video.so for VA in the right location.
The lib32-mesa-git however doesn't have the 32-bit file.
If you want to use VA in both 64-bit & 32-bit multilib apps, you'll have to build my mesa-r* / lib32-mesa-r* AUR packages.
I do use mesa-git for the LLVM / clang packages, so you don't need to build EVERYTHING, just 2 packages
Keep in mind that my packages don't include intel, nouveau & classic radeon drivers.
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
Lone_Wolf,
Thanks for info, I've ended up building mesa-git and lib32-mesa-git from AUR and installing other packages from mesa-git repo, works great so far and took less time than expected
Offline
Hi @lordheavy with the recently update in [mesa-git] repo for the packages clang-* and llvm-* rev 228304 I had crash in my X session,
249.233] (EE)
[ 249.233] (EE) Backtrace:
[ 249.236] (EE) 0: /usr/bin/Xorg.bin (xorg_backtrace+0x56) [0x594276]
[ 249.236] (EE) 1: /usr/bin/Xorg.bin (0x400000+0x1983c9) [0x5983c9]
[ 249.236] (EE) 2: /usr/lib/libc.so.6 (0x7f6eb3288000+0x33b20) [0x7f6eb32bbb20]
[ 249.236] (EE) 3: /usr/lib/libLLVM-3.7svn.so (_ZNK4llvm18TargetRegisterInfo24getMatchingSuperRegClassEPKNS_19TargetRegisterClassES3_j+0x14) [0x7f6eaa380644]
[ 249.237] (EE) 4: /usr/lib/libLLVM-3.7svn.so (0x7f6ea9840000+0xae52f5) [0x7f6eaa3252f5]
[ 249.238] (EE) 5: /usr/lib/libLLVM-3.7svn.so (0x7f6ea9840000+0xae6006) [0x7f6eaa326006]
[ 249.238] (EE) 6: /usr/lib/libLLVM-3.7svn.so (0x7f6ea9840000+0xae81fd) [0x7f6eaa3281fd]
[ 249.239] (EE) 7: /usr/lib/libLLVM-3.7svn.so (_ZN4llvm13FPPassManager13runOnFunctionERNS_8FunctionE+0x1e7) [0x7f6ea9eafcc7]
[ 249.239] (EE) 8: /usr/lib/libLLVM-3.7svn.so (_ZN4llvm13FPPassManager11runOnModuleERNS_6ModuleE+0x2b) [0x7f6ea9eafd5b]
[ 249.240] (EE) 9: /usr/lib/libLLVM-3.7svn.so (_ZN4llvm6legacy15PassManagerImpl3runERNS_6ModuleE+0x2c9) [0x7f6ea9eb21b9]
[ 249.240] (EE) 10: /usr/lib/libLLVM-3.7svn.so (0x7f6ea9840000+0xb783ee) [0x7f6eaa3b83ee]
[ 249.241] (EE) 11: /usr/lib/libLLVM-3.7svn.so (LLVMTargetMachineEmitToMemoryBuffer+0x16a) [0x7f6eaa3b85ca]
[ 249.241] (EE) 12: /usr/lib/xorg/modules/dri/radeonsi_dri.so (0x7f6eac130000+0x5c09db) [0x7f6eac6f09db]
[ 249.241] (EE) 13: /usr/lib/xorg/modules/dri/radeonsi_dri.so (0x7f6eac130000+0x53d1fd) [0x7f6eac66d1fd]
[ 249.241] (EE) 14: /usr/lib/xorg/modules/dri/radeonsi_dri.so (0x7f6eac130000+0x53d904) [0x7f6eac66d904]
[ 249.241] (EE) 15: /usr/lib/xorg/modules/dri/radeonsi_dri.so (0x7f6eac130000+0x545c90) [0x7f6eac675c90]
[ 249.241] (EE) 16: /usr/lib/xorg/modules/dri/radeonsi_dri.so (0x7f6eac130000+0x5460de) [0x7f6eac6760de]
[ 249.241] (EE) 17: /usr/lib/xorg/modules/dri/radeonsi_dri.so (0x7f6eac130000+0x544095) [0x7f6eac674095]
[ 249.241] (EE) 18: /usr/lib/xorg/modules/dri/radeonsi_dri.so (0x7f6eac130000+0x30cd95) [0x7f6eac43cd95]
[ 249.241] (EE) 19: /usr/lib/xorg/modules/dri/radeonsi_dri.so (0x7f6eac130000+0x1c594f) [0x7f6eac2f594f]
[ 249.241] (EE) 20: /usr/lib/xorg/modules/dri/radeonsi_dri.so (0x7f6eac130000+0x19780a) [0x7f6eac2c780a]
[ 249.241] (EE) 21: /usr/lib/xorg/modules/dri/radeonsi_dri.so (0x7f6eac130000+0x197b24) [0x7f6eac2c7b24]
[ 249.241] (EE) 22: /usr/lib/xorg/modules/dri/radeonsi_dri.so (0x7f6eac130000+0x197bcb) [0x7f6eac2c7bcb]
[ 249.241] (EE) 23: /usr/lib/xorg/modules/libglamoregl.so (0x7f6ead670000+0x197c6) [0x7f6ead6897c6]
[ 249.242] (EE) 24: /usr/lib/xorg/modules/libglamoregl.so (0x7f6ead670000+0x1a2a4) [0x7f6ead68a2a4]
[ 249.242] (EE) 25: /usr/lib/xorg/modules/libglamoregl.so (0x7f6ead670000+0x1b290) [0x7f6ead68b290]
[ 249.242] (EE) 26: /usr/lib/xorg/modules/libglamoregl.so (0x7f6ead670000+0x1b96b) [0x7f6ead68b96b]
[ 249.242] (EE) 27: /usr/bin/Xorg.bin (0x400000+0x11a951) [0x51a951]
[ 249.242] (EE) 28: /usr/bin/Xorg.bin (0x400000+0x110644) [0x510644]
[ 249.242] (EE) 29: /usr/bin/Xorg.bin (0x400000+0x37807) [0x437807]
[ 249.242] (EE) 30: /usr/bin/Xorg.bin (0x400000+0x3b9a6) [0x43b9a6]
[ 249.242] (EE) 31: /usr/lib/libc.so.6 (__libc_start_main+0xf0) [0x7f6eb32a8040]
[ 249.242] (EE) 32: /usr/bin/Xorg.bin (0x400000+0x25dce) [0x425dce]
[ 249.242] (EE)
[ 249.242] (EE) Segmentation fault at address 0x18
[ 249.242] (EE)
Fatal server error:
[ 249.242] (EE) Caught signal 11 (Segmentation fault). Server aborting
[ 249.243] (EE)
[ 249.243] (EE)
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
[ 249.243] (EE) Please also check the log file at "/home/luis/.local/share/xorg/Xorg.0.log" for additional information.
[ 249.243] (EE)
[ 249.243] (II) AIGLX: Suspending AIGLX clients for VT switch
[ 249.247] (EE) Server terminated with error (1). Closing log file.
downgraded to rev 228127 of these packages all works fine again, I don't know if is only for me or not.
thanks for your repo ;-)
KF5 & Plasma5 (git versions) - Awesome WM
ASUS Sabertooth 990FX - AMD FX8350 - ATI Radeon HD 7970
[testing] repo
Offline
Hi @lordheavy with the recently update in [mesa-git] repo for the packages clang-* and llvm-* rev 228304 I had crash in my X session,
downgraded to rev 228127 of these packages all works fine again, I don't know if is only for me or not.
thanks for your repo ;-)
Don't forget to rebuild your mesa drivers when llvm-svn is updated
Offline
I am trying to play the Limbo indie game, the issue that I am facing is that while the game loads without any problem the texture of the boy is missing. It is really strange because I can move the boy, but I cannot see it. Only sometimes a small rectangle flickers in the position where the boy supposed to be. I am with mesa-git and my graphics card is a 5850 ati and if I run the game from command line I am getting the following error:
radeon: Failed to allocate a buffer:
radeon: size : 44728320 bytes
radeon: alignment : 32768 bytes
radeon: domains : 4
radeon: flags : 20
does anyone have any hint about it?
Offline
I am trying to play the Limbo indie game, the issue that I am facing is that while the game loads without any problem the texture of the boy is missing. It is really strange because I can move the boy, but I cannot see it. Only sometimes a small rectangle flickers in the position where the boy supposed to be. I am with mesa-git and my graphics card is a 5850 ati and if I run the game from command line I am getting the following error:
radeon: Failed to allocate a buffer: radeon: size : 44728320 bytes radeon: alignment : 32768 bytes radeon: domains : 4 radeon: flags : 20
does anyone have any hint about it?
No problems here (7870 -> radeonsi), you should fill a bug upstream at https://bugs.freedesktop.org
Offline
theodore wrote:I am trying to play the Limbo indie game, the issue that I am facing is that while the game loads without any problem the texture of the boy is missing. It is really strange because I can move the boy, but I cannot see it. Only sometimes a small rectangle flickers in the position where the boy supposed to be. I am with mesa-git and my graphics card is a 5850 ati and if I run the game from command line I am getting the following error:
radeon: Failed to allocate a buffer: radeon: size : 44728320 bytes radeon: alignment : 32768 bytes radeon: domains : 4 radeon: flags : 20
does anyone have any hint about it?
No problems here (7870 -> radeonsi), you should fill a bug upstream at https://bugs.freedesktop.org
thanks, done ;-)
Offline
The xf86-video-ati driver now has DRI3 support [1] [2] .
I've verified with my mesa-r git pacakges, and the build log shows -DHAVE_DRI3 as one of the macros used, so it appears mesa correctly enables DRI3 without having to specifiy it explicitly.
In order to use DRI3 you'll need to use a recent xf86-video-ati git version AND set in option in a xorg config file [2] .
LordHeavy, can you verify if your mesa-git package also enables DRI3 support now and update the xf86-video-ati-git in your repo ?
NOTE : i haven't done any testing with DRI3 yet.
[1] http://www.phoronix.com/scan.php?page=n … DX-Present
[2] http://cgit.freedesktop.org/xorg/driver … 533fa94953
Last edited by Lone_Wolf (2015-03-17 15:59:58)
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 xf86-video-ati driver now has DRI3 support [1] [2] .
I've verified with my mesa-r git pacakges, and the build log shows -DHAVE_DRI3 as one of the macros used, so it appears mesa correctly enables DRI3 without having to specifiy it explicitly.In order to use DRI3 you'll need to use a recent xf86-video-ati git version AND set in option in a xorg config file [2] .
LordHeavy, can you verify if your mesa-git package also enables DRI3 support now and update the xf86-video-ati-git in your repo ?
Yes, mesa-git is built with dri3 support, and xf86-video-ati-git package too
Offline
Is there a way to use OpenCL with the opensource driver?
Offline