bad performance (youtube, vlc, mplayer)

Message

broli · Post by **broli** » Mon Jun 23, 2014 11:10 pm

hi all.
i have this performance issue for a long time, but i was to lazy and didnt had much time to look at it
when watching a youtube video, or any video with mplayer or vlc, the video "stutters"
sound is ok, while the video stops, and then jumps to catch up with the sound (i thin its dropping frames)
this happens with crappy 240x videos, as well as full HD

also, glxgears shows a really low FPS (i would assume my hardware is capable of a bunch more)

Code: Select all

Opteron log # glxgears 
276 frames in 5.0 seconds = 55.136 FPS
277 frames in 5.0 seconds = 55.352 FPS

i have the following related hardware
CPU AMD Phenom(tm) II X6 1090T Processor
GPU [AMD/ATI] Juniper PRO [Radeon HD 6750]

i have installed the closed source drivers
x11-drivers/ati-drivers
Installed versions: 14.4_p1(1)^td(21:26:17 06/04/14)(modules multilib qt4 -debug -pax_kernel -static-libs KERNEL="linux")

and my kernel is sys-kernel/gentoo-sources-3.12.20 compiled trough genkernel
this is an amd64 installation

after searching for a while, trying a few things, making sure everything is configured as wikis or post said, i have narrowed down this to 2 possibilities (wich might be completely wrong XD)
1) the only error i see in any log in /var/log that might be related is this one

Code: Select all

Opteron /var/log # grep -i error Xorg.0.log
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[    33.353] (EE) AIGLX error: failed to open /usr/X11R6/lib64/modules/dri/fglrx_dri.so, error[/usr/X11R6/lib64/modules/dri/fglrx_dri.so: cannot open shared object file: No such file or directory]

dont know if its related,since X starts. so im assuming the module is beeing loaded from somewhere else?

Code: Select all

Opteron log # glxinfo | grep direct
direct rendering: Yes

2) permissions of /dev/ati/card0

Code: Select all

Opteron ~ # getfacl /dev/ati/card0 
getfacl: Removing leading '/' from absolute path names
# file: dev/ati/card0
# owner: root
# group: root
user::rw-
group::rw-
other::rw-

i read this in the gentoo wiki.
manually changing the group to video is not permanent, so i have to test with the system already on. if i reboot it reverts back, thats why i cant be completely sure this solves o not my problem, because i think something thats already runing might not benefit from the permissions change

i do have some other issues, like "input lag" while typing, for example, this post. but since its in X, i assume is related. merging software from the command line works like a charm.

here is some extra info that might be needed
glxinfo http://bpaste.net/show/401247/
current kernel config (from genkernel) http://bpaste.net/show/RBGrCdepglZCDYbj0uwT/
xorg.conf http://bpaste.net/show/nswBLGtn5Eoyim5j0LTs/
emerge --info http://bpaste.net/show/fYlSjjGOT1nuIzMxsUEV/

thanks for reading and dont hesitate to ask for all the info im surely forgetting

regards

eccerr0r · Post by **eccerr0r** » Mon Jun 23, 2014 11:32 pm

It's amazing that it actually tries to get X going no matter how bad your setup is setup... Xorg will tend to fallback to other drivers if you have them installed.

Code: Select all

[    33.353] (EE) AIGLX error: failed to open /usr/X11R6/lib64/modules/dri/fglrx_dri.so, error[/usr/X11R6/lib64/modules/dri/fglrx_dri.so: cannot open shared object file: No such file or directory]

is probably your best bet. Do you have VIDEO_CARDS setup with "fglrx" in your make.conf and have all dependencies cleaned up? Try emerge -1 ati-drivers once more to make sure it's up to date.

Also, after re-emerging ati-drivers and anything else stale, run

eselect opengl list

and make sure that it's pointing to fglrx's opengl (e.g. eselect opengl set 2 # or whatever number it is on your list.)

broli · Post by **broli** » Tue Jun 24, 2014 12:34 am

i have the video cards variable set

Code: Select all

Opteron ~ # grep VIDEO_CARDS /etc/portage/make.conf
VIDEO_CARDS="fglrx"

i have re emerged the ati drivers and i still get the same issue

and ati is the selected option

Code: Select all

Available OpenGL implementations:
  [1]   ati *
  [2]   xorg-x11

also, here is the complete Xorg.log http://bpaste.net/show/6fPGzDHFTjtVOZcU9Zrl/

still having the same issue

russK · Post by **russK** » Tue Jun 24, 2014 3:17 am

I have had the same issue that you mentioned with input lag, which I'm sorry to say I don't remember exactly how I fixed it, but I see you have:

Code: Select all

CONFIG_PREEMPT_NONE=y

I have CONFIG_PREEMPT_VOLUNTARY=y, so you might try rebuilding the kernel after changing:

menuconfig -> Processor type and features -> Preemption Model -> Voluntary Kernel Preemption (Desktop)

HTH

broli · Post by **broli** » Tue Jun 24, 2014 4:10 am

tried changing that option in my kernel, but the problem persists

russK · Post by **russK** » Tue Jun 24, 2014 5:13 am

Should you have VIDEO_CARDS="radeon r600" ? I followed this wiki page when I set up a kabini motherboard: http://wiki.gentoo.org/wiki/Radeon

So in the course of following that, I emerged linux-firmware and added the options under Generic Driver to end up with:

Code: Select all

CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE="rtl_nic/rtl8168g-1.fw rtl_nic/rtl8168g-2.fw rtl_nic/rtl8168g-3.fw radeon/BONAIRE_uvd.bin radeon/KABINI_mec.bin radeon/KABINI_sdma.bin radeon/KABINI_ce.bin radeon/KABINI_pfp.bin radeon/KABINI_me.bin radeon/KABINI_rlc.bin"
CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"

I'm not exactly sure which would be right in your case, it looks like maybe some kind of EVERGREEN.

szatox · Post by **szatox** » Tue Jun 24, 2014 11:07 am

Opteron log # glxinfo | grep direct
direct rendering: Yes

Mistake spotted. Use `grep render` instead of `grep direct`
Direct rendering: yes means nothing those days. You want to see what is really used for rendering and then make a guess if it's HW accelerated

Also, glxgears attemps to sync with your display by default. You can disable this behaviour with some environmental variable. Unfortunately I don't remember it's name.
Finaly, every time you recompile your kernel you must also recbuild ati drivers.

broli · Post by **broli** » Tue Jun 24, 2014 12:23 pm

rusk, those instrucctioms are for the open source driver, and im using the closed source ones

it appears i have hardware rendering

Code: Select all

Opteron ~ # glxinfo | grep -i render               
direct rendering: Yes
OpenGL renderer string: AMD Radeon HD 6700 Series   
    GL_KTX_buffer_region, GL_NV_blend_square, GL_NV_conditional_render, 
    GL_KTX_buffer_region, GL_NV_blend_square, GL_NV_conditional_render,

i always re emerge the ati module after i rebuild my kernel

i googled some about vsync and glxgears, and aparently is not my case.

Code: Select all

carlos@Opteron ~ $ glxgears -info
GL_RENDERER   = AMD Radeon HD 6700 Series   
GL_VERSION    = 4.4.12874 Compatibility Profile Context 12.104
GL_VENDOR     = ATI Technologies Inc.

if it was vsyncyng, i should see a message there saying Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate.

also tried with like this, forcing the vsync off, and got the same results

Code: Select all

carlos@Opteron ~ $ vblank_mode=0 glxgears
244 frames in 5.0 seconds = 48.688 FPS

eccerr0r · Post by **eccerr0r** » Tue Jun 24, 2014 1:52 pm

Now that I am looking at my own, working fglrx box (RadeonHD 5770) I see that

Code: Select all

[     4.418] (EE) AIGLX error: failed to open /usr/X11R6/lib64/modules/dri/fglrx_dri.so, error[/usr/X11R6/lib64/modules/dri/fglrx_dri.so: cannot open shared object file: No such file or directory]

is "normal" or not necessary to work properly:

Code: Select all

fujiko /var/log $ glxgears
39593 frames in 5.0 seconds = 7918.444 FPS
39578 frames in 5.0 seconds = 7915.591 FPS

I'm using x11-drivers/ati-drivers-14.6_beta1 - and I forgot why I keyworded and using this version.

Mystery continues...

broli · Post by **broli** » Tue Jun 24, 2014 2:08 pm

yeap. a mistery
it should work, it just dosnt

im completly lost

eccerr0r · Post by **eccerr0r** » Tue Jun 24, 2014 5:03 pm

You may want to try to re-emerge xorg-server and mesa (or world if brave) - may not solve the problem but could clear up some of the dependencies...

broli · Post by **broli** » Tue Jun 24, 2014 8:05 pm

i have re emerged @world, and specific packages several times now.
i have had this problem for months.
i have tried going to newer kernels, or ATI drivers, or both, googling suposedly working combos

and the problem persists

dachschaden · Post by **dachschaden** » Wed Jun 25, 2014 9:17 am

Code: Select all

[    33.558] (--) fglrx(0): Chipset: "AMD Radeon HD 6700 Series   " (Chipset = 0x68bf)
[    33.558] (--) fglrx(0): (PciSubVendor = 0x1682, PciSubDevice = 0x3142)
[    33.558] (==) fglrx(0): board vendor info: third party graphics adapter - NOT original AMD

The fuck?

Code: Select all

[    33.588] (II) Loading sub module "vbe"
[    33.588] (II) LoadModule: "vbe"
[    33.613] (II) Loading /usr/lib64/xorg/modules/libvbe.so
[    33.651] (II) Module vbe: vendor="X.Org Foundation"
[    33.651] 	compiled for 1.15.0, module version = 1.1.0
[    33.651] 	ABI class: X.Org Video Driver, version 15.0
[    33.652] (II) fglrx(0): VESA BIOS detected
[    33.652] (II) fglrx(0): VESA VBE Version 3.0
[    33.652] (II) fglrx(0): VESA VBE Total Mem: 16384 kB
[    33.652] (II) fglrx(0): VESA VBE OEM: ATI ATOMBIOS
[    33.652] (II) fglrx(0): VESA VBE OEM Software Rev: 12.20
[    33.652] (II) fglrx(0): VESA VBE OEM Vendor: (C) 1988-2005, ATI Technologies Inc. 
[    33.652] (II) fglrx(0): VESA VBE OEM Product: 
[    33.652] (II) fglrx(0): VESA VBE OEM Product Rev: 01.00
[    33.652] (II) fglrx(0): AMD Video BIOS revision 9 or later detected
[    33.652] (--) fglrx(0): Video RAM: 1048576 kByte, Type: GDDR5
[    33.653] (II) fglrx(0): PCIE card detected
[    33.653] (--) fglrx(0): Using per-process page tables (PPPT) as GART.
[    33.653] (WW) fglrx(0): board is an unknown third party board, chipset is supported
[    33.653] (II) fglrx(0): [FB] MC range(MCFBBase = 0xf00000000, MCFBSize = 0x40000000)
[    33.653] (II) fglrx(0): RandR 1.2 support is enabled!
[    33.653] (II) fglrx(0): RandR 1.2 rotation support is enabled!

I do not own the hardware, and it's a rather blind shot ... but maybe the VESA/VBE drivers are messing things up because the dri module for your fglrx driver wasn't found? I once had that problem on Kali - my Xorg was two years old (yours's not, clearly) and Haswell was too new for it, so Xorg wouldn't use the intel driver, but rather the VESA one. And that one is really slow.

On the other hand, you got glxgears running. That program depends on a OpenGL implementation, whether it's done in software or hardware. I don't know about whether or not VESA get's shipped with software OpenGL.

Also "/usr/X11R6/lib64/modules/dri/fglrx_dri.so" is an ... uncommon path for an Xorg driver, at least for me. Maybe fglrx_dri.so got installed in the wrong directory?

Code: Select all

sudo find / -name fglrx_dri.so

If you found that file, try to create a symlink to /usr/X11R6/lib64/modules/dri/fglrx_dri.so from it, and try to restart X.
If that doesn't help ... you should do some googleing about the file.

EDIT:

In the long run, I'd say it's a driver problem ... as always with AMD. But what would you expect from these guys? http://lwn.net/Articles/248227/

The rest will have to be written; freeing of the existing binary-only driver is not in the cards, and "that is better for everybody."

Ouch!

Second EDIT:
Just saw your Xorg.conf - so you have already nailed the device to fglrx ...
Then I wonder why it loads all the VESA and VBE stuff in.

szatox · Post by **szatox** » Wed Jun 25, 2014 10:22 am

Well... maybe it would be a good idea to run some livecd then and test performance there? If it should work but doesn't, maybe it's a hardware issue?
Renderer string looks fine though.
Also, 3.12.20 was masked in portage like a few days after it was added, so I suppose it's a good idea to try with new kernel.
Well, with 3.12.21-r1 ati drivers don't work for me a all, but then it might be a side effect from reusing .config from older kernel.

dachschaden · Post by **dachschaden** » Wed Jun 25, 2014 10:35 am

szatox: make oldconfig with the older .config in the current directory should do the trick.
But it would surprise me - the minor version increments suggest that these are bugs and security fixes, the config file shouldn't change here.

szatox · Post by **szatox** » Wed Jun 25, 2014 12:40 pm

Oh, that's what i did, I used working config from 3.12.20 to build 3.12.21-r1, and you're right old config should work, but it doesn't, so either there was some change (and I will get it work again once I purge old config and change defaults manually again) or we have regression here.

broli · Post by **broli** » Wed Jun 25, 2014 11:00 pm

whats all the "VESA and VBE stuff" and how do i disable it?
never heard o it before....

its in the kernel?

also, i found that so, will try and do that symlink and see i it helps somehow

Code: Select all

carlos@Opteron ~ $ locate -i fglrx_dri.so 
/usr/lib32/dri/fglrx_dri.so
/usr/lib64/dri/fglrx_dri.so

EDIT: nope. doing the symlink made it worse.
there was no error in xorg.log, but everithing was slower. even glxgears was incredible slow

dachschaden · Post by **dachschaden** » Thu Jun 26, 2014 9:03 am

http://en.wikipedia.org/wiki/VESA
http://en.wikipedia.org/wiki/VESA_BIOS_Extensions

Basically all (VESA-compatible) graphic cards support a basic interface to access the card - simple manipulation of the frame buffer, to be particular. And "basic" means basic.
Usually 3D stuff and Pixek Shader and CUDA and whatever is hardly supported by VESA, so it's done in software - that is, ultra-slow and consuming lots of CPU time. Ironically 2D is sometimes better done in software and then just send to the frame buffer, because hardware rendering is not always that exact and error-prone, also the VRAM is not made for memory reads, more for writes.
Driver for a specific card/chipset know all about the usable extentions of the manufacturer, but sometimes they are not available/outdated/closed-source, so Xorg uses them as default when no other driver could be used to talk to your hardware. With VESA drivers you can also talk to both a AMD and a nVidia card - it's just that you don't wanna do it.

Small example:
I once was on Kali Linux with an outdated Xorg and outdated userspace drivers. intel_drv.so couldn't be loaded, because the Haswell chip was too new back then, so instead of using the intel driver, Xorg fell back to VESA. Note that I used a vanilla kernel with a recent i915 module, so on kernel side everything was fine. I didn't really notice until VLC consumed 2 cores to render a normal MP4 video, due to the generic VESA driver.
When I switched to Gentoo and used a recent Xorg version (and a recent intel_drv.so), the CPU usage was cut down from 200% to 4-10% - and OpenGL finally worked as well.

How you disable them? Well ...

Code: Select all

Section "Device"
	Identifier  "aticonfig-Device[0]-0"
	Driver      "fglrx"
	BusID       "PCI:2:0:0"
EndSection

should have been enough, but it does not seem to be the case here.
There are usually VESA and Userspace VESA parts in the kernel, but as long as the Xorg drivers do not get loaded in, they are harmless - usually. They would provide you VTs in your native resolution if you don't use open drivers (because normally those don't support kernel mode setting). You can try out and disable support for them, the CONFIGs are CONFIG_FB_UVESA and CONFIG_FB_VESA - but I don't think that'd work.

nope. doing the symlink made it worse.
there was no error in xorg.log, but everithing was slower. even glxgears was incredible slow

/ver/log/kern.log or /var/log/syslog show no error as well? And you are sure you used the x64 version?
Otherwise ... that's rather strange, yet nothing unusual for AMD. First writing the DRI module in the wrong directory (or setting a wrong path in their driver), then crippling the performance another time. Maybe they even set a wrong path for purpose because they experienced all kind of regressions - but that's mere speculation. In this case the driver seems to be broken - did you try out the open source driver? If you don't want to, you might need to contact AMDs support team to report the problems.

Sorry I couldn't really help here.

eccerr0r · Post by **eccerr0r** » Fri Jun 27, 2014 1:30 am

The idea to try another Linux livecd is not a bad option, to see if others have the same problem. Then again they may not have fglrx installed...

We can't quite rule out hardware issues or something as simple as overheating hardware just yet.

I think it should be OK to ignore the "VESA" and "VBE" stuff, the fglrx module is clearly being loaded but just not running at the right speed. Apparently my guess that MESA was compiled wrong was also incorrect, I was hoping that the software was simply going through the wrong set of libraries for whatever reason.

One other off the wall question, are you using a virtual machine here? Doubt it but I had to ask...

broli · Post by **broli** » Sat Jun 28, 2014 5:52 pm

ok

tried to go for the opernsource drivers and couldnt make them work. probably my fault

reverted to the propietary drivers, and realized i had vsync on
with vsync off, my fps are more like what i was specting

Code: Select all

carlos@Opteron ~ $ glxgears
14412 frames in 5.0 seconds = 2882.391 FPS

but i still have the same issue. im starting to hink this is not a video related problem. since i still have what i was calling "input lag" but know, maybe its not related to input
maybe the entire system is freezing for a second every some.

cpuscaling going crazy? what other way to test this? i could stop XDM and try form the console, but i cant think of an application or tool that can test this...

dachschaden · Post by **dachschaden** » Sat Jun 28, 2014 5:59 pm

Wait ... didn't you say it got [worse] after you symlinked the DRI library for Xorg?
Because I thought that you expected 60 FPS, not 55 FPS. glxgears often runs with V-Sync enabled, so you cannot really use it for benchmarks. 55 FPS indeed would be slow on V-Sync:

Code: Select all

311 frames in 5.0 seconds = 61.899 FPS
311 frames in 5.0 seconds = 62.170 FPS
306 frames in 5.0 seconds = 61.172 FPS

That's what I got on my intel chip. Input lag indeed can rise from V-Sync.

About your problem with YT (I don't really think it's related with your driver for now, but who knows?) - try to start firefox from the command line, open a tab to YT and see if there are any messages on the console.
Also you can use htop to see the CPU usage while seeing a video. On Xfce there are nice plugins which show you the current CPU load, you can check them out as well.

eccerr0r · Post by **eccerr0r** » Sat Jun 28, 2014 9:18 pm

Woah need to back up for a second.

X11 should not be "stuttering" as in it works for a while then hangs for a second then comes back? When typing into a text window on a webpage do all your typing show up right away? When you mention emerge, do you mean in a terminal window in X11 or when you ctrl-alt-Fx to get back to the console virtual terminals?

It sounds indeed that the setup is working fine (though I'd imagine a RadeonHD 6700 blow my RadeonHD 5770's away in FPS).

Still a strange mystery. I wonder if you ran 'top' and watched it while it stutters, is there anything interesting? How about cat /proc/interrupts, is there a massive storm of interrupts coming from somewhere?

broli · Post by **broli** » Sun Jun 29, 2014 3:19 am

Yes, stutter as in works, then it doesn't.
A ratio of 1 second stopping for every 3 seconds

When a type, letters appear, stop, then resume when this stutter happens

eccerr0r · Post by **eccerr0r** » Sun Jun 29, 2014 5:43 pm

OK yes that's a weird problem.
Things you need to try to rule out: Perhaps with 'top':
Is it swapping/out of RAM?

Then cat /proc/interrupts - is there an interrupt storm?

Does this show up on other Linux?

I wasn't quite sure from your debug:

Does it happen in console/text mode?
If you completely quit out of X11 does it still do this?
Does it do this on the login window (if it's graphical)?
If you ssh into the machine from another machine, does it also lag?

broli · Post by **broli** » Sun Jun 29, 2014 8:23 pm

swap is 0% used (by conky and top)
i have stared at conky for long periods of time, and i cant see a cpu or memory usage spike, and the stuttering is constant

i have no idea how to interpret this infomation about interrupts
http://bpaste.net/show/jUZGI8wnvV83p2UqBSR8/

i dont have another linux ion this pc, i only have a windows install (and it works fine)

i have only tested in a xterm in X11, not in a tty
i dont know iof this still happens when i quit X11 completly, because i wouldnt know how to check
i cant see any lag in XDM, but i dont think it would be easy to see, not to much interactions are posible
i would try trough ssh, if i knew how to test it on a pure text console