<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Kabylake has poor performance, doesn't upclock during activity quickly with single display configurations" href="https://bugs.freedesktop.org/show_bug.cgi?id=102199#c16">Comment # 16</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Kabylake has poor performance, doesn't upclock during activity quickly with single display configurations" href="https://bugs.freedesktop.org/show_bug.cgi?id=102199">bug 102199</a> from <a class="email" href="mailto:rstrode@redhat.com" title="Ray Strode [halfline] <rstrode@redhat.com>"> Ray Strode [halfline]</a> <pre>(In reply to Chris Wilson from <a href="show_bug.cgi?id=102199#c15">comment #15</a>) > (In reply to Ray Strode [halfline] from <a href="show_bug.cgi?id=102199#c14">comment #14</a>) > > wouldn't the boosting need to happen before the drawing was started, not > > after its drawn and before its swapped ? > > With the glFinish, the boost would be applied to the rendering. It's just > that you end up with a synchronous step prior to SwapBuffers. oh okay. So I gave Lyude a build with this patch as an experiment: <a href="https://git.gnome.org/browse/mutter/commit/?h=wip/rstrode/finish-to-boost&id=4035543d4f73b9f2571c1f2dea67de5d0b1352f0">https://git.gnome.org/browse/mutter/commit/?h=wip/rstrode/finish-to-boost&id=4035543d4f73b9f2571c1f2dea67de5d0b1352f0</a> and she says it does help, but your kernel fix is all around smoother feeling. I don't know if that's because of the introduced blocking stalling other parts of the compositor or what... > > can the driver just boost whenever an input device fires off an event ? keep > > interactive performance up when the user is interacting... > > How to determine which request corresponds to the interactive stream? why do you need to ? at the end of the day the question is whether the gpu is 500mhz or 1300mhz right? just make it 1300mhz if there's input and let it downscale on its own when it stops animating and the user stops typing and swiping. > As a > gfx driver we have no knowledge of input devices. The system as a whole > struggles to identify interactive processes! The easiest way for us to > identify user tasks is by looking at what affects the output. But why do we need to know what processes are interactive ?</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> <li>You are the assignee for the bug.</li> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>