Application Windows Flickering, black surrounding windows, or blank (black) app window

I guess I could’ve put this in application sub, but seems to have a crossover with this one. I’ve also submitted a bug report with this same title.

The latest update to 6.6.2 (?) completely breaks my application windows. Brave browser won’t render any images, just displays some colors, or has window echoing. My VPN app doesn’t generate at all, just a black window.

I’m using KDE. Gnome was way worse. Rolled back to 6.6.1-1, and don’t have any issues. Attempted a reinstall of the update, and got same problem.

00:02.0 VGA compatible controller: Intel Corporation HD Graphics 5500 (rev 09)
04:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Opal PRO [Radeon R7 M260X]

Welcome to the openSUSE forums.

It is always good to provide a link to the bug report. Then people with the same can add information and follow waht is happening there.

1 Like

I’m new to the forums which you mentioned…so it appears I missed the ‘edit’ window. Here is the bugzilla link. Thanks.

https://bugzilla.opensuse.org/show_bug.cgi?id=1217467

You can’t edit your posts (after a few minutes). This to avoid nonsensical threads like it would have been if you add the link to the first post here and me asking for it in the second.

Thanks for the link.

1 Like

Sounds a little bit like
https://bugzilla.opensuse.org/show_bug.cgi?id=1214274

1 Like

Would this shader cache issue effect most app windows? As mentioned, my VPN (Mullvad) window was just completely black. In KDE I could at least use Konsole, but in Gnome, even the Konsole window was almost unusable. Text would appear to almost write over each other, or the refresh (?) of the text unreadable.

Video card/driver??? If NVIDIA then drivers are often behind kernels in TW

Read the first post…

/usr/sbin/hwinfo --gfxcard
21: PCI 400.0: 0300 VGA compatible controller (VGA)
[Created at pci.386]
Unique ID: YmUS.gj5DKYAcvKA
Parent ID: QSNP.+JiugkQ5HD6
SysFS ID: /devices/pci0000:00/0000:00:1c.4/0000:04:00.0
SysFS BusID: 0000:04:00.0
Hardware Class: graphics card
Model: “ATI Opal PRO [Radeon R7 M260X]”
Vendor: pci 0x1002 “ATI Technologies Inc”
Device: pci 0x6605 “Opal PRO [Radeon R7 M260X]”
SubVendor: pci 0x103c “Hewlett-Packard Company”
SubDevice: pci 0x2258
Driver: “radeon”
Driver Modules: “radeon”
Memory Range: 0xa0000000-0xafffffff (ro,non-prefetchable)
Memory Range: 0xc1000000-0xc103ffff (rw,non-prefetchable)
I/O Ports: 0x3000-0x30ff (rw)
Memory Range: 0xc1040000-0xc105ffff (ro,non-prefetchable,disabled)
IRQ: 47 (65 events)
Module Alias: “pci:v00001002d00006605sv0000103Csd00002258bc03sc00i00”
Driver Info #0:
Driver Status: radeon is active
Driver Activation Cmd: “modprobe radeon”
Driver Info #1:
Driver Status: amdgpu is active
Driver Activation Cmd: “modprobe amdgpu”
Config Status: cfg=new, avail=yes, need=no, active=unknown
Attached to: #20 (PCI bridge)

22: PCI 02.0: 0300 VGA compatible controller (VGA)
[Created at pci.386]
Unique ID: _Znp.chQ+KYVH9E2
SysFS ID: /devices/pci0000:00/0000:00:02.0
SysFS BusID: 0000:00:02.0
Hardware Class: graphics card
Device Name: “32”
Model: “Hewlett-Packard Company ZBook 15u G2 Mobile Workstation”
Vendor: pci 0x8086 “Intel Corporation”
Device: pci 0x1616 “HD Graphics 5500”
SubVendor: pci 0x103c “Hewlett-Packard Company”
SubDevice: pci 0x2216 “ZBook 15u G2 Mobile Workstation”
Revision: 0x09
Driver: “i915”
Driver Modules: “i915”
Memory Range: 0xc0000000-0xc0ffffff (rw,non-prefetchable)
Memory Range: 0xb0000000-0xbfffffff (ro,non-prefetchable)
I/O Ports: 0x6000-0x603f (rw)
Memory Range: 0x000c0000-0x000dffff (rw,non-prefetchable,disabled)
IRQ: 48 (1203773 events)
Module Alias: “pci:v00008086d00001616sv0000103Csd00002216bc03sc00i00”
Driver Info #0:
Driver Status: i915 is active
Driver Activation Cmd: “modprobe i915”
Config Status: cfg=new, avail=yes, need=no, active=unknown

Primary display adapter: #21

The browser issue is somewhat common after a specific update of an app/library (I suspect an update to LLVM). The side-effects of an update affects Chromium-based browsers (Chrome, Brave, etc) and some apps.

Read this Reply … deleting the GPUCache sub-dir does no harm - it’s simply removing a specific cached sub-dir that will be recreated upon the next fire up of the app.

.

2 Likes

@myswtest That worked, thank you. Ran the find & rm command (there was only 3 anyway) and restarted. Posting this in Brave and my VPN window now generates per usual.

Hopefully I don’t have to do this at every update. We’ll see I guess.

As a matter of mechanics, I’d like to close this out, and the bugzilla. Should I reference that thread for the fix? Thanks again!

1 Like

I marked the bugzilla ticket fixed and referenced the mentioned thread. This can also be closed, thanks again everyone.

2 Likes

Just to be clear … when you delete the GPUCache sub-dirs, no need to restart the operating system… simply delete the sub-dirs, and then fire up the browser(s) afterwards … the fix is immediate. :+1:

1 Like

With 6.6.3 - I did not have to repeat these steps. Looks like a one-off issue.

I wouldn’t classify it as a “one off issue”. In the last 6 months, I’ve seen it 5-6 times. I forget the name of the library now, but whenever it gets updated, this GPUCache issue rears up.

I believe I found this solution out in an Opera forum. I’ve never seen the issue with Firefox, as it’s not a Chromium based browser.

And I’ve experienced this issue not just with AMD graphics oriented machines - I have a laptop with Intel UHD based, and it has seen the issue on some occasions.

I simply copied the rm command line from my history and run it when the issue shows up. In less than 5 seconds, the prob is solved.

user@home:~> find ~/ -type d -name GPUCache -exec rm -rf {} +
1 Like

This name of the package is “Mesa” as mentioned in the Bugzilla link posted above.

And a more sane way is to only delete the GPUcache of the affected application and not all GPUCaches in your home directory…
Chromium:

rm -rf ~/.config/chromium/Default/GPUCache/

Google-Chrome:

rm -rf ~/.config/google-chrome/Profile 1/GPUCache/

The GPUCache issue was also affecting my MullvadVPN window. The contents never generated, just a black/blank window.

… Quote from @hui:
This name of the package is “Mesa” as mentioned in the Bugzilla link posted above.
… end quote

Yea, I think I’ve seen on my laptop where Mesa is the culprit, but I’ll pay attention next time I do a zypper dup.

However, l just did a zypper dup on my 2 desktops - I noticed updates for “libLLVMxx” (where xx is the version, such as 15, 16, 17). On the first desktop, I allowed all 3 LLVM libs to be updated (libLLVM15, libLLVMx16, libLLVM17). The Chromium-based browser rendering issue reared its ugly head … so I had to delete the GPUCache subdirs.

So, I fired up the 2nd desktop unit, and THIS time, I marked libLLVM15, libLLVMx16, and libLLVM17 to be Protected, and then did a zypper dup. Tested Brave and Chrome - no issue.

Then I allowed libLLVM15 to be updated. Tested Brave and Chrome - no issue. Then I allowed libLLVM16 to be updated. Tested Brave and Chrome - no issue.

Then I allowed libLLVM17 to be updated. Tested Brave and Chrome - the issue showed up - both browsers could not render web pages properly, so deleted their GPUCache sub-dirs. So, the problem on SOME machines (at least on my machines), it’s libLLVM17 that causes the rendering problem.

I also updated my laptop just now, that has libLLVM17, and it does NOT have the rendering issue. (However, I think Mesa does cause the issue on the laptop, not desktops, which is almost certain to be because of the difference of graphics hardware).

BTW, in the bug link above, Mesa is NOT mentioned (and that issue has been closed by the author) … it’s the bug referred to by Takashi Iwai “a similar report in bug https://bugzilla.opensuse.org/show_bug.cgi?id=1217484”, where it is mentioned.

The bug (which names clearly Mesa) is mentioned in my comment…