[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:       Simeon Bird <bladud () gmail ! com>
Date:       2015-02-16 5:50:54
Message-ID: bug-343551-17878-cEb9UG6xBZ () http ! bugs ! kde ! org/
[Download RAW message or body]

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

--- Comment #33 from Simeon Bird <bladud@gmail.com> ---
> Your patch is absolutely correct, but some of the comments in the code are
> not.

Ok, I'll update the comments and post a new version. Incidentally, is this
actually an nvidia bug?
ie, does the standard call for glDeleteSync not to block? If the answer is yes,
should the patch
be made conditional on the nvidia driver somehow?

> 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. 

What I was worried about was in some other case - if trigger() is called and
then insertWait() is called immediately afterwards as part of the normal draw
routines. This would be a classic race condition and would lead to an
occasional unrepeatable hang. But maybe it isn't possible for this to happen
without something equivalent to xcb_flush?

> 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().

That's actually fine (I checked when debugging)

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