[prev in list] [next in list] [prev in thread] [next in thread]
List: kwin
Subject: Re: Review Request 109783: split hasWaitSync to blocksForRetrace and syncsToVBlank
From: Thomas_Lübking <thomas.luebking () gmail ! com>
Date: 2013-05-19 20:26:17
Message-ID: 20130519202617.27569.68970 () vidsolbach ! de
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
> On May 16, 2013, 3:27 p.m., Ralf Jung wrote:
> > Working fine here. It still has some statics which I don't like, but well - I \
> > think we can agree to disagree here.
> > > If we ever meet, one of you is going to have to show me altering triple \
> > > buffering under the running WM ;-P
> > Will do. After I bought you enough beer that you believe anything. :D
> >
> > > Though: i'm currently running Fredriks patches and no idea whether that's the \
> > > cause (gonna figure) but sth. changed and re-using the frontbuffer now seems to \
> > > induce blocking (not like the mesa extremely-slow-case, but swapping blocks. \
> > > 6-8ms mean, but not > 15-16ms) Could also be the driver, though - i hadn't \
> > > checked that for a longer time.
> > Interesting. It's still (with his patches) working all right here, mean block \
> > time was 0.65ms and 0.35ms in my two attempts. Probably that comment on one of \
> > Martin's blog posts was right: These copy-pixel paths are not optimised in the \
> > drivers as they are not what's typically used by GL applications (read: games), \
> > and drivers optimise for the common case.
> > However, I made an interesting observation: If I change \
> > Compositor::setCompositeTimer() to never sleep for more than 2ms, the detection \
> > still says that triple buffering is activated. However, my profiler tells me that \
> > 80% of the main thread CPU time are spent in the renderer - obviously, the \
> > blocking occurs somewhere else. This is consistent with the observations I made \
> > with my simple GL test application: The block is often done in glClear, instead \
> > of glXSwapBuffers.
>
> Ralf Jung wrote:
> Hm, the timer logic is more nasty than I thought: Even when swap buffers does not \
> block, missing frames barely still seems to be a problem. If I force the detection \
> to assume double-buffering (which just makes it wait 6ms less in the timer, \
> right?), my simple GL test application runs with smooth 60fps and the vertical bar \
> it moves around looks perfectly like when composite is disabled.
> If I force KWin to assume triple-buffering, the bar stutters around 4 times a \
> second. Framerate is at 57fps. I assume this is because KWin now takes barely above \
> 16ms to render, so three to four times a second, it does not come in time for the \
> next scanout, and then it does not block, however the same image is shown for two \
> consecutive frames, which is immediately visible. The only reliable way to fix this \
> I can come with is to have a tight render loop which uses the blocking that even \
> triple-buffering systems have to throttle. However, in KWin this obviously means \
> rendering and input processing must be done in different threads. It also induces \
> some latency (a frame is drawn at the beginning of a 16ms interval, but presented \
> at its end), however we already have that one-frame latency right now. I have no \
> idea how hard is it to move this into different threads - one "Big KWin Lock" would \
> probably suffice as this would block event handling only while rendering is \
> actually performed, however, this is only easily feasible if there is a single \
> entry point from the event handling loop to KWin. Oh, and non-synced updates will \
> cause a tight loop, so something needs to be done about them (manual throttling \
> again...). /EndDream
> More realistically, maybe some slack time should also be subtracted in the timer \
> logic if we have triple-buffering. Which would of course break the triple-buffering \
> detection logic, so it can only be done after detection is finished.
> Thomas Lübking wrote:
> *cough*
>
> Ralf Jung wrote:
> What's it?^^ This just shows that the timing logic is more complicated than I (we?) \
> thought.
> This detection is definitely still useful, see \
> https://git.reviewboard.kde.org/r/110527/ . Also the "right" timing will probably \
> still be different for blocking and non-blocking, e.g. we will never want to "give \
> up" (due to not enough time being left) in a frame if SwapBuffers does not block.
No, meant "*cough*, can i please get a comment about shipping, *cough*" ;-P
I've btw. a similar but different patch pending here =)
- Thomas
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/109783/#review32651
-----------------------------------------------------------
On May 15, 2013, 8:25 p.m., Thomas Lübking wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/109783/
> -----------------------------------------------------------
>
> (Updated May 15, 2013, 8:25 p.m.)
>
>
> Review request for kwin, Martin Gräßlin and Ralf Jung.
>
>
> Description
> -------
>
> ... for that is not the same (though atm. syncsToVBlank is only used to determine \
> the fps interval - other usage pot. for supportInfo etc.)
> Also "hasWaitSync" is an implementation detail of GLX - EGL doesn't have it.
>
>
> Diffs
> -----
>
> kwin/composite.cpp 63b0735
> kwin/eglonxbackend.cpp 0d3ef17
> kwin/glxbackend.h 49b897e
> kwin/glxbackend.cpp cf28a9a
> kwin/scene.h 4dc4f47
> kwin/scene.cpp cb7d04b
> kwin/scene_opengl.h cb01664
> kwin/scene_opengl.cpp fc28035
>
> Diff: http://git.reviewboard.kde.org/r/109783/diff/
>
>
> Testing
> -------
>
> Compiles and runs. Is part of https://git.reviewboard.kde.org/r/109086/ and has \
> been used for pretty long here now.
>
> Thanks,
>
> Thomas Lübking
>
>
[Attachment #5 (text/html)]
<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 \
solid;"> <tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="http://git.reviewboard.kde.org/r/109783/">http://git.reviewboard.kde.org/r/109783/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <p style="margin-top: 0;">On May 16th, 2013, 3:27 p.m. UTC, <b>Ralf Jung</b> \
wrote:</p> <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; \
padding-left: 10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; \
white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Working \
fine here. It still has some statics which I don't like, but well - I think we \
can agree to disagree here.
> If we ever meet, one of you is going to have to show me altering triple \
buffering under the running WM ;-P Will do. After I bought you enough beer that you \
believe anything. :D
> Though: i'm currently running Fredriks patches and no idea whether \
that's the cause (gonna figure) but sth. changed and re-using the frontbuffer now \
seems to induce blocking (not like the mesa extremely-slow-case, but > swapping \
blocks. 6-8ms mean, but not > 15-16ms) > Could also be the driver, though - i \
hadn't checked that for a longer time. Interesting. It's still (with his \
patches) working all right here, mean block time was 0.65ms and 0.35ms in my two \
attempts. Probably that comment on one of Martin's blog posts was right: These \
copy-pixel paths are not optimised in the drivers as they are not what's \
typically used by GL applications (read: games), and drivers optimise for the common \
case.
However, I made an interesting observation: If I change \
Compositor::setCompositeTimer() to never sleep for more than 2ms, the detection still \
says that triple buffering is activated. However, my profiler tells me that 80% of \
the main thread CPU time are spent in the renderer - obviously, the blocking occurs \
somewhere else. This is consistent with the observations I made with my simple GL \
test application: The block is often done in glClear, instead of \
glXSwapBuffers.</pre> </blockquote>
<p>On May 16th, 2013, 3:48 p.m. UTC, <b>Ralf Jung</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Hm, the timer logic is \
more nasty than I thought: Even when swap buffers does not block, missing frames \
barely still seems to be a problem. If I force the detection to assume \
double-buffering (which just makes it wait 6ms less in the timer, right?), my simple \
GL test application runs with smooth 60fps and the vertical bar it moves around looks \
perfectly like when composite is disabled.
If I force KWin to assume triple-buffering, the bar stutters around 4 times a second. \
Framerate is at 57fps. I assume this is because KWin now takes barely above 16ms to \
render, so three to four times a second, it does not come in time for the next \
scanout, and then it does not block, however the same image is shown for two \
consecutive frames, which is immediately visible. The only reliable way to fix this I \
can come with is to have a tight render loop which uses the blocking that even \
triple-buffering systems have to throttle. However, in KWin this obviously means \
rendering and input processing must be done in different threads. It also induces \
some latency (a frame is drawn at the beginning of a 16ms interval, but presented at \
its end), however we already have that one-frame latency right now. I have no idea \
how hard is it to move this into different threads - one "Big KWin Lock" \
would probably suffice as this would block event handling only while rendering is \
actually performed, however, this is only easily feasible if there is a single entry \
point from the event handling loop to KWin. Oh, and non-synced updates will cause a \
tight loop, so something needs to be done about them (manual throttling again...). \
/EndDream More realistically, maybe some slack time should also be subtracted in the \
timer logic if we have triple-buffering. Which would of course break the \
triple-buffering detection logic, so it can only be done after detection is \
finished.</pre> </blockquote>
<p>On May 19th, 2013, 11:07 a.m. UTC, <b>Thomas Lübking</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">*cough*</pre> \
</blockquote>
<p>On May 19th, 2013, 7:28 p.m. UTC, <b>Ralf Jung</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">What's it?^^ This \
just shows that the timing logic is more complicated than I (we?) thought.
This detection is definitely still useful, see \
https://git.reviewboard.kde.org/r/110527/ . Also the "right" timing will \
probably still be different for blocking and non-blocking, e.g. we will never want to \
"give up" (due to not enough time being left) in a frame if SwapBuffers \
does not block.</pre> </blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">No, meant "*cough*, \
can i please get a comment about shipping, *cough*" ;-P
I've btw. a similar but different patch pending here =)</pre>
<br />
<p>- Thomas</p>
<br />
<p>On May 15th, 2013, 8:25 p.m. UTC, Thomas Lübking wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" \
style="background-image: \
url('http://git.reviewboard.kde.org/static/rb/images/review_request_box_top_bg.ab6f3b1072c9.png'); \
background-position: left top; background-repeat: repeat-x; border: 1px black \
solid;"> <tr>
<td>
<div>Review request for kwin, Martin Gräßlin and Ralf Jung.</div>
<div>By Thomas Lübking.</div>
<p style="color: grey;"><i>Updated May 15, 2013, 8:25 p.m.</i></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" \
style="border: 1px solid #b8b5a0"> <tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">... for that is not the same (though atm. syncsToVBlank is only used to \
determine the fps interval - other usage pot. for supportInfo etc.)
Also "hasWaitSync" is an implementation detail of GLX - EGL doesn't \
have it.</pre> </td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: \
1px solid #b8b5a0"> <tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">Compiles and runs. Is part of https://git.reviewboard.kde.org/r/109086/ \
and has been used for pretty long here now.</pre> </td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>kwin/composite.cpp <span style="color: grey">(63b0735)</span></li>
<li>kwin/eglonxbackend.cpp <span style="color: grey">(0d3ef17)</span></li>
<li>kwin/glxbackend.h <span style="color: grey">(49b897e)</span></li>
<li>kwin/glxbackend.cpp <span style="color: grey">(cf28a9a)</span></li>
<li>kwin/scene.h <span style="color: grey">(4dc4f47)</span></li>
<li>kwin/scene.cpp <span style="color: grey">(cb7d04b)</span></li>
<li>kwin/scene_opengl.h <span style="color: grey">(cb01664)</span></li>
<li>kwin/scene_opengl.cpp <span style="color: grey">(fc28035)</span></li>
</ul>
<p><a href="http://git.reviewboard.kde.org/r/109783/diff/" style="margin-left: \
3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>
_______________________________________________
kwin mailing list
kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic