<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#c18">Comment # 18</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#c17">comment #17</a>) > The gfx driver doesn't have that information. I'm not sure if the kernel > knows what is an active hid, and certainly there's no link to it to either > the cpu scheduler or to us. I don't understand, the kernel sends input events from keyboard/mice/touchscreens to userspace via /dev/input/eventN interface, so why couldn't the clock speed get boosted any time an event got posted to one of those devices? git grep seems to suggest there's a function called input_register_handler() that lets various parts of the kernel hook into the event stream for all devices (granted this was just 60 seconds of searching, so I may be missing something). > From our perspective the only way we can > identify such streams is by looking at what ends up on the display, and > backtracking from there. The piece that pulls all of this together is the > compositor. But wouldn't it better if we could ramp up the clockspeed before firefox started rerendering a page getting drag scrolled, not after the compositor is responding to damage requests? > Because we are looking for anything that interacts with the user to > preferentially give those low latency. We identify these by contexts which > are tied to files and processes. On the other hand, we can remove that > guesswork if userspace is able to tell us what is high priority and what is > not. Okay, so it's not just video card in turbo mode or power save mode, but also certain GL contexts getting preferential access to the card. Seems like a worthwhile thing to have, I guess, but giving gnome-shell preferential access doesn't help firefox rerender faster, right ?</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>