D23881: Possible solution for scheduling repaints on NVIDIA

[Roman Gilg]

romangg added a comment.


  In D23881#529634 <https://phabricator.kde.org/D23881#529634>, @ekurzinger wrote:
  
  > Also, apart from the above two comments, any thoughts to how this relates to Roman's pending re-work of a lot of the GLX code https://phabricator.kde.org/D23105?
  
  
  @fredrik would be interested in this as well. This change allows to schedule buffer swaps like we do with swap events at some point before the vblank and then get an event through second thread when the thread is unblocked again i.e. when the swap has been completed, right? This should also work with my rework patches only providing a single path with an event after swap (or a fallback timer if such an event is not available on the hardware).
  
  And what do you think of using https://www.khronos.org/registry/OpenGL/extensions/NV/GLX_NV_delay_before_swap.txt as suggested by Erik in D23105#525696 <https://phabricator.kde.org/D23105#525696> instead of blocking through the `__GL_MaxFramesAllowed` equals 1 setting? Your approach with the thread maps to the model "swap -> wait for event -> (delay for smaller latency ->) swap -> wait for event -> ..." used by the mesa drivers pretty well though.

REPOSITORY
  R108 KWin

REVISION DETAIL
  https://phabricator.kde.org/D23881

To: fredrik, #kwin, romangg
Cc: ekurzinger, kwin, LeGast00n, The-Feren-OS-Dev, sbergeron, jraleigh, fbampaloukas, GB_2, mkulinski, ragreen, jackyalcine, iodelay, crozbo, bwowk, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, hardening, romangg, jensreuterberg, abetts, sebas, apol, mart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kwin/attachments/20190920/1036262e/attachment.html>