[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-20 17:51:21
Message-ID: bug-343551-17878-sFXsKeCoes () http ! bugs ! kde ! org/
[Download RAW message or body]

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

--- Comment #36 from Fredrik Höglund <fredrik@kde.org> ---
(In reply to Thomas Lübking from comment #35)
> (In reply to Fredrik Höglund from comment #32)
> > What glDeleteSync() is clearly waiting for is for the fence to become signaled
>
> (excuse my stupidity)
> Is this any "clearly" beyond hindsight?
> From out of all options, I considered this to be the least reasonable one

A fence is a synchronization primitive that is inserted in the command stream
so that you can wait for it and know that all prior commands have completed. So
when the function that deletes the associated sync object waits indefinitely
for something, my first thought is that it is waiting for the fence. Especially
when you consider that at least some of these sync objects are in an unsignaled
state, and no fence command has been set in the command stream that will signal
them. That Simeon's patch fixes the problem proves the theory.

> (would that mean the driver is in pre-emptive waiting condition - and what
> would be the runtime implications for windows that never trigger the fence?)

Windows don't trigger fences. The fences are triggered from
Compositor::performCompositing() immediately after fetching and resetting the
damage region, so we can know that the damage has landed in the window textures
before we render them. When we are about to render the first damaged window, we
insert a command to wait for the fence. If there are no damaged windows, we
don't trigger or wait for any fences.

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