https://bugs.freedesktop.org/show_bug.cgi?id=75719
Priority: medium Bug ID: 75719 Assignee: dri-devel@lists.freedesktop.org Summary: mplayer -vo gl consume more CPU on r200 Severity: normal Classification: Unclassified OS: Linux (All) Reporter: smoki00790@gmail.com Hardware: x86 (IA32) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI
OS is current Debian Sid 32bit, card 1002:5960...
So this is on r200 i spotted playing any video file vith gl render (but also many videos in games are also affected), bisecting says it started with this code in ttm:
http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next&id=a095c60...
And it performs the same also in 3.14-rc5 kernel :). It consume cca 40% or more CPU power after that commit... that *more* depends on video file and if it is in game or playing video file with mplayer -vo gl.
Mesa version seems doesn't metter i tried 9.2 git, 10.0 git, 10.1 git and current git master.
https://bugs.freedesktop.org/show_bug.cgi?id=75719
--- Comment #1 from smoki smoki00790@gmail.com --- Created attachment 95043 --> https://bugs.freedesktop.org/attachment.cgi?id=95043&action=edit dmesg
https://bugs.freedesktop.org/show_bug.cgi?id=75719
--- Comment #2 from smoki smoki00790@gmail.com --- Created attachment 95046 --> https://bugs.freedesktop.org/attachment.cgi?id=95046&action=edit glxinfo
https://bugs.freedesktop.org/show_bug.cgi?id=75719
--- Comment #3 from smoki smoki00790@gmail.com --- Created attachment 95047 --> https://bugs.freedesktop.org/attachment.cgi?id=95047&action=edit Xorg.0.log
https://bugs.freedesktop.org/show_bug.cgi?id=75719
--- Comment #4 from smoki smoki00790@gmail.com ---
Disable or enable ColorTiling doesn't help it is the same plus 40% CPU usage.
In both cases even it used more CPU for gl video playback it is not smooth anymore.
https://bugs.freedesktop.org/show_bug.cgi?id=75719
--- Comment #5 from smoki smoki00790@gmail.com --- Created attachment 95050 --> https://bugs.freedesktop.org/attachment.cgi?id=95050&action=edit Before commit
Example from games when video is there: main menu from OpenJK game https://github.com/JACoders/OpenJK . In the centar circle there is playing a video file.
CPU usage is 50% and it have ~50 FPS
https://bugs.freedesktop.org/show_bug.cgi?id=75719
--- Comment #6 from smoki smoki00790@gmail.com --- Created attachment 95051 --> https://bugs.freedesktop.org/attachment.cgi?id=95051&action=edit With this commit
With this commit:
CPU usage is higher 90% but it have just ~12 FPS :).
https://bugs.freedesktop.org/show_bug.cgi?id=75719
--- Comment #7 from smoki smoki00790@gmail.com ---
So in this case it uses 700 MHz more CPU power, but gives nothing FPS :).
https://bugs.freedesktop.org/show_bug.cgi?id=75719
--- Comment #8 from Thomas Hellström thellstrom@vmware.com --- There's really nothing in this commit that should affect anything but metadata, and if anything, CPU usage should've decreased.
So if CPU usage is drastically increased by this commit (or rather this merge), IMHO that points to a bug somewhere else, but triggered by this merge; possibly in radeon / TTM caching setup or in the x86 PAT memory region tracking code.
In any case, I'm on out-of-office this week and can't look at this before next week, but meantime it would be helpful if you could perform a couple of additional checks:
1) Try to find out which of the commits in the merge that causes this. If that turns out to be hard, could you change all occurencies of VM_PFNMAP in ttm_bo_mmap() (ttm_bo_vm.c) to VM_MIXEDMAP and check if that fixes the problem you are seeing?
2) If you're familiar with oprofile, it would be very helpful to see a profile of a "good" and a "bad" run, including kernel symbols.
Thanks,
/Thomas
https://bugs.freedesktop.org/show_bug.cgi?id=75719
--- Comment #9 from smoki smoki00790@gmail.com --- (In reply to comment #8)
could you change all occurencies of VM_PFNMAP in ttm_bo_mmap() (ttm_bo_vm.c) to VM_MIXEDMAP and check if that fixes the problem you are seeing?
Quick try and yes that helps :). Seems like r200 like VM_MIXEDMAP, but not VM_PFNMAP.
https://bugs.freedesktop.org/show_bug.cgi?id=75719
--- Comment #10 from smoki smoki00790@gmail.com ---
One thing to point out which is rather strange to me, but maybe that can help someone to figured out what is this... GL games rendering and CPU usage in them are normal and not affected by this bug!!! but ONLY gl video playback triggers this both with players or in games.
So two thing are in this combination: VM_PFNMAP and GL videos doesn't play well together on r200 :).
https://bugs.freedesktop.org/show_bug.cgi?id=75719
--- Comment #11 from smoki smoki00790@gmail.com --- I am not in this but... could it be that videos played with gl are also some kind of special case which maybe? needs COW thus need MIXEDMAP or something like that? :)
https://bugs.freedesktop.org/show_bug.cgi?id=75719
--- Comment #12 from smoki smoki00790@gmail.com --- Created attachment 95181 --> https://bugs.freedesktop.org/attachment.cgi?id=95181&action=edit BAD: 3.14-rc5 and VM_PFNMAP
(In reply to comment #8)
- If you're familiar with oprofile, it would be very helpful to see a
profile of a "good" and a "bad" run, including kernel symbols.
Not very familiar but to give it a try :). This is 3.14-rc5 proper kernel with pfnmap which is bad case here and then oprofiled with pfnmap changed to mixedmap which is good one :).
https://bugs.freedesktop.org/show_bug.cgi?id=75719
--- Comment #13 from smoki smoki00790@gmail.com --- Created attachment 95182 --> https://bugs.freedesktop.org/attachment.cgi?id=95182&action=edit GOOD: 3.14-rc5 and VM_MIXEDMAP
https://bugs.freedesktop.org/show_bug.cgi?id=75719
--- Comment #14 from smoki smoki00790@gmail.com --- (In reply to comment #8)
So if CPU usage is drastically increased by this commit (or rather this merge), IMHO that points to a bug somewhere else, but triggered by this merge; possibly in radeon / TTM caching setup or in the x86 PAT memory region tracking code.
Seems like that is the case... VM_PFNMAP usage instead of VM_MIXEDMAP triggers that i now need 'nopat' boot option it is also workaround...
So only 'nopat' option work here good with VM_PFNMAP or like before VM_MIXEDMAP is good with PAT... VM_PFNMAP with PAT here is really unusable for gl videos :).
https://bugs.freedesktop.org/show_bug.cgi?id=75719
--- Comment #15 from Thomas Hellström thellstrom@vmware.com --- (In reply to comment #14)
(In reply to comment #8)
So if CPU usage is drastically increased by this commit (or rather this merge), IMHO that points to a bug somewhere else, but triggered by this merge; possibly in radeon / TTM caching setup or in the x86 PAT memory region tracking code.
Seems like that is the case... VM_PFNMAP usage instead of VM_MIXEDMAP triggers that i now need 'nopat' boot option it is also workaround...
So only 'nopat' option work here good with VM_PFNMAP or like before VM_MIXEDMAP is good with PAT... VM_PFNMAP with PAT here is really unusable for gl videos :).
Interesting, although it's not the first time x86 pat/caching has busted graphics performance-wise, which might appear a bit strange considering graphics is a major user.
In any case, I'll put together a patch to revert the VM_PFNMAP usage until I've figured out what's really happening (it's only there to boost performance anyway).
Meanwhile, the fact that this is visible also points to an area of potential improvement in the radeon driver. Apparently video playback causes a lot of buffer maps / unmaps. Could the maps somehow be cached in the driver?
Thanks, Thomas
https://bugs.freedesktop.org/show_bug.cgi?id=75719
Martin Peres martin.peres@free.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |MOVED
--- Comment #16 from Martin Peres martin.peres@free.fr --- -- GitLab Migration Automatic Message --
This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/455.
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org