<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEEDINFO "
title="NEEDINFO --- - KDE Konsole very slow scrolling with TearFree and QT graphics system native"
href="https://bugs.freedesktop.org/show_bug.cgi?id=77436#c128">Comment # 128</a>
on <a class="bz_bug_link
bz_status_NEEDINFO "
title="NEEDINFO --- - KDE Konsole very slow scrolling with TearFree and QT graphics system native"
href="https://bugs.freedesktop.org/show_bug.cgi?id=77436">bug 77436</a>
from <span class="vcard"><a class="email" href="mailto:chris@chris-wilson.co.uk" title="Chris Wilson <chris@chris-wilson.co.uk>"> <span class="fn">Chris Wilson</span></a>
</span></b>
<pre>It's a balance between render lag and input lag. If we forgo throttling, we can
build long streams of render commands on the GPU, and the display lags behind.
If we wait for the GPU for too long, we stop sending clients updates.
I have two problems here:
1. The throttling should already exist to prevent the huge +2s stalls. Unless
it is just a single massive batch constructed within one throttle period that
generates the massive stall. trace-cmd should help identify if that is the
case.
2. There is no way that we should be able to queue more than the GPU can handle
in the first place, certainly not +2s! So something is not quite right with the
command stream. This is why I have been trying to spot likely culprits such as
using large untiled buffers.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
</ul>
</body>
</html>