<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - mplayer -vo gl consume more CPU on r200" href="https://bugs.freedesktop.org/show_bug.cgi?id=75719#c15">Comment # 15</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - mplayer -vo gl consume more CPU on r200" href="https://bugs.freedesktop.org/show_bug.cgi?id=75719">bug 75719</a> from <a class="email" href="mailto:thellstrom@vmware.com" title="Thomas Hellström <thellstrom@vmware.com>"> Thomas Hellström</a> <pre>(In reply to <a href="show_bug.cgi?id=75719#c14">comment #14</a>) > (In reply to <a href="show_bug.cgi?id=75719#c8">comment #8</a>) > > 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</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>