[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [kwin] [Bug 343551] Kwin hangs, stops drawing the screen and starts using 100% cpu inside nvidia-glc
From:       Fredrik Höglund <fredrik () kde ! org>
Date:       2015-02-16 0:27:53
Message-ID: bug-343551-17878-fmLXKIzuOs () http ! bugs ! kde ! org/
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=343551

--- Comment #32 from Fredrik Höglund <fredrik@kde.org> ---
(In reply to Simeon Bird from comment #31)
> Created attachment 91085 [details]
> Another patch to fix the hang by manually triggering the xcb fence.
> 
> The hang occurs when the sync is in the Ready or Resetting state. It seems
> that nvidia doesn't like it if the gl sync is deleted or waited on before
> the xcb fence has been triggered.
> 
> This patch fixes it - there is no theory behind this, just trial and error.
> It also seems to me that if wait() is called sufficiently quickly after
> trigger() there will also be a hang.

Your patch is absolutely correct, but some of the comments in the code are not.
What glDeleteSync() is clearly waiting for is for the fence to become signaled,
and that is never going to happen unless kwin tells the X server to trigger it.
So it's not really correct to say that we need to manually trigger the fence;
it's not something that can happen automatically. It would be a very serious
bug if it ever did.

The comment above xcb_flush() is also not exactly correct. If the xcb_flush()
call is left out, glDeleteSync() will wait for the fence to become signaled,
but the trigger request will be stuck in the output buffer and never sent to
the X server. So glDeleteSync() ends up waiting indefinitely.

There is no need to call wait() before deleting the fence. The purpose of
wait() is to prevent the GPU from executing future draw commands before the
fence is signaled, and that's not relevant here. There may be a similar hazard
between calling wait() and glDeleteSync() without a glFlush() in-between as
with calling trigger() and glDeleteSync() without an xcb_flush() in-between. If
you want to make sure that the fence is signaled before you call
glDeleteSync(), you should call finish() instead of wait().

-- 
You are receiving this mail because:
You are watching all bug changes.=
[prev in list] [next in list] [prev in thread] [next in thread]