Bug 59086

Its crystalspace3d 2.0/2.2 as a PS developer told me.

Hi Martin,

Have you compiled PlaneShift from SVN?  I don't see a 0.5.9.3 on their website...only 0.5.9.2.

For what it's worth, disabling GLSL should only be useful on old, non-programmable Intel hardware, like GMA950/945/Pineview.  I would highly recommend using GLSL on Sandybridge.  That said, from your description it sounds like there are issues when running with GLSL.  I'll try to reproduce those.

Thanks for the detailed information.  Having the exact graphics setting you used is very helpful.

I'll try and take a look soon.

Kenneth, thank you very much for your answer. No I didn´t compile from SVN, but the client can update itself. It offered two client updates after I first installed it. So I suggest, you just try it and see whether it offers you an update and let it install it.

Note that the first client version I tried, I think it was 0.5.9.1, had working grass, whereas in current clients it flickers, also on other graphics cards, so you may want to disable it[1].

Disabling GLSL gave me beautiful textures where there only have been single colored areas or wierd psychedelic patterns. I think I can dig out two screenshots for comparison and I am willing to provide a separate bug report for this if you want.

As for gfx settings I noted them in my bug report in detail. If there is something missing please tell me. My X.org configuration is minimal:

merkaba:~> cat /etc/X11/xorg.conf.d/anzeige.conf 
Section "Device"
        Identifier      "Grafikkern"

        Driver          "intel"

        # Monitore
        Option          "Monitor-LVDS1" "Notebook-Display"

        # Optionen
# [Bug 54195] [sna] crashes sometimes with two KDE sessions
# https://bugs.freedesktop.org/show_bug.cgi?id=54195
        Option          "AccelMethod"   "sna"

EndSection

Section "Monitor"
        Identifier      "Notebook-Display"

        DisplaySize     340 192
EndSection

The crash mentioned in the config does not seem to happen anymore, I will close this bug report, if not already done.

[1]http://www.hydlaaplaza.com/flyspray/index.php?opened=1484&type[0]=&sev[0]=&due[0]=&cat[0]=&status[0]=open&percent[0]=&reported[0]=&sort=asc&do=details&task_id=5805

Thanks,
Martin

Alright, I can reproduce this (albeit on Ivybridge).  I cast Defensive Wind and immediately got 99% CPU usage...basically all in a swrast CopyTexSubImage fallback.

Which is odd, because something extremely similar happened a year ago and I fixed it then.  I'll continue investigating.

The game is attempting to CopyTexSubImage between two MESA_FORMAT_X8_Z24 buffers, which are Y-tiled.

Currently we only have two implementations of CopyTexSubImage: first we try the GPU's BLT engine, and then fall back to the meta/software path.  Right now our BLT path can't handle Y-tiled buffers, so we're forced to software.

Now I remember the problem: I wrote some preliminary patches to do Y-tiled blits, but they were broken and rejected.  Paul's blorp engine can handle this, we just need to adapt it to work for CopyTexSubImage in addition to BlitFramebuffer.

Kenneth, great, I love it, thanks. In case you have anything for testing, just tell me, and I might try to make a new xserver-xorg-video-intel package for my Debian Sid install. Also please tell me whether you want me to file a bug regarding disabling GLSL. In case you want to the a gross difference just go into the Laanx temple in Hydlaa, reachable from the plaza, with your char. Thanks, Martin

Here's a preliminary spin of a patch to fix the issue:
http://lists.freedesktop.org/archives/mesa-dev/2013-January/033013.html

Kenneth, this makes a huge difference. I had to build mesa 9 packages for Debian Sid from their git, the patch did apply with some offsets, but Planeshift didn´t start. Then I applied your patch to fdo mesa git master where it applied without offsetting. This worked. I also build a current xserver-xorg-video-intel package 2.20.18 instead of 2.20.14 from Debian git, but I am not sure whether this was necessary. This is with Linux 3.8-rc4 now.

Thus I now have:

- mesa git master at f9f5c92f734c517c1bd486f5a3b1931ea6f871a5
- + the patch (I also subscribed to mesa-dev now)
- on top of

martin@merkaba:~> dpkg -l | egrep "(mesa|xserver-xorg-video-intel)" | cut -c1-70
ii  libgl1-mesa-dev                        9.0.1-1~test               
ii  libgl1-mesa-dri:amd64                  9.0.1-1~test               
ii  libgl1-mesa-glx:amd64                  9.0.1-1~test               
ii  libglapi-mesa:amd64                    9.0.1-1~test               
pi  libglu1-mesa:amd64                     8.0.5-3                    
ii  libopenvg1-mesa:amd64                  9.0.1-1~test               
ii  mesa-common-dev                        9.0.1-1~test               
ii  mesa-utils                             8.0.1-2+b3                 
ii  xserver-xorg-video-intel               2:2.20.18-1                
ii  xserver-xorg-video-intel-dbg           2:2.20.18-1

Observed results:
- spell effects are way faster
- defensive wind and flame spire work faster than ever before
- CPU during flame spire which makes a huge cloud of fire is between 12-20%
  I think it was similar with defensive wind.

It is a tad bit jerky on certain spell effects still, but this works way better than before. This is a huge improvement. PS is playable with enabled spell effects now on Sandybridge. A bit jerky still sometimes, but playable.

I had to remove

Video.OpenGL.UseExtension.GL_ARB_shader_objects = false

from planeshift.cfg, otherwise Planeshift didn´t start. So this is with using GLSL.

Also GLSL is way better: The differing gfx output I described above is gone. I see textures where with Mesa 8 with GLSL has just been blank areas or psychedelic patterns. I have the impression that with GLSL and Mesa 9 in high detail areas like the Red Crystal Den´s it is a bit more jerky than before.


Feel free to link to this bug report in your commit message and add my 

Tested-by: Martin Steigerwald <martin@lichtvoll.de>

Thank you,
Martin

Let me comment on the jeckyness. It does not seem to be related to the spells. I now had four spells simultaneously. Two from my char and two from another char with 50% CPU usage. Fluently!

I raised minimum FPS cap from 35 to 40. Maybe will go to 50 to see whether it makes a difference.

(In reply to comment #8)
> Kenneth, this makes a huge difference. I had to build mesa 9 packages for
> Debian Sid from their git, the patch did apply with some offsets, but
> Planeshift didn´t start. Then I applied your patch to fdo mesa git master
> where it applied without offsetting. This worked. I also build a current
> xserver-xorg-video-intel package 2.20.18 instead of 2.20.14 from Debian git,
> but I am not sure whether this was necessary. This is with Linux 3.8-rc4 now.

The 2D driver (xserver-xorg-video-intel/xf86-video-intel) version shouldn't matter.  Just Mesa.

> Observed results:
> - spell effects are way faster
> - defensive wind and flame spire work faster than ever before
> - CPU during flame spire which makes a huge cloud of fire is between 12-20%
>   I think it was similar with defensive wind.
> 
> It is a tad bit jerky on certain spell effects still, but this works way
> better than before. This is a huge improvement. PS is playable with enabled
> spell effects now on Sandybridge. A bit jerky still sometimes, but playable.

Excellent.  If there's something in particular that triggers a slowdown that you'd like me to look at, just let me know.  Sadly, it looks like the main performance gains might come from optimizing Crystal Space though.

> Also GLSL is way better: The differing gfx output I described above is gone.
> I see textures where with Mesa 8 with GLSL has just been blank areas or
> psychedelic patterns.

Great.  I'm glad it's working now.

> I have the impression that with GLSL and Mesa 9 in
> high detail areas like the Red Crystal Den´s it is a bit more jerky than
> before.
> 
> Feel free to link to this bug report in your commit message and add my 
> 
> Tested-by: Martin Steigerwald <martin@lichtvoll.de>
> 
> Thank you,
> Martin

Will do.  Thanks!

Kenneth, I found that after I updated mesa from 8 to 9.0.1 + your patch I have something strange in X.org:

Samples: 150K of event 'cycles', Event count (approx.): 75195405698                                         
 70,89%  libc-2.13.so                                                 [.] __memcpy_ssse3                   ◆
  8,09%  psclient.bin                                                 [.] 0x0000000000d99fcb               ▒
  2,88%  i965_dri.so                                                  [.] 0x000000000003113d               ▒
  0,83%  libdrm_intel.so.1.0.0                                        [.] 0x0000000000008164               ▒
  0,74%  libspeexdsp.so.1.5.0                                         [.] 0x0000000000009bc3               ▒
  0,46%  [kernel]                                                     [k] lzo1x_decompress_safe            ▒
  0,42%  libc-2.13.so                                                 [.] __memmove_ssse3                  ▒
  0,36%  libc-2.13.so                                                 [.] _int_malloc                      ▒
  0,32%  libpthread-2.13.so                                           [.] pthread_mutex_lock   

It is spinning on 75-90% CPU.

This just happened after running PS for a while.

Could that be related to your patch? Maybe not, cause the dri driver is only listed with 3%.

Immmediately gone after ending PS.

I already downngraded xf86-video-intel to 2.20.14 due to severe issues with SNA on the newer one. I now also have refresh issues, but only after having played PS for a while. Using SNA on 2.20.14 has been without issues until then.

After once triggered I just have to start PS till the screen where I can login. Immediately X.org goes up to 95% CPU.

Sorry, need to send, cause SNA messes up heavily with iceweasel text input field.

Thanks

Marti

Well after a reboot it doesn´t trigger after the first spell effect being cast. And the SNA refresh issues appear to be unrelated. I have wierd SNA refresh issues but X.org is still behaving fine CPU-wise.

I will just disable SNA again and next occassion just to really test whether there is no relation ship. It doesn´t work really nicely anyway here at the moment after having worked for weeks.

Okay, all I can say is that this CPU hog issue doesn´t seem to happen without SNA. I still get some slight flickering that I did you see before.

As for sluggyness in game I has an area, the Red Crystal Den´s. I can explain you where it is.

But my suggestion is: Keep this for the spell effects and thus close it, cause they are really fast enough. I will open requests for other things I find. Unless of course the SNA issues and the patch might be related, which I doubt meanwhile.

Do you happen to know in which mesa version your fine patch will be? 9.1?

Bug 60172 - Planeshift: triangles where grass would be

may be related to the patches fixing the spell effects issue. Or not. And then related to the switch from mesa 8.0.5 to 9.x or the enabling of GLSL.

Fixed in master by:

commit 0b3bebbaacf42ae07f712b5693f7b00fad3ff35e
Author: Kenneth Graunke <kenneth@whitecape.org>
Date:   Tue Jan 15 22:17:23 2013 -0800

    i965: Implement CopyTexSubImage2D via BLORP (and use it by default).

    ...

Thanks for your help testing all of this, Martin.