https://bugs.kde.org/show_bug.cgi?id=406180
--- Comment #48 from Erik Kurzinger ---
(In reply to Guilherme Almeida from comment #47)
> (In reply to Luca Carlon from comment #22)
> > Hello, I'm also affected by this issue. It is so severe that the system was
> > hardly usable. I j
https://bugs.kde.org/show_bug.cgi?id=407968
--- Comment #2 from Erik Kurzinger ---
If that's the case, I suspect
https://github.com/NVIDIA/egl-wayland/commit/547055cb58690515077bd9f02b1325ed677650c1
might have been the fix. With that change we now correctly report whether EGL
images are Y
https://bugs.kde.org/show_bug.cgi?id=407966
--- Comment #1 from Erik Kurzinger ---
Sorry for taking a while to look into this, however it would seem krunner's
QSGRenderThread is getting stuck in eglSwapBuffers waiting for a
wl_surface::frame event. I think this is a similar issue to what I tried
https://bugs.kde.org/show_bug.cgi?id=406180
--- Comment #76 from Erik Kurzinger ---
The Qt patch has been submitted for review, sorry about the delay.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=406180
--- Comment #79 from Erik Kurzinger ---
https://codereview.qt-project.org/c/qt/qtbase/+/264563
It was suggested to just remove the m_swapInterval variable entirely instead of
resetting it in doneCurrent, but it should have the same effect as far
https://bugs.kde.org/show_bug.cgi?id=406180
Erik Kurzinger changed:
What|Removed |Added
Latest Commit|https://commits.kde.org/kwi |https://commits.kde.org/kwi
https://bugs.kde.org/show_bug.cgi?id=406180
Erik Kurzinger changed:
What|Removed |Added
Resolution|--- |FIXED
Latest Commit
https://bugs.kde.org/show_bug.cgi?id=406180
--- Comment #87 from Erik Kurzinger ---
Did you apply the qtbase patch from the earlier comment on this bug? Or the one
that was committed upstream?
https://code.qt.io/cgit/qt/qtbase.git/commit/?id=0c1831178540462da31fd7a4b6d2e446bc84498b
The patch
https://bugs.kde.org/show_bug.cgi?id=406180
--- Comment #34 from Erik Kurzinger ---
Setting the swap interval to 0 *should* resolve the issue, and indeed, on my
system the first time the window switcher is displayed it never hangs. However,
subsequent times it still can. Luca, does this agree
https://bugs.kde.org/show_bug.cgi?id=406180
--- Comment #38 from Erik Kurzinger ---
Should also note that the above needs to be applied in addition to David's
patch to KWin itself
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=406180
--- Comment #37 from Erik Kurzinger ---
> Do you mean "the first time the switcher is displayed after kwin process
> started"?
Yes, that's what I meant. Maybe also after restarting compositing.
This patch to qtbase seems to fix thin
https://bugs.kde.org/show_bug.cgi?id=406180
--- Comment #41 from Erik Kurzinger ---
It might be quicker for you to submit the Qt patch if you don't mind. We need
to go through some bureaucracy at NVIDIA to get approval before contributing to
open source projects which can delay things a bit
https://bugs.kde.org/show_bug.cgi?id=406180
Erik Kurzinger changed:
What|Removed |Added
CC||ekurzin...@nvidia.com
--
You are receiving
https://bugs.kde.org/show_bug.cgi?id=406180
--- Comment #96 from Erik Kurzinger ---
(In reply to ssergio-ll from comment #93)
> Qt Version: 5.12.3
Qt version 5.12.4 or later should contain the required patch.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=353983
Erik Kurzinger changed:
What|Removed |Added
CC||ekurzin...@nvidia.com
--- Comment #169 from
https://bugs.kde.org/show_bug.cgi?id=427603
--- Comment #11 from Erik Kurzinger ---
The mem value reported by "nvidia-smi dmon" refers to memory bandwidth
utilization. If the GPU isn't actively rendering anything, it's normal for it
to be zero. It should increase if you run a game or
https://bugs.kde.org/show_bug.cgi?id=427603
--- Comment #14 from Erik Kurzinger ---
Bar1 is the portion of video memory that can be accessed by the CPU over PCIe.
And yes, a graphical desktop environment would be expected to utilize GPU
memory bandwidth, but only if you're actually interacting
https://bugs.kde.org/show_bug.cgi?id=427603
--- Comment #15 from Erik Kurzinger ---
sorry, forgot to answer this...
> and is there a way to have nvidia-smi report only the total framebuffer
> memory size?
no, I don't think so, sorry. You could always pipe its output through some
othe
https://bugs.kde.org/show_bug.cgi?id=427603
--- Comment #19 from Erik Kurzinger ---
Ok, that is strange. It's kind of a separate issue to this ksysguard bug,
though. Would you mind either sending an email to linux-b...@nvidia.com or
starting a thread on
https://forums.developer.nvidia.com/c/gpu
https://bugs.kde.org/show_bug.cgi?id=424311
--- Comment #30 from Erik Kurzinger ---
Are you certain this is a regression in the 450.57 driver? We've reproduced the
issue internally at NVIDIA, but also observe similar corruption with a 440
series driver.
It is possible the regression
https://bugs.kde.org/show_bug.cgi?id=424592
--- Comment #12 from Erik Kurzinger ---
Dang. Yes, this is indeed a regression in the 450 NVIDIA driver. Thank you for
narrowing it down, David. I've identified the root cause and will try to get a
fix included in the next minor version.
--
You
https://bugs.kde.org/show_bug.cgi?id=424311
--- Comment #50 from Erik Kurzinger ---
To update, there *was* a driver regression which seems to be responsible for
the symptoms described here. See
https://bugs.kde.org/show_bug.cgi?id=424592#c11 for a description of the issue.
Unfortunately, I
https://bugs.kde.org/show_bug.cgi?id=424311
--- Comment #52 from Erik Kurzinger ---
(In reply to br1ghtch1p from comment #51)
> (In reply to Erik Kurzinger from comment #50)
> > To update, there *was* a driver regression which seems to be responsible for
> > the symptoms desc
https://bugs.kde.org/show_bug.cgi?id=424592
--- Comment #3 from Erik Kurzinger ---
Possibly also related to https://bugs.kde.org/show_bug.cgi?id=424311
Out of curiosity, are you using a PRIME / hybrid graphics setup? I'm wondering
if the issue is specific to such systems, as I've been using
https://bugs.kde.org/show_bug.cgi?id=353983
--- Comment #179 from Erik Kurzinger ---
(In reply to Sebastian Kuźlak from comment #177)
> nvidia 450.51 beta claims to fix this issue.
Yes, 450.51 should contain the fix. I would appreciate it if anyone who has
been affected by this bug wo
https://bugs.kde.org/show_bug.cgi?id=430207
--- Comment #2 from Erik Kurzinger ---
What Nate said. You can either send an email to linux-b...@nvidia.com or make a
post here https://forums.developer.nvidia.com/c/gpu-unix-graphics/linux/
It would be helpful if you could run nvidia-bug-report.sh
https://bugs.kde.org/show_bug.cgi?id=428089
--- Comment #2 from Erik Kurzinger ---
This is a tricky issue. Our client-side egl-wayland code really isn't set up to
handle the compositor restarting. The client would need some way to become
aware of this and send a new attach_eglstream_consumer
https://bugs.kde.org/show_bug.cgi?id=450914
--- Comment #8 from Erik Kurzinger ---
Tried this with a debug NVIDIA driver, and it looks like the application is
spending most of its time waiting for the PresentIdleNotify event from
Xwayland. If vsync is disabled this should get delivered pretty
https://bugs.kde.org/show_bug.cgi?id=448917
Erik Kurzinger changed:
What|Removed |Added
CC||ekurzin...@nvidia.com
--- Comment #7 from
https://bugs.kde.org/show_bug.cgi?id=450914
--- Comment #25 from Erik Kurzinger ---
So I did look into this a bit further, and can provide some hopefully relevant
information...
Firstly, I noticed that, unfortunately, direct scan-out for Xwayland
applications doesn't work at all with our driver
https://bugs.kde.org/show_bug.cgi?id=471559
Erik Kurzinger changed:
What|Removed |Added
CC||ekurzin...@nvidia.com
--
You are receiving
https://bugs.kde.org/show_bug.cgi?id=471559
--- Comment #2 from Erik Kurzinger ---
I've determined that this is a bug in the NVIDIA EGL library. Kwin is not doing
anything wrong, we're just not correctly processing the dma-buf feedback that
it sends us.
--
You are receiving this mail because
32 matches
Mail list logo
