From: bugzilla-daemon@freedesktop.org
To: dri-devel@lists.freedesktop.org
Subject: [Bug 75719] mplayer -vo gl consume more CPU on r200
Date: Mon, 10 Mar 2014 09:41:25 +0000 [thread overview]
Message-ID: <bug-75719-502-UFWGI8JI8v@http.bugs.freedesktop.org/> (raw)
In-Reply-To: <bug-75719-502@http.bugs.freedesktop.org/>
[-- Attachment #1.1: Type: text/plain, Size: 1441 bytes --]
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
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 2383 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2014-03-10 9:41 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-03 15:09 [Bug 75719] New: mplayer -vo gl consume more CPU on r200 bugzilla-daemon
2014-03-03 17:17 ` [Bug 75719] " bugzilla-daemon
2014-03-03 17:18 ` bugzilla-daemon
2014-03-03 17:19 ` bugzilla-daemon
2014-03-03 17:22 ` bugzilla-daemon
2014-03-03 18:04 ` bugzilla-daemon
2014-03-03 18:06 ` bugzilla-daemon
2014-03-03 18:08 ` bugzilla-daemon
2014-03-04 13:06 ` bugzilla-daemon
2014-03-04 14:37 ` bugzilla-daemon
2014-03-04 15:47 ` bugzilla-daemon
2014-03-04 17:37 ` bugzilla-daemon
2014-03-05 18:49 ` bugzilla-daemon
2014-03-05 18:50 ` bugzilla-daemon
2014-03-06 4:40 ` bugzilla-daemon
2014-03-10 9:41 ` bugzilla-daemon [this message]
2019-11-19 8:44 ` bugzilla-daemon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-75719-502-UFWGI8JI8v@http.bugs.freedesktop.org/ \
--to=bugzilla-daemon@freedesktop.org \
--cc=dri-devel@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox