[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-03-31 17:51:50
Message-ID: 20130331175150.3641.74423 () vidsolbach ! de
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


> On None, Thomas Lübking wrote:
> > kwin/glxbackend.cpp, line 115
> > <http://git.reviewboard.kde.org/r/109783/diff/1/?file=125912#file125912line115>
> > 
> > Currently hardcoded.
> > We really should find a way to auto-determine this, no user can possible figure \
> > that himself.
> 
> Ralf Jung wrote:
> > no user can possible figure that himself
> That's true. However, I wonder how many users will even need a setting of "true" \
> here. Maybe I can convince my father to install a Kubuntu test installation on his \
> laptop with an AMD card, so I can check how the AMD drivers behave. What could be \
> done (in a different patch, preferably ;-) is calling SwapBufers three times \
> immediately after each other. This should take at least 32ms in a double-buffered \
> blocking scenario, while it should never take more than 16ms in a triple-buffered \
> "block only if two frames are already queued" scenario (assuming 60Hz). However, \
> IMHO this should be done on first startup only (and/or if the GPU setup changes - \
> if KWin can detect that) as it will delay KWin starting and might cause flicker. 

> calling SwapBufers three times immediately after each other. This should take at \
> least 32ms in a double-buffered blocking scenario
Yes.
> while it should never take more than 16ms in a triple-buffered "block only if two \
> frames are already queued" scenario
I fear it's more like "block only if one frame is queued" for triple buffering \
(you're waiting for the frontbuffer to free the backbuffer - if you queue rather than \
discard frames you'll only have the first out of two subsequent swaps for free) - so \
a) a double swap is a sufficient indicator, but b) you'll then wait for (x)ms + 16ms \
                in the double buffering and (16 - y)ms in the triple buffering case
- x is the blocking time until the next retrace, the 2nd 16ms you'll wait for sure
- on blocking triple buffering the first swap comes for free and then you'll have to \
wait until the next restrace (<= 16ms)

So the test would be to swap twice. If that takes < 15ms you've triple buffering and \
if it takes > 17ms you've double buffering (given there's sufficient CPU time for \
that thread in general) If you end up between 15 & 17 ms there could be either and \
you got to retest (by knowing that a blocking swap and thus retrace just occured - so \
sleeping 16+8ms should kick you into a more expressive condition)


I'm not yet sure where to put that (apparently not init and if we wanted to cache it, \
we'd have to check whether the X server is new - until some driver permits changing \
that at runtime)

Another option was to start with the assumption of triple buffering and measure swaps \
online - if then there's a "significant" amount of swaps that take "significantly" \
more than no time, we can pretty much assume that this is a blocking swap and change \
the state at runtime.


- Thomas


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/109783/#review30049
-----------------------------------------------------------


On March 28, 2013, 10:32 p.m., Thomas Lübking wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/109783/
> -----------------------------------------------------------
> 
> (Updated March 28, 2013, 10:32 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 ee885dc 
> kwin/eglonxbackend.cpp ecb6e0a 
> kwin/glxbackend.h 49b897e 
> kwin/glxbackend.cpp c68bcee 
> kwin/scene.h 5d49c40 
> kwin/scene.cpp 939f000 
> kwin/scene_opengl.h 409ec3d 
> kwin/scene_opengl.cpp 3343164 
> 
> 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 , <b>Thomas Lübking</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;">  



<table width="100%" border="0" bgcolor="white" style="border: 1px solid #C0C0C0; \
border-collapse: collapse; margin: 2px padding: 2px;">  <thead>
  <tr>
   <th colspan="4" bgcolor="#F0F0F0" style="border-bottom: 1px solid #C0C0C0; \
font-size: 9pt; padding: 4px 8px; text-align: left;">  <a \
href="http://git.reviewboard.kde.org/r/109783/diff/1/?file=125912#file125912line115" \
style="color: black; font-weight: bold; text-decoration: \
underline;">kwin/glxbackend.cpp</a>  <span style="font-weight: normal;">

     (Diff revision 1)

    </span>
   </th>
  </tr>
 </thead>

 <tbody style="background-color: #e4d9cb; padding: 4px 8px; text-align: center;">
  <tr>

   <td colspan="4"><pre style="font-size: 8pt; line-height: 140%; margin: 0; ">void \
GlxBackend::init()</pre></td>

  </tr>
 </tbody>



 
 

 <tbody>

  <tr>
    <th bgcolor="#b1ebb0" style="border-right: 1px solid #C0C0C0;" \
align="right"><font size="2"></font></th>  <td bgcolor="#c5ffc4" width="50%"><pre \
style="font-size: 8pt; line-height: 140%; margin: 0; "></pre></td>  <th \
bgcolor="#b1ebb0" style="border-left: 1px solid #C0C0C0; border-right: 1px solid \
#C0C0C0;" align="right"><font size="2">106</font></th>  <td bgcolor="#c5ffc4" \
width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; ">            \
<span class="n">setBlocksForRetrace</span><span class="p">(</span><span \
class="nb">false</span><span class="p">);</span></pre></td>  </tr>

 </tbody>

</table>

  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Currently hardcoded. We \
really should find a way to auto-determine this, no user can possible figure that \
himself.</pre>  </blockquote>



 <p>On March 29th, 2013, 10:07 a.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;">&gt; no user can \
possible figure that himself That&#39;s true. However, I wonder how many users will \
even need a setting of &quot;true&quot; here. Maybe I can convince my father to \
install a Kubuntu test installation on his laptop with an AMD card, so I can check \
how the AMD drivers behave. What could be done (in a different patch, preferably ;-) \
is calling SwapBufers three times immediately after each other. This should take at \
least 32ms in a double-buffered blocking scenario, while it should never take more \
than 16ms in a triple-buffered &quot;block only if two frames are already \
queued&quot; scenario (assuming 60Hz). However, IMHO this should be done on first \
startup only (and/or if the GPU setup changes - if KWin can detect that) as it will \
delay KWin starting and might cause flicker. </pre>
 </blockquote>







</blockquote>
<pre style="margin-left: 1em; white-space: pre-wrap; white-space: -moz-pre-wrap; \
white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">&gt; \
calling SwapBufers three times immediately after each other. This should take at \
least 32ms in a double-buffered blocking scenario Yes.
&gt; while it should never take more than 16ms in a triple-buffered &quot;block only \
if two frames are already queued&quot; scenario I fear it&#39;s more like &quot;block \
only if one frame is queued&quot; for triple buffering (you&#39;re waiting for the \
frontbuffer to free the backbuffer - if you queue rather than discard frames \
you&#39;ll only have the first out of two subsequent swaps for free) - so a) a double \
swap is a sufficient indicator, but b) you&#39;ll then wait for (x)ms + 16ms in the \
                double buffering and (16 - y)ms in the triple buffering case
- x is the blocking time until the next retrace, the 2nd 16ms you&#39;ll wait for \
                sure
- on blocking triple buffering the first swap comes for free and then you&#39;ll have \
to wait until the next restrace (&lt;= 16ms)

So the test would be to swap twice. If that takes &lt; 15ms you&#39;ve triple \
buffering and if it takes &gt; 17ms you&#39;ve double buffering (given there&#39;s \
sufficient CPU time for that thread in general) If you end up between 15 &amp; 17 ms \
there could be either and you got to retest (by knowing that a blocking swap and thus \
retrace just occured - so sleeping 16+8ms should kick you into a more expressive \
condition)


I&#39;m not yet sure where to put that (apparently not init and if we wanted to cache \
it, we&#39;d have to check whether the X server is new - until some driver permits \
changing that at runtime)

Another option was to start with the assumption of triple buffering and measure swaps \
online - if then there&#39;s a &quot;significant&quot; amount of swaps that take \
&quot;significantly&quot; more than no time, we can pretty much assume that this is a \
blocking swap and change the state at runtime.</pre> <br />




<p>- Thomas</p>


<br />
<p>On March 28th, 2013, 10:32 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 March 28, 2013, 10:32 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 &quot;hasWaitSync&quot; is an implementation detail of GLX - EGL doesn&#39;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">(ee885dc)</span></li>

 <li>kwin/eglonxbackend.cpp <span style="color: grey">(ecb6e0a)</span></li>

 <li>kwin/glxbackend.h <span style="color: grey">(49b897e)</span></li>

 <li>kwin/glxbackend.cpp <span style="color: grey">(c68bcee)</span></li>

 <li>kwin/scene.h <span style="color: grey">(5d49c40)</span></li>

 <li>kwin/scene.cpp <span style="color: grey">(939f000)</span></li>

 <li>kwin/scene_opengl.h <span style="color: grey">(409ec3d)</span></li>

 <li>kwin/scene_opengl.cpp <span style="color: grey">(3343164)</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