You are not logged in.
ethan961 wrote:joanmanel wrote:Now with Steam and Dota2 working, my performance seems to degrade a lot over time.
It started being nice, all max, all fast. After 15 minutes more or less, FPS dropped and I had to set all to mid, and again after one hour FPS dropped and I had to set all to low.
This looks more like a driver problem than application problem.
Anyone has similar experiences?
I have the same issue, although I can usually get 2-3 games in before performance degrades. Lowering settings doesn't help though. I'm on the HD 8650G (Richland notebook APU). I'm updating to 14.1 now and if it doesn't solve the problem I'll try the radeon git drivers. Anything to ditch windows!
I've been using for the past weeks radeon git (open source drivers) and it goes perfect. I mostly play Dota2, and all max, I get more FPS with the oss than catalyst. I have an HD7770
I switched to the radeon git drivers in the end and performance is indeed better than with Catalyst. No slowdowns after a period of time, which is a big deal. Playing out the rest of a game with 10-15FPS was torture! I'm glad AMD is giving the free drivers the support they've so badly needed at least. I mainly play Source games and the exceptions I have to boot to Windows for anyways (not enough juice to run them well in Wine) so the open drivers are fine for me.
Offline
I recently bought "MSI 290X Gaming" and have this "lag" whenever I'm scrolling text in text editor or scrolling in file manager. In both KDE and GNOME3 (on Gnome it's even more painfull), no matter if compositing is enabled or disabled.
Definitelly something bad is going on with ATI's 2D Acceleration.
There's no problem with web browsers - scrolling works perfectly, also on chromium with aura (edit: I said it too early, scrolling works fine only in chromium and opera, sucks in qupzilla and firefox)
I checked 13.111, 14.1 and 14.2, tried disabling and enabling some options, nothing helped.
Can some owner of 290(X) (probably also 260X) confirm? I searched bugzilla but didn't find a tip, so I would like to report it.
Open source drivers also aren't working well with 290X - scrolling in editor or file manager is much better, yes, but it's not that well on chromium, also 3d performance is terrible...
Well... it looks like I did it again - I bought AMD hardware too quickly . I was waiting months but, just like with 7850, it was not enought. Now I would have to patently wait for a salvation ;P...
Edit: here's bug report
As for the 14.1 - I can see that I removed it from the repo too quickly... I didn't notice any problems, there should be no regression is such a small update, but if someone will confirm Jannis' problems I think I will reup 14.1 repo again (as an archive)
Last edited by Vi0L0 (2014-03-06 19:26:29)
Offline
Hey all, 'jus curous:
- Using catalyst-test ;
It's been a while since I re-installed "catalyst-test", from AUR, but has something changed ?
That is, I used to have to add "nomodeset" to the linux kernel boot-params line.
Anyway, with latest catalyst-test-14.2-1, from AUR, everything seems ok, booting and 3D in X,..., even WITHOUT this so-called required "nomodeset" ???
so what changed ? sorry,...I guess I've been under a rock lately, but has newer Kernel switching ability in Linux fixed all this ?,
and should I continue to bother with "nomodeset" ?
Thanks ahead.
--------------------------
Hardware schtuff:
-my (AMD) Desktop with RadeonHD 7750 GPU card
-catalyst-test 14.2-1 from AUR, installed via yaourt
-Linux 3.13.5-1-ARCH x86_64
Last edited by scjet (2014-03-08 02:54:25)
The "BSD" things in life are "Free", and "Open", and so is "Arch"
Offline
I have a problem with the AMD A10-7850K (the latest APU from AMD): X refuses to start and aticonfig spits out this message whenever I try to fix the problem.
aticonfig: No supported adapters detected
I am using the latest catalyst-total.
Offline
I have a problem with the AMD A10-7850K (the latest APU from AMD): X refuses to start and aticonfig spits out this message whenever I try to fix the problem.
aticonfig: No supported adapters detected
I am using the latest catalyst-total.
# modprobe fglrx
?
Asus N61J/ATi Radeon HD5730
Toshiba A200/ATi Radeon HD2600
Offline
l0vot wrote:I have a problem with the AMD A10-7850K (the latest APU from AMD): X refuses to start and aticonfig spits out this message whenever I try to fix the problem.
aticonfig: No supported adapters detected
I am using the latest catalyst-total.
# modprobe fglrx
?
The install in question was running with radeon HD 7770 graphics, then the mobo died, and I decided to experiment with APUs instead of buying another motherboard for my old-ish Athlon 2. fglrx is definately enabled and my xorg.conf was autogened by aticonfig before the switch.
Maybe I should try cping my xorg.conf from my APU laptop, maybe that would work.
Offline
I have a problem with the AMD A10-7850K (the latest APU from AMD): X refuses to start and aticonfig spits out this message whenever I try to fix the problem.
aticonfig: No supported adapters detected
I am using the latest catalyst-total.
Might be too new for AMD Catalyst for Linux.
Claire is fine.
Problems? I have dysgraphia, so clear and concise please.
My public GPG key for package signing
My x86_64 package repository
Offline
Hello everyone. Has the issue with the latest mesa upgrade been raised somewhere (libEGL.so missing. thus nothing working as expected)?
Offline
There's this thread: https://bbs.archlinux.org/viewtopic.php?id=178189
But it's more nVidia centred, for now.
I think I'll rollback to previous mesa and see what happens then.
As I said in that thread, catalyst isn't only thing affected (at least for me) both Firefox and Chromium don't work as well.
EDIT: Downgrading solved everything (for now)
Last edited by Primoz (2014-03-08 22:49:03)
Arch x86_64 ATI AMD APU KDE frameworks 5
---------------------------------
Whatever I do, I always end up with something horribly mis-configured.
Offline
I was getting the error
error while loading shared libraries: libEGL.so.1: cannot open shared object file: No such file or directory
after installing mesa 10.1.0-2 from the extra repository.
I looked at the file list for the new mesa and saw that there was now a file named "mesa-libEGL.so.1.0.0", so I used the command
sudo ln -s /usr/lib/mesa-libEGL.so.1.0.0 /usr/lib/libEGL.so.1
to link the old file name to the new one.
This may or may not be a "correct" way to do this, but it works perfectly for me.
Last edited by fiendfan1 (2014-03-08 22:56:43)
Offline
I opened the bug against nvidia-libgl yesterday that is now causing problem to catalyst users:
https://bugs.archlinux.org/task/39219
So I am aware of the issue. I wrote something about a possible "official" solution.
They renamed the libs bundled in mesa and moved their associated symlinks to mesa-libgl package.
Vi0l0 just need to add few symlinks in the next catalyst package update.
As a temporary workaround creating symlinks manually is perfect.
Last edited by lano1106 (2014-03-09 06:18:14)
Offline
Right now the only solution I could think of is to modify catalyst-utils in this way:
- add 'mesa' dependency into catalyst-utils
- in post_install() firstly check if libs (like libEGL.so) are absent, if so create symlinks like:
cd /usr/lib
ln -s mesa-libEGL.so.1.0.0 libEGL.so
ln -s mesa-libEGL.so.1.0.0 libEGL.so.1
ln -s mesa-libEGL.so.1.0.0 libEGL.so.1.0.0
ln -s mesa-libGLESv1_CM.so.1.1.0 libGLESv1_CM.so
ln -s mesa-libGLESv1_CM.so.1.1.0 libGLESv1_CM.so.1
ln -s mesa-libGLESv1_CM.so.1.1.0 libGLESv1_CM.so.1.1.0
ln -s mesa-libGLESv2.so.2.0.0 libGLESv2.so
ln -s mesa-libGLESv2.so.2.0.0 libGLESv2.so.2
ln -s mesa-libGLESv2.so.2.0.0 libGLESv2.so.2.0.0
It's imho pretty dirty, maybe someone have better idea?
If there will be no other idea I will update packages later today.
Offline
Right now the only solution I could think of is to modify catalyst-utils in this way:
- add 'mesa' dependency into catalyst-utils
- in post_install() firstly check if libs (like libEGL.so) are absent, if so create symlinks like:cd /usr/lib ln -s mesa-libEGL.so.1.0.0 libEGL.so ln -s mesa-libEGL.so.1.0.0 libEGL.so.1 ln -s mesa-libEGL.so.1.0.0 libEGL.so.1.0.0 ln -s mesa-libGLESv1_CM.so.1.1.0 libGLESv1_CM.so ln -s mesa-libGLESv1_CM.so.1.1.0 libGLESv1_CM.so.1 ln -s mesa-libGLESv1_CM.so.1.1.0 libGLESv1_CM.so.1.1.0 ln -s mesa-libGLESv2.so.2.0.0 libGLESv2.so ln -s mesa-libGLESv2.so.2.0.0 libGLESv2.so.2 ln -s mesa-libGLESv2.so.2.0.0 libGLESv2.so.2.0.0
It's imho pretty dirty, maybe someone have better idea?
If there will be no other idea I will update packages later today.
catalyst-utils needs to be split up into catalyst-libgl like the nvidia-304xx-utils package.
https://projects.archlinux.org/svntogit … 04xx-utils
The -libgl split package provides the symlinks.
Last edited by blackout23 (2014-03-09 12:50:14)
Offline
Why do you think it needs to be split?
There was no such a need before, I don't see such a need now.
Arch devs moved egl libs from mesa to mesa-libgl only because nvidia started to ship its own egl libs, and so there was the conflict.
Last edited by Vi0L0 (2014-03-09 13:31:17)
Offline
Why do you think it needs to be split?
There was no such a need before, I don't see such a need now.Arch devs moved egl libs from mesa to mesa-libgl only because nvidia started to ship its own egl libs, and so there was the conflict.
You are right you could probably just provide the symlinks in the -utils package. However a seperate -libgl package would make it more consistent with the package naming and seperation of the other video drivers.
Offline
However a seperate -libgl package would make it more consistent with the package naming and seperation of the other video drivers.
I don't see the purpose. I don't know why it was separated anyway... Probably to clarify that mesa-libgl is not the only libgl (back in the days there was a libgl package built from a mesas source).
Is there any other reason? Why was nvidia-libgl separated from nvidia-utils? What can be done with a separated nvidia-libgl package without nvidia-utils? Or from a backward: what can be done with a separated nvidia-utils package without nvidia-libgl? Is there any nvidia user with nvidia-utils installed and nvidia-libgl not installed?
mesa-libgl needs to be separated because its conflicting with blobs, but nvidia-libgl? I dunno... imho nvidia-utils which would provide libgl would be enought. But (as always) I can be wrong...
It would be easy to separate catalyst-libgl, I just don't know what for.
I never was the type of a man who's blindly following others. But just give me some logical, practical reason and I will do whatever you want. Well.. almost ;P
Last edited by Vi0L0 (2014-03-09 15:29:34)
Offline
Perhaps for now it would be sufficient to print that the symlinks may have to be created to stdout. It might save lazy mindless repo users like me from having to fiddle with surf
Offline
Right now the only solution I could think of is to modify catalyst-utils in this way:
- add 'mesa' dependency into catalyst-utils
- in post_install() firstly check if libs (like libEGL.so) are absent, if so create symlinks like:
Please don't create the symlinks in post_install() but in package() so they are included in the package and tracked by pacman.
(Assuming it's possible to do it like this and there aren't any conflicts or other issues.)
Offline
Vi0L0 wrote:Right now the only solution I could think of is to modify catalyst-utils in this way:
- add 'mesa' dependency into catalyst-utils
- in post_install() firstly check if libs (like libEGL.so) are absent, if so create symlinks like:Please don't create the symlinks in post_install() but in package() so they are included in the package and tracked by pacman.
(Assuming it's possible to do it like this and there aren't any conflicts or other issues.)
Let it be then.
Sidenote: I already wrote a simple script which would create/rebuild symlinks for any version of mesa libs - this would allow users to rebuild symlinks on their own, whenever it would be neccessary, now they would have to wait for me and my update of a package.
But as you said - the package() way is the Arch Way. Now I can see that a separate catalyst-libgl package could be helpful - because I would only have to rebuild that small one with a symlinks, not the whole big catalyst-utils. I think that I will use it.
I've updated AUR packages, sorry guys no repo update today, had no time
Will update repo tommorrow.
Last edited by Vi0L0 (2014-03-10 07:47:39)
Offline
foutrelis wrote:Vi0L0 wrote:Right now the only solution I could think of is to modify catalyst-utils in this way:
- add 'mesa' dependency into catalyst-utils
- in post_install() firstly check if libs (like libEGL.so) are absent, if so create symlinks like:Please don't create the symlinks in post_install() but in package() so they are included in the package and tracked by pacman.
(Assuming it's possible to do it like this and there aren't any conflicts or other issues.)
Let it be then.
Sidenote: I already wrote a simple script which would create/rebuild symlinks for any version of mesa libs - this would allow users to rebuild symlinks on their own, whenever it would be neccessary, now they would have to wait for me and my update of a package.
But as you said - the package() way is the Arch Way. Now I can see that a separate catalyst-libgl package could be helpful - because I would only have to rebuild that small one with a symlinks, not the whole big catalyst-utils. I think that I will use it.I've updated AUR packages, sorry guys no repo update today, had no time
Will update repo tommorrow.
Thanks Vi0L0 for all your hard work. Can confirm the latest catalyst-test 14.2-2 works with the latest mesa/lib32 packages with no symlinks needed
Last edited by okubax (2014-03-09 23:55:26)
Offline
Sidenote: I already wrote a simple script which would create/rebuild symlinks for any version of mesa libs - this would allow users to rebuild symlinks on their own, whenever it would be neccessary, now they would have to wait for me and my update of a package.
But as you said - the package() way is the Arch Way. Now I can see that a separate catalyst-libgl package could be helpful - because I would only have to rebuild that small one with a symlinks, not the whole big catalyst-utils. I think that I will use it.
I just thought that since I already wrote this script then maybe it would be good idea to add it into some package generator, with ability to create pacman's catalyst-libgl package with needed symlinks inside (maybe it would be good idea to add this generator into catalyst-libgl itself). Users would have to run the generator's script manually (automation here is not that necessary imho), but they would be able to run it whenever needed, so whenever mesa's libs version would change and keep their systems working well without a need of waiting for my update. I think that soon I will start to work on this solution.
Last edited by Vi0L0 (2014-03-10 07:49:00)
Offline
Hey there,
I'm having a problem with the oss drivers on my 7750. The color space is compressed in the dark shades of gray, that means in the values <=16 everything is just black. But that's only a problem on the HDMI output connected to my TV. It used to work with the catalyst drivers, but since kernel 3.13 has a sufficient performance I switched to the oss drivers.
I did already create a thread for this problem, but since there have been no responses that resolved my problem I'm also asking for help here.
Offline
I'm in the middle of [catalyst] update. Today I also wanna update [catalyst-stable] and [catalyst-hd234k].
Repo users should note that:
- catalyst-utils is now splitted into:
catalyst-utils
catalyst-libgl
opencl-catalyst
- lib32-catalyst-utils is now splitted into:
lib32-catalyst-utils
lib32-catalyst-libgl
lib32-opencl-catalyst
You MOST probably want to also install catalyst-libgl and (if using x86_64) lib32-catalyst-libgl
Edit: src tarballs are here:
http://catalyst.wirephire.com/tarball/1 … src.tar.gz
http://catalyst.wirephire.com/tarball/1 … src.tar.gz
Last edited by Vi0L0 (2014-03-10 20:30:15)
Offline
Now I get this error when trying to update:
error: failed to prepare transaction (could not satisfy dependencies)
:: Starting full system upgrade...
resolving dependencies...
looking for inter-conflicts...
error: failed to prepare transaction (could not satisfy dependencies)
:: amdapp-sdk: requires libcl
:: amdapp-sdk: requires libgl
:: cairo-infinality-ultimate: requires libgl
:: cgminer-gpu: requires libcl
.. etc, the full message is useless, but here it is if you want http://pastie.org/8905314 , but it goes on with simular errors about libgl, lib32-libgl.
SO I figured I'd try updating to catalyst-libgl...
:: catalyst-libgl and catalyst-utils are in conflict (libgl). Remove catalyst-utils? [y/N] y
error: failed to prepare transaction (could not satisfy dependencies)
:: catalyst-libgl: requires catalyst-utils
:: amdapp-sdk: requires libcl
:: amdoverdrivectrl: requires catalyst-utils
:: catalyst-hook: requires catalyst-utils
:: cgminer-gpu: requires libcl
:: imagemagick: requires libcl
:: lib32-catalyst-utils: requires catalyst-utils
:: xvba-video: requires catalyst-utils
Last edited by joelisntmyname (2014-03-10 20:08:25)
Offline
I'm getting the same error as joelisntmyname.
Offline