You are not logged in.
Anders H wrote:Well at least my system is booting properly so unless someone can find a "better" fix for this I'm going to just call this another one of Catalyst's "charms" for now.
Yay! I fixed it. I still has radeon in the modules section in /etc/mkinitcpio.conf. No idea why that didn't cause problems before.
So after removing it and rebuilding the initramdisk I can now boot with only the nomodeset option just fine.
*derp* That makes two of us. Thanks for the tip
Don't be bothered about the version - package on the repo was bumped to bring conflict with catalyst-dkms, there's no other difference
Figured it was something like that, hey thanks again for all the hard work you do Vi0L0
Offline
Hi,
I just noticed the efi_enabled fix in catalyst-generator 13.4-3. Was the error responsible of a noticable problem?
Yes.
On a different side note in firegl_public.c
#if defined(CONFIG_AMD_IOMMU) || defined(CONFIG_DMAR)
#define FIREGL_DMA_REMAPPING
#endifI have noticed CONFIG_DMAR does not exist anymore. It has been replaced by CONFIG_INTEL_IOMMU.
It is a bit tricky to include the fix in catalyst-generator because CONFIG_INTEL_IOMMU is defined in most kernels but it doesn't mean that the Hardware Intel IOMMU will be on.For people having a Intel chipset with VT-d. It might be worthwile to try. To enable FIREGL_DMA_REMAPPING,
1. replace CONFIG_DMAR by CONFIG_INTEL_IOMMU in firegl_public.c and rebuild the driver
2. Enable VT-d in BIOS
3. Edit kernel command line param in grub.cfg by adding 'intel_iommu=on'This could, in theory, improve DMA transfer and result into a small graphic performance boost.
Good catch. I'm unable to test it because my CPU doesn't support VT-d, but your words sounds reasonable, so I've already patched 13.4 packages @AUR with this change (hope you don't mind? )
Soon also catalyst and catalyst-stable repo will be updated with this and Krzysztof Kolasa's ttys fix.
Offline
Vi0L0,
I do not mind that you include the fix but I am worry that this is not a good default behavior because:
Even without VT-d, CONFIG_INTEL_IOMMU is defined in stock Arch Kernel for pretty much everyone.
Even if you have VT-d, DMAR will not be enabled unless you a) defined CONFIG_INTEL_IOMMU_DEFAULT_ON or use 'intel_iommu=on' on kernel command line.
That means that most fireglx users will be using the dma remapping without hardware support. Based on my tests, it is working fine but there could be negative impact.
I do have a VT-d platform. when vt-d is on and fireglx is using dma remapping, it is working as expected. I haven't done extensive benchmark to measure perf difference if any.
The only problem that I have seen is when
intel_iommu=on + fireglx dma remapping disabled = X freeze on startup.
Offline
I also didn't notice any negative performance impact after simply changing DMAR into INTEL_IOMMU in firegl_public.
Besides that not every AMD's CPU is aimed with the IOMMU, still AMD is using this option in fglrx.
+ firegl_public's preprocessor's directive is using (also defined in our kernel config) CONFIG_AMD_IOMMU as an operand of logical OR - this means that FIREGL_DMA_REMAPPING is enabled either way if i'm correct
Offline
what would be required is a runtime detection of a hardware iommu during frglx initialisation. If you let me a couple of days, I'll be able to offer you a patch.
My only remaining question is what does EFI support provide as new functionality?
I have modified the code to force its deactivation on my EFI enabled platform. I haven't noticed any difference.
IMO, disabling a useless functionnality == a good thing.
Offline
what would be required is a runtime detection of a hardware iommu during frglx initialisation. If you let me a couple of days, I'll be able to offer you a patch.
That would be awesome
My only remaining question is what does EFI support provide as new functionality?
I have modified the code to force its deactivation on my EFI enabled platform. I haven't noticed any difference.
IMO, disabling a useless functionnality == a good thing.
Cannot tell about the EFI, though my friend with nvidia card told that untill nvidia hasn't fixed its efi he wasn't able to switch to tty in any way.
If it's working like you said it seems to be useless, yes. Can someone reproduce lano1106' experiment?
Last edited by Vi0L0 (2013-05-22 09:01:15)
Offline
lano1106 wrote:what would be required is a runtime detection of a hardware iommu during frglx initialisation. If you let me a couple of days, I'll be able to offer you a patch.
That would be awesome
Vi0L0, I have explored the possibility to do that but I have given up because:
1. The easiest way would have been to check iommu_detected variable but it is not exported.
2. The whole purpose FIREGL_DMA_REMAPPING is to avoid compatibility issues between different kernel version in regards to DMA API.
Well maybe 95% of your users do have FIREGL_DMA_REMAPPING without HW iommu without problems.
The opposite patch would be, IMO, better. That is to systematically define FIREGL_DMA_REMAPPING.
When no HW iommu is present, DMA api ends up using functions in arch/x86/kernel/pci-nommu.c which are probably more robust and correct than what fglrx code is managing by itself.
That being said, I have recompiled my kernel with CONFIG_AGP=n (The last chipset with AGP support is at least 10 years old and only Intel integrated graphics still use the AGP code as a hack) and by doing so, it has broken fglrx with:
lano1106@whippet2 ~ $ dmesg | grep fglrx
[ 2.897539] fglrx: module license 'Proprietary. (C) 2002 - ATI Technologies, Starnberg, GERMANY' taints kernel.
[ 2.899186] fglrx: Unknown symbol KCL_AGP_FindCapsRegisters (err 0)
I have just moved this function outside the #if CONFIG_AGP block and it is ok to do so since it does not contain anything specific to agp. only generic pci functions.
You can get the patch at:
Offline
Vi0L0 wrote:lano1106 wrote:what would be required is a runtime detection of a hardware iommu during frglx initialisation. If you let me a couple of days, I'll be able to offer you a patch.
That would be awesome
Vi0L0, I have explored the possibility to do that but I have given up because:
1. The easiest way would have been to check iommu_detected variable but it is not exported.
2. The whole purpose FIREGL_DMA_REMAPPING is to avoid compatibility issues between different kernel version in regards to DMA API.
Well maybe 95% of your users do have FIREGL_DMA_REMAPPING without HW iommu without problems.
The opposite patch would be, IMO, better. That is to systematically define FIREGL_DMA_REMAPPING.
When no HW iommu is present, DMA api ends up using functions in arch/x86/kernel/pci-nommu.c which are probably more robust and correct than what fglrx code is managing by itself.
Yes... I can see that now...
Also (edit: when using AMD's DMA_REMAPPING) I'm guessing that the best time of checking if iommu was enabled on the system is to do it while inserting module (edit: and we aren't able to achieve that afaik). Doing this while module' build isn't the good way because, even if you will add some hack which will ie. check kernel' options in your bootloader' config, there's always some chance that user will disable or enable it with ie. mentioned kernel option.
That being said, I have recompiled my kernel with CONFIG_AGP=n (The last chipset with AGP support is at least 10 years old and only Intel integrated graphics still use the AGP code as a hack) and by doing so, it has broken fglrx with:
lano1106@whippet2 ~ $ dmesg | grep fglrx
[ 2.897539] fglrx: module license 'Proprietary. (C) 2002 - ATI Technologies, Starnberg, GERMANY' taints kernel.
[ 2.899186] fglrx: Unknown symbol KCL_AGP_FindCapsRegisters (err 0)I have just moved this function outside the #if CONFIG_AGP block and it is ok to do so since it does not contain anything specific to agp. only generic pci functions.
You can get the patch at:
Aaaah, nice job!
I've just test it and it seems to work well, soon I will add your patch.
BIG THANKS!
Last edited by Vi0L0 (2013-05-26 19:44:07)
Offline
Hey all, I recently did a full update and seem to have broken my video drivers. Had been using catalyst from the official repos with no issues. Reverted back to xorg-server 1.13, but still can't startx. A couple days of searching have not yielded anything that works for me, so I'm posting here for the first time. Maybe someone can help? Let me know if you need more info than this:
My current setup is:
linux 3.9.4-1
xorg-server 1.13.4 from wirephire repo
catalyst-generator 13.4-4 from wirephire repo (previously tried catalyst and catalyst-hook with same results)
catalyst-utils 13.4-1
xorg.conf:
Section "ServerLayout"
Identifier "aticonfig Layout"
Screen 0 "aticonfig-Screen[0]-0" 0 0
EndSection
Section "Module"
EndSection
Section "Monitor"
Identifier "aticonfig-Monitor[0]-0"
Option "VendorName" "ATI Proprietary Driver"
Option "ModelName" "Generic Autodetecting Monitor"
Option "DPMS" "true"
EndSection
Section "Device"
Identifier "aticonfig-Device[0]-0"
Driver "fglrx"
BusID "PCI:0:1:0"
EndSection
Section "Screen"
Identifier "aticonfig-Screen[0]-0"
Device "aticonfig-Device[0]-0"
Monitor "aticonfig-Monitor[0]-0"
DefaultDepth 24
SubSection "Display"
Viewport 0 0
Depth 24
EndSubSection
EndSection
Xorg.0.log:
[ 783.046]
X.Org X Server 1.13.4
Release Date: 2013-04-17
[ 783.050] X Protocol Version 11, Revision 0
[ 783.051] Build Operating System: Linux 3.8.10-1-ARCH x86_64
[ 783.052] Current Operating System: Linux archiso 3.7.5-1-ARCH #1 SMP PREEMPT Mon Jan 28 10:03:32 CET 2013 x86_64
[ 783.052] Kernel command line: archisobasedir=arch archisolabel=ARCH_201302 initrd=boot/x86_64/archiso.img BOOT_IMAGE=boot/x86_64/vmlinuz
[ 783.055] Build Date: 28 April 2013 01:19:17PM
[ 783.056]
[ 783.058] Current version of pixman: 0.30.0
[ 783.061] Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[ 783.061] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 783.066] (==) Log file: "/var/log/Xorg.0.log", Time: Tue May 28 09:35:45 2013
[ 783.068] (==) Using config file: "/etc/X11/xorg.conf"
[ 783.069] (==) Using config directory: "/etc/X11/xorg.conf.d"
[ 783.069] (==) ServerLayout "aticonfig Layout"
[ 783.069] (**) |-->Screen "aticonfig-Screen[0]-0" (0)
[ 783.069] (**) | |-->Monitor "aticonfig-Monitor[0]-0"
[ 783.069] (**) | |-->Device "aticonfig-Device[0]-0"
[ 783.069] (==) Automatically adding devices
[ 783.069] (==) Automatically enabling devices
[ 783.069] (==) Automatically adding GPU devices
[ 783.069] (WW) The directory "/usr/share/fonts/OTF/" does not exist.
[ 783.069] Entry deleted from font path.
[ 783.069] (WW) The directory "/usr/share/fonts/Type1/" does not exist.
[ 783.069] Entry deleted from font path.
[ 783.069] (WW) `fonts.dir' not found (or not valid) in "/usr/share/fonts/100dpi/".
[ 783.069] Entry deleted from font path.
[ 783.069] (Run 'mkfontdir' on "/usr/share/fonts/100dpi/").
[ 783.069] (WW) `fonts.dir' not found (or not valid) in "/usr/share/fonts/75dpi/".
[ 783.069] Entry deleted from font path.
[ 783.069] (Run 'mkfontdir' on "/usr/share/fonts/75dpi/").
[ 783.069] (==) FontPath set to:
/usr/share/fonts/misc/,
/usr/share/fonts/TTF/
[ 783.069] (==) ModulePath set to "/usr/lib/xorg/modules"
[ 783.069] (II) The server relies on udev to provide the list of input devices.
If no devices become available, reconfigure udev or disable AutoAddDevices.
[ 783.069] (II) Loader magic: 0x7fbc20
[ 783.069] (II) Module ABI versions:
[ 783.070] X.Org ANSI C Emulation: 0.4
[ 783.070] X.Org Video Driver: 13.1
[ 783.070] X.Org XInput driver : 18.0
[ 783.070] X.Org Server Extension : 7.0
[ 783.070] (II) config/udev: Adding drm device (/dev/dri/card0)
[ 783.071] (--) PCI:*(0:0:1:0) 1002:9644:1849:9640 rev 0, Mem @ 0xc0000000/268435456, 0xfef00000/262144, I/O @ 0x0000f000/256
[ 783.072] Initializing built-in extension Generic Event Extension
[ 783.074] Initializing built-in extension SHAPE
[ 783.075] Initializing built-in extension MIT-SHM
[ 783.076] Initializing built-in extension XInputExtension
[ 783.078] Initializing built-in extension XTEST
[ 783.079] Initializing built-in extension BIG-REQUESTS
[ 783.080] Initializing built-in extension SYNC
[ 783.081] Initializing built-in extension XKEYBOARD
[ 783.083] Initializing built-in extension XC-MISC
[ 783.084] Initializing built-in extension SECURITY
[ 783.085] Initializing built-in extension XINERAMA
[ 783.086] Initializing built-in extension XFIXES
[ 783.087] Initializing built-in extension RENDER
[ 783.089] Initializing built-in extension RANDR
[ 783.090] Initializing built-in extension COMPOSITE
[ 783.091] Initializing built-in extension DAMAGE
[ 783.092] Initializing built-in extension MIT-SCREEN-SAVER
[ 783.093] Initializing built-in extension DOUBLE-BUFFER
[ 783.094] Initializing built-in extension RECORD
[ 783.096] Initializing built-in extension DPMS
[ 783.097] Initializing built-in extension X-Resource
[ 783.098] Initializing built-in extension XVideo
[ 783.099] Initializing built-in extension XVideo-MotionCompensation
[ 783.100] Initializing built-in extension XFree86-VidModeExtension
[ 783.102] Initializing built-in extension XFree86-DGA
[ 783.103] Initializing built-in extension XFree86-DRI
[ 783.104] Initializing built-in extension DRI2
[ 783.104] (II) "glx" will be loaded by default.
[ 783.104] (II) LoadModule: "glx"
[ 783.104] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[ 783.105] (II) Module glx: vendor="Advanced Micro Devices, Inc."
[ 783.105] compiled for 6.9.0, module version = 1.0.0
[ 783.106] Loading extension GLX
[ 783.106] (II) LoadModule: "fglrx"
[ 783.106] (II) Loading /usr/lib/xorg/modules/drivers/fglrx_drv.so
[ 783.121] (II) Module fglrx: vendor="FireGL - AMD Technologies Inc."
[ 783.121] compiled for 1.4.99.906, module version = 12.10.5
[ 783.121] Module class: X.Org Video Driver
[ 783.121] (II) Loading sub module "fglrxdrm"
[ 783.121] (II) LoadModule: "fglrxdrm"
[ 783.121] (II) Loading /usr/lib/xorg/modules/linux/libfglrxdrm.so
[ 783.121] (II) Module fglrxdrm: vendor="FireGL - AMD Technologies Inc."
[ 783.121] compiled for 1.4.99.906, module version = 12.10.5
[ 783.121] (II) AMD Proprietary Linux Driver Version Identifier:12.10.05
[ 783.121] (II) AMD Proprietary Linux Driver Release Identifier: 12.104
[ 783.121] (II) AMD Proprietary Linux Driver Build Date: Mar 28 2013 21:07:25
[ 783.121] (++) using VT number 1
[ 783.122] (WW) Falling back to old probe method for fglrx
[ 783.127] (II) Loading PCS database from /etc/ati/amdpcsdb /etc/ati/amdpcsdb.default
[ 783.129] ukiDynamicMajor: failed to open /proc/ati/major
[ 783.129] ukiDynamicMajor: failed to open /proc/ati/major
[ 783.132] (--) Chipset Supported AMD Graphics Processor (0x9644) found
[ 783.132] (WW) fglrx: No matching Device section for instance (BusID PCI:0@0:1:1) found
[ 783.133] (II) AMD Video driver is running on a device belonging to a group targeted for this release
[ 783.134] (II) AMD Video driver is signed
[ 783.135] (II) fglrx(0): pEnt->device->identifier=0xc69200
[ 783.135] (II) fglrx(0): === [xdl_xs113_atiddxPreInit] === begin
[ 783.135] (**) fglrx(0): Depth 24, (--) framebuffer bpp 32
[ 783.135] (II) fglrx(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps)
[ 783.135] (==) fglrx(0): Default visual is TrueColor
[ 783.135] (**) fglrx(0): Option "DPMS" "true"
[ 783.136] (==) fglrx(0): RGB weight 888
[ 783.136] (II) fglrx(0): Using 8 bits per RGB
[ 783.136] (==) fglrx(0): Buffer Tiling is ON
[ 783.136] (II) Loading sub module "fglrxdrm"
[ 783.136] (II) LoadModule: "fglrxdrm"
[ 783.136] (II) Loading /usr/lib/xorg/modules/linux/libfglrxdrm.so
[ 783.136] (II) Module fglrxdrm: vendor="FireGL - AMD Technologies Inc."
[ 783.136] compiled for 1.4.99.906, module version = 12.10.5
[ 783.138] ukiDynamicMajor: failed to open /proc/ati/major
[ 783.138] ukiDynamicMajor: failed to open /proc/ati/major
[ 783.138] (**) fglrx(0): NoAccel = NO
[ 783.138] (**) fglrx(0): AMD 2D Acceleration Architecture enabled
[ 783.138] (--) fglrx(0): Chipset: "AMD Radeon HD 6410D" (Chipset = 0x9644)
[ 783.138] (--) fglrx(0): (PciSubVendor = 0x1849, PciSubDevice = 0x9640)
[ 783.138] (==) fglrx(0): board vendor info: third party graphics adapter - NOT original AMD
[ 783.138] (--) fglrx(0): Linear framebuffer (phys) at 0xc0000000
[ 783.138] (--) fglrx(0): MMIO registers at 0xfef00000
[ 783.138] (--) fglrx(0): I/O port at 0x0000f000
[ 783.138] (==) fglrx(0): ROM-BIOS at 0x000c0000
[ 783.158] (II) fglrx(0): Invalid ATI BIOS from int10, the adapter is not VGA-enabled
[ 783.159] (EE) fglrx(0): Invalid video BIOS signature!
[ 783.159] (EE) fglrx(0): GetBIOSParameter failed
[ 783.159] (EE) fglrx(0): PreInitAdapter failed
[ 783.159] (EE) fglrx(0): PreInit failed
[ 783.159] (II) fglrx(0): === [xdl_xs113_atiddxPreInit] === end
[ 783.160] (II) UnloadModule: "fglrx"
[ 783.160] (II) UnloadSubModule: "fglrxdrm"
[ 783.160] (II) Unloading fglrxdrm
[ 783.160] (II) UnloadSubModule: "fglrxdrm"
[ 783.160] (EE) Screen(s) found, but none have a usable configuration.
[ 783.160]
Fatal server error:
[ 783.160] no screens found
[ 783.160] (EE)
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
[ 783.160] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[ 783.160] (EE)
[ 783.179] Server terminated with error (1). Closing log file.
Thanks!
Brian
Offline
Brian,
the problem seems to be this:
[ 783.158] (II) fglrx(0): Invalid ATI BIOS from int10, the adapter is not VGA-enabled
[ 783.159] (EE) fglrx(0): Invalid video BIOS signature!
[ 783.159] (EE) fglrx(0): GetBIOSParameter failed
[ 783.159] (EE) fglrx(0): PreInitAdapter failed
[ 783.159] (EE) fglrx(0): PreInit failed
What was the original catalyst version that you were using before the upgrade? That sounds like AMD added a new feature that is 'validate video bios' before proceeding.
Maybe there is other options but I see at least 2 obvious ones:
1. Look on the manufacturer website for firmware update for your card or
2. Rollback to previous catalyst version.
Forgot to mention but there is this nice /proc file to figure out more info about your card BIOS:
lano1106@whippet2 /proc/ati/0 $ cat biosversion
BIOS_CREATION_DATE="09/26/12 04:40"
BIOS_MSG="Tahiti B0 XT GDDR5 3GB 500e/150m "
BIOS_KIT_VERSION="BK-AMD VER015.025.000.099.000000"
BIOS_PN="113-2104XTHY-OS1"
Last edited by lano1106 (2013-05-28 04:24:04)
Offline
@thatwasbrillian
Try
aticonfig --initial --adapter=all
@Vi0L0@
http://support.amd.com/us/kbarticles/Pa … river.aspx
Last edited by MadNoob (2013-05-28 21:39:46)
Offline
Catalyst 13.6 beta with xorg-server 1.14 support and many bugfixes, please get this into the repo asap. :-) (because the 13.4 driver stinks)
Offline
Indeed, I'm curious how it performs.
If you can't sit by a cozy fire with your code in hand enjoying its simplicity and clarity, it needs more work. --Carlos Torres
Offline
Thanks for helping. I flashed the latest BIOS, but I think the real problem was that I was working in chroot off of a live CD, and thus actually running an older kernel? Being a noob, I didn't know another way to get to a command prompt. But after lowering the runlevel in GRUB and booting straight into my actual system, I was able to rebuild the fglrx module and get a basic GUI with startx. Now I get a blank screen when booting normally, but that's probably an unrelated issue. I'll look into it and post another update.
Offline
Thanks! I will update as soon as I get back home - around ~10 hours.
edit: one more interesting fix in this release:
Fix tearing for some OpenGL applications with VSYNC on or off
... wondering how did they fix tearing when vsync is disabled, lol
Last edited by Vi0L0 (2013-05-29 07:10:09)
Offline
Can't wait to see what this one is going to bring. 13.4 was so bad performance wise, but there are so many little graphical improvements listed since 13.3 beta, and 13.4 didn't have that pesky unsupported watermark (aticonfig finally recognizes my card again).
I hope 13.6 manages better performance. Can I dump the xorg113 repository too?
Offline
Can I dump the xorg113 repository too?
Probably, AMD lists Xorg 1.14 support for this driver.
If you can't sit by a cozy fire with your code in hand enjoying its simplicity and clarity, it needs more work. --Carlos Torres
Offline
Works fine here with Xorg 1.14.1.
Had to remove the "Testing Use Only" watermark manually.
Offline
Can't wait for it to hit the repo...
Offline
Shouldn't take too long, just need to modify 3.10 patch, test it, pack and upload
I'm having some problems with 13.6 performance.
KDE's minimize and cube effects slowed down much (only sometimes it's working well - for now I don't know why). Disabling direct rendering isn't helping, tear-free and vsync neither.
Hell... even warsow (tested on tear free and KDE with effects enabled only) is sometimes (not on every session) slowing down below 60fps, i mean much below like 40...
Also GNOME3 slowed down...
Because of this i decided to use kolasa's and lano1106's patches only on catalyst-generator - so we could say on bugzilla that we are using vanilla's catalyst driver ...
BTW: AMD has fixed efi/tty with this release, so we don't need a patch for this anymore
Also - since this is a beta release I will update "only" catalyst-test@AUR and [catalyst] repo.
[catalyst-stable] will stay untouched, with 13.4 inside
Last edited by Vi0L0 (2013-05-29 19:18:28)
Offline
I can confirm poor performance on 13.6. On 13.3 beta repo this morning, games and desktop performance were fluid and snappy. Updated to 13.6 with Xorg 1.14 on Catalyst-test, now the desktop seems sluggish and glitchy (gnome3, KDE, XFCE, even noncompositing graphics like openbox seem sluggish), and in games, movement lags behind input by a second or so (move the mouse, the player onscreen moves after a halfsecond delay, Minecraft, Counter Strike, Team Fortress all show this issue).
This really is disappointing stuff. Let's hope it's a work in progress toward something better.
Offline
No FPS drop for me with 13.6!
Xfce + Kernel 3.9.4 + AMD LLano APU 6620G + 6470
It seems good.
PS: Still having brightness bug.
Offline
Since Gnome 3.8.2 stopped working and I added the gnome-catalyst repository, things have been really slow. For example if I click on a menu sometimes the menu shadow will appear half a second before the actual menu does. Steam in particular has been bugging out like this, but generally everything was slow, especially popping in and out of the activities overview.
Just upgraded to 13.6 and it's much the same, except this time menus work normally, at least in everything but Firefox. In Firefox if you try to use a menu, the whole app freezes up for a good 10 seconds before it appears, if you try to use a submenu the same thing will happen, but the menu won't show up.
I'm guessing that this likely has something to do with the changes made in the gnome-catalyst repo as well as the drivers, as 13.4 with Gnome 3.8.1 was perfectly smooth.
Offline
Concerning the performance issue, there is something disgusting that I have discovered. X catalyst drivers seems to rewrite from scratch amdpcsdb several times every time a mesa application is started and read the 3 bytes file atiapfxx.blb. All I did during the strace session is calling glxinfo. See by yourself what has happened:
lano1106@whippet2 ~ $ su
Password:
whippet2 /home/lano1106 # ps -ef | grep X
lano1106 640 617 0 22:28 tty1 00:00:00 xinit /etc/xdg/xfce4/xinitrc -- /etc/X11/xinit/xserverrc
root 641 640 0 22:28 ? 00:00:02 /usr/bin/X -nolisten tcp :0 vt1
root 2965 2957 0 23:31 pts/2 00:00:00 grep --color=auto X
whippet2 /home/lano1106 # strace -p641 -o/tmp/x_strace2.txt
Process 641 attached
^CProcess 641 detached
whippet2 /home/lano1106 # grep amdpcsdb /tmp/x_strace2.txt
open("/etc/ati/amdpcsdb", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 35
open("/etc/ati/amdpcsdb", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 35
open("/etc/ati/amdpcsdb", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 35
open("/etc/ati/amdpcsdb", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 35
open("/etc/ati/amdpcsdb", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 35
open("/etc/ati/amdpcsdb", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 35
open("/etc/ati/amdpcsdb", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 35
open("/etc/ati/amdpcsdb", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 35
open("/etc/ati/amdpcsdb", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 35
open("/etc/ati/amdpcsdb", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 35
open("/etc/ati/amdpcsdb", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 35
open("/etc/ati/amdpcsdb", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 35
open("/etc/ati/amdpcsdb", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 35
open("/etc/ati/amdpcsdb", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 35
open("/etc/ati/amdpcsdb", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 35
open("/etc/ati/amdpcsdb", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 35
open("/etc/ati/amdpcsdb", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 35
open("/etc/ati/amdpcsdb", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 35
open("/etc/ati/amdpcsdb", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 35
open("/etc/ati/amdpcsdb", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 35
open("/etc/ati/amdpcsdb", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 35
open("/etc/ati/amdpcsdb", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 35
open("/etc/ati/amdpcsdb", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 35
open("/etc/ati/amdpcsdb", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 35
open("/etc/ati/amdpcsdb", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 35
whippet2 /home/lano1106 # grep atiapfxx.blb /tmp/x_strace2.txt
open("/etc/ati/atiapfxx.blb", O_RDONLY) = 35
open("/etc/ati/atiapfxx.blb", O_RDONLY) = 35
open("/etc/ati/atiapfxx.blb", O_RDONLY) = 35
open("/etc/ati/atiapfxx.blb", O_RDONLY) = 35
open("/etc/ati/atiapfxx.blb", O_RDONLY) = 35
open("/etc/ati/atiapfxx.blb", O_RDONLY) = 35
open("/etc/ati/atiapfxx.blb", O_RDONLY) = 35
open("/etc/ati/atiapfxx.blb", O_RDONLY) = 35
open("/etc/ati/atiapfxx.blb", O_RDONLY) = 35
open("/etc/ati/atiapfxx.blb", O_RDONLY) = 35
open("/etc/ati/atiapfxx.blb", O_RDONLY) = 35
open("/etc/ati/atiapfxx.blb", O_RDONLY) = 35
open("/etc/ati/atiapfxx.blb", O_RDONLY) = 35
open("/etc/ati/atiapfxx.blb", O_RDONLY) = 35
open("/etc/ati/atiapfxx.blb", O_RDONLY) = 35
open("/etc/ati/atiapfxx.blb", O_RDONLY) = 35
open("/etc/ati/atiapfxx.blb", O_RDONLY) = 35
open("/etc/ati/atiapfxx.blb", O_RDONLY) = 35
open("/etc/ati/atiapfxx.blb", O_RDONLY) = 35
open("/etc/ati/atiapfxx.blb", O_RDONLY) = 35
open("/etc/ati/atiapfxx.blb", O_RDONLY) = 35
open("/etc/ati/atiapfxx.blb", O_RDONLY) = 35
open("/etc/ati/atiapfxx.blb", O_RDONLY) = 35
open("/etc/ati/atiapfxx.blb", O_RDONLY) = 35
psychoticmeow, you should strace X server and open a menu. If you have as much or more config file rewrite, it could in part explain the slowness that you experience.
Say goodbye to your SSD lifespan :-)
Last edited by lano1106 (2013-05-30 04:13:49)
Offline
I'm guessing that this likely has something to do with the changes made in the gnome-catalyst repo as well as the drivers, as 13.4 with Gnome 3.8.1 was perfectly smooth.
You mean "changes made by gnome-catalyst repo"? Because I didn't update this repo. There's something in GNOME 3.8.2 which prevent it from work with catalyst if only it's compiled with wayland and egl-backend support enabled. [gnome-catalyst] only contains 3.8.2 packages compiled without mentioned support. It's possible that the best way here would be to perform complete (or partial) downgrade to 3.8.1.
@lano1106:
nice investigation!
Just a couple of notes:
catalyst seems to change only one thing in amdpcsdb, it's increasing the value of AplReloadCounter whenever you will open new opengl app - it's changing this file only once per app. (edit: just checked - 13.4 behaves in same way)
13.6 came up with only 3 new (binary) files (all in /etc/ati): atiapfxx atiapfxx.blb and atiapfxx.log.
Yes, the driver is opening atiapfxx.blb, but it's not modyfing it.
Yes, the amount of open operations on those files stinks...
edit: also iirc read operations aren't that bad for ssds, it's write that is eating them (could be wrong though)
I've performed a simple test:
- stop kdm
- removed all atiapfxx* files
- chmod 444 amdpcsdb
- start kdm
amdpcsdb is now read-only and catalyst isn't rewrtiting it. But nothing else has changed also in a matter of performance
Looks like this driver is simply aimed to the APUs owners, till now I haven't seen any positive reviews from other users.
Last edited by Vi0L0 (2013-05-30 10:48:32)
Offline