--===============8935978681931916286== Content-Type: multipart/alternative; boundary="===============7507492627904928673==" --===============7507492627904928673== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit > On None, Thomas Lübking wrote: > > kwin/glxbackend.cpp, line 115 > > > > > > 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 > > --===============7507492627904928673== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit
This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109783/

On , Thomas Lübking wrote:

kwin/glxbackend.cpp (Diff revision 1) 
void GlxBackend::init()
 

    106
    
            setBlocksForRetrace(false);

  


 




  
Currently hardcoded.
We really should find a way to auto-determine this, no user can possible figure that himself.

 




 
On March 29th, 2013, 10:07 a.m. UTC, 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






On March 28th, 2013, 10:32 p.m. UTC, Thomas Lübking wrote:











 

  


Review request for kwin, Martin Gräßlin and Ralf Jung.


By Thomas Lübking.




Updated March 28, 2013, 10:32 p.m.








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.

  		
 






Testing 



 

  
   
Compiles and runs. Is part of https://git.reviewboard.kde.org/r/109086/ and has been used for pretty long here now.

  		
 








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)
    • 





View Diff








  		
 











  

 



--===============7507492627904928673==--

--===============8935978681931916286==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
kwin mailing list
kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin

--===============8935978681931916286==--