Bug 293325 - [NPOT] kwin shadows broken on R200 Radeon graphics cards
Summary: [NPOT] kwin shadows broken on R200 Radeon graphics cards
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 4.8.0
Platform: Archlinux Linux
: NOR normal with 1 vote (vote)
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-04 21:29 UTC by Luke
Modified: 2012-02-10 09:25 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
r200 with KDE 4.8 (91.23 KB, image/png)
2012-02-04 21:29 UTC, Luke
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Luke 2012-02-04 21:29:33 UTC
Created attachment 68500 [details]
r200 with KDE 4.8

Version:           4.8.0 (using KDE 4.8.0) 
OS:                Linux

Hi, I was playing a little with portable linux on usb-hdd and while working on my dad's pc I noticed that shadows are broken (menu shadows, tooltips, classic kmenu etc), it was just before 4.8 release so I decided to wait and see if it's fixed, unfortunately not (but situation is way better on 4.8 than on 4.7.4 - see screenshot: http://bayimg.com/eAmidAadG)

on 4.7.4 - whole decorations was broken (along with windows shadows)
in 4.8   - just shadows of menus/tooltips etc. are broken (windows shadows are ok)

PS R200 in this case means Radeon 9200 with 128VRAM - translucency effect on this is not usable, moving windows is like in slow-motion - good news are: after disabling most of the effects composition on this hardware (along with 750MB of RAM and P4 Prescott 2.4GHz) is working very well :)

Reproducible: Always

Steps to Reproduce:
Enable composition on system with R200 graphics card and xf86-video-ati drivers


Expected Results:  
Proper shadows

$ glxinfo | grep -i render

direct rendering: Yes
OpenGL renderer string: Mesa DRI R200 (RV280 5961) x86/MMX/SSE2 TCL DRI2
Comment 1 Thomas Lübking 2012-02-04 22:08:52 UTC
likely bug #282882
add a shellscript to ~/.kde/env

---- snip: qt-graphicssystem.sh  ----------
#!/bin/sh
export QT_GRAPHICSSYSTEM=native
--- /snip -----------------------

log out/in report the outcome.
Comment 2 Luke 2012-02-04 22:59:38 UTC
Thanks, I've switched to QT_GRAPHICSSYSTEM=native but unfortunately with no success. https://bugs.kde.org/show_bug.cgi?id=282882 I was hurting from this issue but in 4.7.4, now everything is fine except menu shadows/tooltips (button tooltips, task manager shadows are fine - strange)
Comment 3 Thomas Lübking 2012-02-04 23:09:44 UTC
Ok, sorry. I clicked the link in the post and missed the attachment.
Looks more exactly like bug #280116 - still an NPOT issue :-\

The way the oygen decoration shadows and the popup shadows are generated differs a bit.
If you can install bespin and select it's decoration you will most likely encounter the same issue for the decoration shadows, yesno?
Comment 4 Luke 2012-02-05 19:42:35 UTC
Yeah, bespin is all broken:

http://bayimg.com/gAMOMaadg
Comment 5 Luke 2012-02-05 19:58:16 UTC
Oh gosh I messed up, i just realized that I had qt_graphicsystem=native from the begging, now with raster I have whole oxygen broken also just as it was in 4.7.4

to sum up:
native & oxygen = broken only tooltips/menus
raster & oxygen = all shadows broken + messed up decorations just like in Bug 282882

native & bespin = all shadows broken, but decorations ok
raster & bespin = same as raster & oxygen
Comment 6 Thomas Lübking 2012-02-06 02:36:49 UTC
They're probably all the same issue.

Unfortunately afaik we don't have access to an r200 chip and i can't try on the FX5200 unless nvidia releases drivers for the current X11 version (since nouveau does not suffer from this issue and "breaking" NPOT here had no effect, the nvidia driver probably treats NPOT and rect ARB textures the same internally :-(

fglrx does probably not support that chip anymore, does it? (so you could test whether it occurs there as well or rect textures are just broken in ati and legacy nvidia)

FTR: do we know whether this also affects R200 chips (since the 9200 is actually an RV280 chip and the RV significantly differs from the R series - cheaper design ;-)

@Martin:
maybe we can just check whether NPOT is supported and otherwise just prescale the shadow pixmaps to make the shadow texture POT and fix the offsets?
Comment 7 Luke 2012-02-06 12:22:35 UTC
fglrx supports HD2xxx and newer Radeons afaik

You're right 9200 is rv280 chip, as we are on that - maybe some fund-raising? Older cards are fairly cheap - used & working rv280 card is <10euro so we could gather some older hardware to kwin team as play/test ground. Maybe working on optimizations for older hardware will bring some improvements on newer hardware also? - people just love that. I know this is not high priority so we need to decide if it's worth the effort. 

BTW if it doesn't make sense on r200/rv280 era of hardware maybe you need not-so-old cards for testing? I've finished Doom3 on GeForce2 MX 200 for crying out loud :D so I think that moving 2D windows on better cards shouldn't be so problematic ;)
Comment 8 Martin Flöser 2012-02-06 14:08:04 UTC
> You're right 9200 is rv280 chip, as we are on that - maybe some 
> fund-raising?
> Older cards are fairly cheap - used & working rv280 card is <10euro
> so we could
> gather some older hardware to kwin team as play/test ground.
Getting the cards is not the issue. Getting them into the system is the 
problem. Even the oldest hardware I have around does not have an AGP or 
PCI socket any more. Using a system so old that it could carry such a 
card would be so slow on compiling that I would not even want to do it, 
even if I were paid to do it.
> Maybe working on
> optimizations for older hardware will bring some improvements on
> newer hardware
> also?
No, they are too special to have any advantage for newer hardware. More 
likely disadvantage due to additional code pathes
Comment 9 Martin Flöser 2012-02-06 19:51:10 UTC
> @Martin:
> maybe we can just check whether NPOT is supported and otherwise just
> prescale the shadow pixmaps to make the shadow texture POT and fix the
> offsets?
That could work. IIRC we used to increase the texture size for non-NPOT in 
some places...
Comment 10 Thomas Lübking 2012-02-07 00:56:14 UTC
Ok, i probably have it.

The texture is prescaled anyway in the NPOT case and because of that and the packed format we cannot use the texture dimensions as divisor but MUST use the calculations used when creating the texture (before scaling)

The scaling apparently still causes some glitches (probably again because of the packed format resulting in false interpolation values - i'll test that tomorrow) but it's nowhere like just scaling the texture and using the texture dimensions.

@lukasas
can you try a patch (ie. have the kwin sources, apply the patch and recompile kwin)?
Comment 11 Luke 2012-02-07 17:21:12 UTC
> @lukasas
> can you try a patch (ie. have the kwin sources, apply the patch and recompile
> kwin)?

Yeah, shouldn't be a problem but you need to guide me step by step as I never aplied a patch ;) (don't worry I not total noob)
Comment 12 Thomas Lübking 2012-02-07 17:41:46 UTC
get the kde-workspace/kwin sources

git clone git://anongit.kde.org/kde-workspace

next fetch this patch:
https://bugs.kde.org/attachment.cgi?id=68592

copy it into the kde-workspace/kwin directory and apply it
patch -p2 < __fix_NPOT_shadows.diff

leave the kwin directory and "mkdir BUILD" in kde-workspace, enter the BUILD dir
ccmake ..
press c [optionally deselect everything you don't actually  want to compile and press c again]
press g
wait ;-)
cd kwin
make && sudo make install
Comment 13 Luke 2012-02-07 20:37:14 UTC
OK, on patched Kwin: oxygen + raster + compositing = very nice working windows shadows but crash and fallback when any kind of tooltip is about to show up
Comment 14 Luke 2012-02-07 20:44:48 UTC
and backtrace (strangely short)

http://pastebin.com/FUcpvsPf
Comment 15 Thomas Lübking 2012-02-07 21:39:10 UTC
stack corruption

umm ... "git branch" - if "master" has a leading asterisk
-> "git reset --hard HEAD; git checkout KDE/4.8"
reapply the patch and recompile, sorry - didn't think of that...
Comment 16 Luke 2012-02-08 13:38:04 UTC
OK, with new build:

oxygen + raster + compositing = very nice working windows shadows: http://bayimg.com/BAmNKaadH

no crash on tooltips :)

small glitches (on classic menu, firefox, dolphin menus etc, looks like buttons tooltips are not affected(?)): http://bayimg.com/BAmnLAaDH

no shadows under panel tooltips and kickoff menu

other than that: user experience way better than with broken shadows ;) (any performance hit because of patch?)
Comment 17 Thomas Lübking 2012-02-08 17:37:34 UTC
no, actually it might get faster - i'm not sure why we pot scale the texture if GL_ARB_texture_rectangle is supported though.


While at it, you could try what happens if you manipulate the end of the patch file

delete m_texture;
- m_texture = new GLTexture(image);
+ m_texture = new GLTexture(image, GL_TEXTURE_RECTANGLE_ARB);


This patch should also resolve the remaining glitches
http://git.reviewboard.kde.org/r/103888/
Comment 18 Luke 2012-02-09 13:24:38 UTC
After new patch: everything seems fine :) window shadows ok, no crashes whatsoever, tooltips and menu shadows ok, no glitches on menu shadows but they remain in logout/shutdown popups: http://bayimg.com/mAMcEaadi

I noticed sluggish window moving if windows are big, small windows moving very fast/responsively, the bigger window the slower it becomes to move (it could be due hardware limited powers, I'll test this on official kwin from repos later)

New patch with edited last lines: I would say the same as above, maybe sluggishness of big windows is more noticeable (but it can be autosuggestion)

PS should I uninstall/make clean or something like that before installing kde workspace from repos? Also I didn't do anything like that before each of next tests - just new compilation and installation + reboot to be sure - hope this doesn't messed up results(?)

PSS on applying edited patch I get: 

patching file scene_opengl.cpp
Hunk #9 succeeded at 1684 with fuzz 2.

don't know what this mean, but everything went fine without errors
Comment 19 Luke 2012-02-09 13:53:31 UTC
OK I got this, about sluggishness:

it's matter of refresh rate, this PC is hooked up to CRT display, with 60Hz window moving even big ones is always responsive, on 85Hz big windows can be sluggish to move (tested with or without v-sync enabled through KCM)

this tests can be inaccurate cause this PC need more RAM for KDE (512MB is not enough and a lot of swapping occurs but this refresh thing seems to be always reproducible)
Comment 20 Thomas Lübking 2012-02-09 17:16:37 UTC
(In reply to comment #18)
> remain in logout/shutdown popups: http://bayimg.com/mAMcEaadi
I'm not sure whether this are already "new" shadows or stuff painted into the ARGB window by the plasma theme. It's afaik however intended to ultimately pipe all shadow rendering through the affected code.

> I noticed sluggish window moving if windows are big, small windows moving very
> fast/responsively, the bigger window the slower it becomes to move
Because more of the screen has to be updated - it's a matter on how powerful your system (GPU) is. You should probably rather disable effects like blur (if that is supported on that GPU at all)

> New patch with edited last lines: I would say the same as above, maybe
> sluggishness of big windows is more noticeable (but it can be autosuggestion)
The rect textures might be considerably slower than the POT ones on old GPUs, yes (i guess that's why it's not used)

> PS should I uninstall/make clean or something like that before installing kde
> workspace from repos?
No, the files should just be overridden by the packager.

> tests - just new compilation and installation + reboot to be sure - hope this
> doesn't messed up results(?)
No. Indeed restarting "kwin --replace &" would have done ;-)

> patching file scene_opengl.cpp
> Hunk #9 succeeded at 1684 with fuzz 2.
i don't know what you edited, but if you edited the patch file by just adding that string it likely didn't work (those outer lines are only for the patch system to identify/ensure the correct location) - best look up kwin/scene_opengl.cpp and inject the string there.

(In reply to comment #19)
> it's matter of refresh rate, this PC is hooked up to CRT display, with 60Hz
> window moving even big ones is always responsive, on 85Hz big windows can be
you can attempt to force a refreshrate (in case it's misdetected/reported)

kwriteconfig -file kwinrc -group Compositing -key RefreshRate 85
qdbus org.kde.kwin /KWin reconfigure
qdbus org.kde.kwin /KWin toggleCompositing
sleep 1
qdbus org.kde.kwin /KWin toggleCompositing

BE WARNED that this hardcodes the refreshrate, it will not adapt to further changes anymore.
To deactivate the hardcoded refreshrate, set it to "0" or remove the key from ~/.kde/share/config/kwinrc (kwriteconfig has no delete option)
Comment 21 Thomas Lübking 2012-02-09 18:06:14 UTC
Git commit 7355a9ad14e24ca1eb4088430950bc88f03fb4de by Thomas Lübking.
Committed on 08/02/2012 at 19:31.
Pushed by luebking into branch 'KDE/4.8'.

fix NPOT shadows

a) fixes the texture offset calculation
b) arranges he shadow pixmaps as border in the texture to avoid interpolation issues.
Related: bug 280116, bug 282882, bug 291161
REVIEW: 103888

M  +33   -53   kwin/scene_opengl.cpp

http://commits.kde.org/kde-workspace/7355a9ad14e24ca1eb4088430950bc88f03fb4de
Comment 22 Thomas Lübking 2012-02-09 18:07:56 UTC
Git commit 4281fd09be344bfa99b0450eae384b49b55db152 by Thomas Lübking.
Committed on 08/02/2012 at 19:31.
Pushed by luebking into branch 'master'.

fix NPOT shadows

a) fixes the texture offset calculation
b) arranges he shadow pixmaps as border in the texture to avoid interpolation issues.
Related: bug 280116, bug 282882, bug 291161
REVIEW: 103888

M  +33   -53   kwin/scene_opengl.cpp

http://commits.kde.org/kde-workspace/4281fd09be344bfa99b0450eae384b49b55db152
Comment 23 Luke 2012-02-09 18:14:32 UTC
(In reply to comment #20)
> Because more of the screen has to be updated - it's a matter on how powerful
> your system (GPU) is. You should probably rather disable effects like blur (if
> that is supported on that GPU at all)
I thought so, but this refresh thing is interesting. Of course I've disabled almost all effects, no heavy effects, transparency etc. Blur is not supported but I don't like it anyway ;)


> i don't know what you edited, but if you edited the patch file by just adding
> that string it likely didn't work (those outer lines are only for the patch
> system to identify/ensure the correct location) - best look up
> kwin/scene_opengl.cpp and inject the string there.
I "manipulated the end of the patch file", but I will try direct way tomorrow

> you can attempt to force a refreshrate (in case it's misdetected/reported)
I wasn't clear enough: I use openbox and KDE on USB disk, so refresh rate is often reseted to default 60Hz, I have no problem to set 85Hz, but with 85Hz sluggishness occurs - no such effect on 60Hz

How to test this pop-ups? different plasma themes?
Comment 24 Thomas Lübking 2012-02-09 18:29:35 UTC
The reported issue is fixed, isn't? (i really can't say about the plasma thing atm)
Please do not turn this into a "kwin is  sluggish" report but in doubt open a new one.

(In reply to comment #23)
> > you can attempt to force a refreshrate (in case it's misdetected/reported)
> I wasn't clear enough: I use openbox and KDE on USB disk, so refresh rate is
> often reseted to default 60Hz, I have no problem to set 85Hz, but with 85Hz
> sluggishness occurs - no such effect on 60Hz
the setting in kwin is not directly related to the xrandr setting. esp. if you change the refreshrate after starting KDE you maybe should attempt to enforce this value (in case the change is somehow not catched)

Also notice that the GPU needs to pump out the framebuffer ~1.41 times as often with the higher refreshrate what -depending on the architecture- might simply drain resources from other buffer processing (same goes oc for higher resolutions) - the GPU also might be "optimized" towards typical LCD rates and it's eg. rather common that throughput drops a lot when accessing two screens (and esp. with different clocks, ie. refresh rates)
Ie. if this is a notebook and the internal display has 60Hz and you attach it to an external @85Hz and the internal is not unregistered from the GPU (so it actually still supplies both) this causes heavy load (more than if the two screens run at equal clock speeds or one is a full multiple of the other, ie. eg. 60Hz & 120Hz)

> How to test this pop-ups? different plasma themes?
Do an " xprop | grep _KDE_NET_WM_SHADOW" on that window. If there's no output, you need to file a bug against (lib)plasma - tell them texture packing is evil if one uses some (bi)linear scaling somewhere =)
Comment 25 Donatas Glodenis 2012-02-09 20:51:29 UTC
I applied this patch: http://git.reviewboard.kde.org/r/103888/ , recompiled, and yes, no glitches, not even traces (like after the last patch I tried). Thank you again, Thomas. Good to see the old hardware is not abandoned. By the way, I had to recompile all kde-workspace again :( and therefore I have a debian package for kwin here: http://dg.lapas.info/share/kde-window-manager_4.7.4-0ubuntu0.2_i386.deb (it installs only using command dpkg -i --force-depends kde-window*.deb , because I messed unsuccessfully with version numbers..)
Comment 26 Luke 2012-02-09 21:19:48 UTC
(In reply to comment #24)
> The reported issue is fixed, isn't? (i really can't say about the plasma thing
> atm)
> Please do not turn this into a "kwin is  sluggish" report but in doubt open a
> new one.
I don't want to do that, just want to be sure that there is no regression.

> with the higher refreshrate what -depending on the architecture- might simply
> drain resources from other buffer processing 
You are right, after some more testing it seems that GPU is running out of juice (still it's crazy, it should be able to handle window moving, I know its old card but if someone would tell me 9years ago that card which is capable of many 3D games like UT2003 is to slow to display 2D windows... - end of personal opinion)

> Do an " xprop | grep _KDE_NET_WM_SHADOW" on that window. If there's no output,
> you need to file a bug against (lib)plasma - tell them texture packing is evil
> if one uses some (bi)linear scaling somewhere =)
Yeah, it didn't return anything, I'm gonna fill report and because I don't understand this technical stuff to much I'll link to this thread also

Anyway, that was my best bug report so far and very pleasing dev-user experience, thank you for your patience and guidance :) Much appreciate your work (and not only yours), regards.
Comment 27 Thomas Lübking 2012-02-09 22:44:59 UTC
(In reply to comment #26)
> You are right, after some more testing it seems that GPU is running out of
> juice (still it's crazy, it should be able to handle window moving, I know its
> old card but if someone would tell me 9years ago that card which is capable of
> many 3D games like UT2003 is to slow to display 2D windows... - end of personal
> opinion)
Different demands. Shooters need fast T&L, Z buffer clipping, maybe shaders while the WM needs  much memory and fast memory throughput (esp. when you played @ 1024x768 but run the desktop @ 1920x1200)

It probably also doesn't help that the texture_from_pixmap conversion (that maps between X11 and OpenGL) creates rectangular textures when "supported" (while games will always come with rather small POT textures) - even if that doesn't mean "supported to be fast"

Eg. get kmquake2 - will certainly run nice. Then get the hires texture pack ....
Comment 28 Luke 2012-02-10 09:25:22 UTC
(In reply to comment #27)
> Different demands. Shooters need fast T&L, Z buffer clipping, maybe shaders
> while the WM needs  much memory and fast memory throughput (esp. when you
> played @ 1024x768 but run the desktop @ 1920x1200)
> 
> It probably also doesn't help that the texture_from_pixmap conversion (that
> maps between X11 and OpenGL) creates rectangular textures when "supported"
> (while games will always come with rather small POT textures) - even if that
> doesn't mean "supported to be fast"

Everyday something new to learn, thanks :)