Bug 71813 - some apps or games are terribly slow
Summary: some apps or games are terribly slow
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/Acceleration/glamor (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Zhigang Gong
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-11-19 23:04 UTC by Damian Nowak
Modified: 2014-02-06 19:31 UTC (History)
12 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Speed up glamor_copy_area for certain use cases (6.99 KB, patch)
2014-01-01 04:21 UTC, Anthony Waters
no flags Details | Splinter Review
OpenTTD black rectangles (1.99 MB, image/png)
2014-01-17 21:11 UTC, Anthony Waters
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Damian Nowak 2013-11-19 23:04:42 UTC
Some apps are terribly slow. They also make the whole system perform very weak. Once such an app is run, all other applications respond to events (e.g. clicks, window moves) very slowly. Here's a list of those applications:

OpenTTD:
- 640x480 window - smooth animation
- 800x600 - a bit choppy
- 1024x768 - very choppy
- 1280x760 or more - 3fps or less, can't play

LibreOffice Calc - totally unusable


It's constant for these apps. Always reproducible. There were more but I don't currently remember them, probably because I don't use them on a regular basis.

This has been a case since I bought my Radeon 7870 in May 2013 - so it's not a problem with a specific version of package.

The slowdown affects everything. I just OpenTTD in 1280 and every application is chopping. The text I currently write appears with delays comparable to an SSH connection across the ocean.

# Package versions:

glamor-egl git today
mesa 9.2.3-2
libdrm 2.4.47-1
linux 3.12.0-1-ARCH

# Environment and GPU:

Radeon 7870
Intel i5 2500 3.3 GHz
3 displays (1920x1200, 2560x1440, 1920x1200) via Eyefinity

That's a whole lot of pixels but on 2x NVidia cards with Nouveau and Xinerama (!) I was able to play OpenTTD in 3840x1200. It couldn't handle more because of CPU usage. So if Xinerama was able to handle it, a "native" driver has to handle way more.

# My speculations

The more resolution I set in OpenTTD, the more /usr/bin/X process takes CPU.

doing nothing, just displaying several apps: 25%
OpenTTD 640: 50%
OpenTTD 1024: 70%
OpenTTD 1280+: 75% (and no more)
Comment 1 Damian Nowak 2013-11-21 13:14:16 UTC
Other apps that are slow:

TeamViewer - when sharing my screen
Skype - when sharing my screen
Comment 2 Alexander Tsoy 2013-11-25 22:11:22 UTC
Java (at least AWT) applications are extremely slow. It is painfull to use some IP-KVMs.
Comment 3 Damian Nowak 2013-11-25 22:13:25 UTC
Agreed. Soap UI is terribly slow.

Fortunately, Java IDE I use (IntelliJ IDEA) allows me to set a GTK look and feel. It's fast.
Comment 4 Alexander Tsoy 2013-11-25 22:46:42 UTC
This is probably related to bug 68524, or may be even a duplicate.
Comment 5 Zhigang Gong 2013-11-26 13:45:48 UTC
(In reply to comment #4)
> This is probably related to bug 68524, or may be even a duplicate.

I agree so, these two bugs should be the same. The reason is that I can't
reproduce this on Intel's platform is that the fallback on Intel platform
may fallback to UXA which is not too bad. But on AMD platform, it will fallback
to pure software rendering patch which leads to texture download (glReadPixels) and texture upload, the downloading/uploading is really extreme slow. Need someone to identify the fallback code path and optimize it to avoid the fallback.
Comment 6 Anthony Waters 2014-01-01 04:21:04 UTC
This slowdown is due to the way glamor_copy_area works when the source pixmap is on the CPU and the destination pixmap is on the GPU.  EXA specifically handles this path by copying straight from the data into the destination, so I have attached a patch that does a similar thing.  I also had to update how __glamor_upload_pixmap_to_texture works to properly account for texture data that is aligned differently, so there may still be some bugs with it.

The patch will make openttd faster, and should also make other things faster as well, like text rendering, due to the way it works, but I haven't run any benchmarks or anything.
Comment 7 Anthony Waters 2014-01-01 04:21:34 UTC
Created attachment 91380 [details] [review]
Speed up glamor_copy_area for certain use cases
Comment 8 Damian Nowak 2014-01-01 04:24:29 UTC
Thank you Anthony, I will check it out tomorrow.
Comment 9 Anthony Waters 2014-01-02 02:02:23 UTC
I see some flashing black blocks semi-frequently when running openttd so the patch isn't quite bug free, I'll see if I can figure it out.
Comment 10 Damian Nowak 2014-01-02 05:07:42 UTC
OK. Please keep me informed. I didn't have time to try the patch today though, but I'll take a look asap. Thanks.
Comment 11 Damian Nowak 2014-01-02 23:37:26 UTC
Hey Anthony, I jest checked it out. It works for me. Resolution is 6400x1200, with no single slowdown! I didn't see any flashing blocks. It just works. Here's a screenshot. http://upload.nowaker.net/nwkr/1388704282_openttd-6400x1200.png

LibreOffice Calc is much faster. It still takes some time for it to render, around 45 seconds. However, after it renders, I can use Calc without any issues. The only element that renders slowly is sheet selector. Others are fine. I highlighted red the element I'm talking about. http://upload.nowaker.net/nwkr/1388704673_libreoffice.png

Soap UI is a bit faster. I'd say +50% fps. The same applies to recording a screencast with kdenlive, I believe there were some more fps this time. But there's still much to improve there.

There must be some other places in the code that still slow glamor down I believe. But this patch is a great step towards the performance anyway! Thanks for your great work.

// Tested on Arch Linux with glamor from git and this patch. Package in AUR: https://aur.archlinux.org/packages/glamor-egl-git/ + Anthony's patch.
Comment 12 Anthony Waters 2014-01-03 02:02:24 UTC
That sounds good, the flashing blocks maybe due to something else then, I'll look into it more to see if I can figure it out before posting the patches to the mailing list.


As for those other slowdowns, I'm not too sure of their cause, but I will look into them once I close out the other patch.
Comment 13 Marek Olšák 2014-01-03 12:39:12 UTC
(In reply to comment #7)
> Created attachment 91380 [details] [review] [review]
> Speed up glamor_copy_area for certain use cases

Did you consider using something like GLX_EXT_texture_from_pixmap to get a GL texture ID from a pixmap without copying anything?
Comment 14 Damian Nowak 2014-01-03 12:51:35 UTC
@Anthony, the more patches the better, I will test everything you port here. ;-)
Comment 15 Marek Olšák 2014-01-03 20:55:27 UTC
@Anthony: Ignore what I said before. The patch looks good at first glance, but I don't understand why you changed the stride parameter of glamor_upload_sub_pixmap_to_texture to 0 at several places.
Comment 16 Anthony Waters 2014-01-04 00:51:18 UTC
(In reply to comment #15)
> @Anthony: Ignore what I said before. The patch looks good at first glance,
> but I don't understand why you changed the stride parameter of
> glamor_upload_sub_pixmap_to_texture to 0 at several places.

I think I changed it because glamor_upload_sub_pixmap_to_texture originally didn't actually use the parameter so I set them to zero because I saw some corruption.  I changed them back to their original values and things seem to be okay.

However, the one case that causes issues was _glamor_put_image, the two calls used pixmap->devKind and PixmapBytePad(w, depth), however, that cause the xserver to crash with the backtrace 
[ 36556.429] (EE) 
[ 36556.429] (EE) Backtrace:
[ 36556.430] (EE) 0: /usr/bin/X (OsLookupColor+0x129) [0x583f19]
[ 36556.430] (EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0) [0x7fda47776aff]
[ 36556.430] (EE) 2: /lib64/libc.so.6 (__memcpy_ssse3_back+0xb9) [0x7fda46509069]
[ 36556.431] (EE) 3: /mnt/samsung/development/build64/lib/dri/r600_dri.so (memcpy_texture+0x188) [0x7fda410d7c2e]
[ 36556.432] (EE) 4: /mnt/samsung/development/build64/lib/dri/r600_dri.so (_mesa_texstore+0xab) [0x7fda410de102]
[ 36556.433] (EE) 5: /mnt/samsung/development/build64/lib/dri/r600_dri.so (store_texsubimage+0x35c) [0x7fda410dec29]
[ 36556.433] (EE) 6: /mnt/samsung/development/build64/lib/dri/r600_dri.so (_mesa_store_texsubimage+0x5b) [0x7fda410dee2b]
[ 36556.434] (EE) 7: /mnt/samsung/development/build64/lib/dri/r600_dri.so (st_TexSubImage+0xa4c) [0x7fda41134068]
[ 36556.435] (EE) 8: /mnt/samsung/development/build64/lib/dri/r600_dri.so (st_TexImage+0xbc) [0x7fda41134193]
[ 36556.435] (EE) 9: /mnt/samsung/development/build64/lib/dri/r600_dri.so (teximage+0x10cd) [0x7fda410ce55f]
[ 36556.436] (EE) 10: /mnt/samsung/development/build64/lib/dri/r600_dri.so (_mesa_TexImage2D+0x63) [0x7fda410cf41d]
[ 36556.436] (EE) 11: /mnt/samsung/development/build64/lib/libglamor.so.0 (__glamor_upload_pixmap_to_texture.isra.6+0x154) [0x7fda4534ef54]
[ 36556.437] (EE) 12: /mnt/samsung/development/build64/lib/libglamor.so.0 (_glamor_upload_bits_to_pixmap_texture+0x34d) [0x7fda4534f56d]
[ 36556.437] (EE) 13: /mnt/samsung/development/build64/lib/libglamor.so.0 (glamor_upload_sub_pixmap_to_texture+0x275) [0x7fda4534fe75]
[ 36556.437] (EE) 14: /mnt/samsung/development/build64/lib/libglamor.so.0 (_glamor_put_image+0x602) [0x7fda4533e552]
[ 36556.437] (EE) 15: /mnt/samsung/development/build64/lib/libglamor.so.0 (glamor_put_image+0x32) [0x7fda4533e6e2]
[ 36556.437] (EE) 16: /usr/bin/X (DamageRegionAppend+0x35b9) [0x5127b9]
[ 36556.438] (EE) 17: /usr/bin/X (SyncVerifyFence+0x203b) [0x4ceebb]
[ 36556.438] (EE) 18: /usr/bin/X (SyncVerifyFence+0x33b8) [0x4d19e8]
[ 36556.438] (EE) 19: /usr/bin/X (SendErrorToClient+0x38e) [0x435b1e]
[ 36556.438] (EE) 20: /usr/bin/X (remove_fs_handlers+0x40a) [0x43992a]

Setting the stride to 0 for those causes fixed the issue, to be honest I'm not 100% sure what it is supposed to be.
Comment 17 Anthony Waters 2014-01-07 15:53:11 UTC
I'm still getting the flashes of black occasionally when playing OpenTTD, I'm not too sure of the cause at the moment because EXA doesn't have the issue and I cannot seem to reproduce it any where else.
Comment 18 Damian Nowak 2014-01-07 17:13:21 UTC
I run Arch Linux, so I am up to date with kernel, X, drm and such. Maybe it's not working for you because of some older stuff?
Comment 19 Anthony Waters 2014-01-09 00:03:01 UTC
I am up to date, mesa, kernel, X, and drm are latest from git, I also tried mesa 9.2.5 and had the same issue.  I notice it mostly on the introduction screen, every couple of seconds a small rectangle will fill with black/white, it doesn't appear to happen consistently making it hard to pinpoint what the issue could be.
Comment 20 darkbasic 2014-01-10 12:11:45 UTC
"Speed up glamor_copy_area for certain use cases" (https://bugs.freedesktop.org/attachment.cgi?id=91380) seems to fix my KDE raster backend issue (bug #69341 https://bugs.freedesktop.org/show_bug.cgi?id=69341) hurray!!!

I suggest you to apply also "polylines: Handle diagonal lines" (https://bugs.freedesktop.org/attachment.cgi?id=91802) which fixes the gtk primitives/Calc issues (bug #68524 https://bugs.freedesktop.org/show_bug.cgi?id=68524)
Comment 21 Hleb Valoshka 2014-01-10 19:50:24 UTC
(In reply to comment #7)
> Created attachment 91380 [details] [review] [review]
> Speed up glamor_copy_area for certain use cases

I've just tested this patch together with "First attempt at handling diagonal lines in poly_line code" from #68524: libreoffice calc works without glitches and windowmaker draws its menu in a flash (hurray!), gtkperf show better results too (not only with GtkDrawingArea - Lines).
Comment 22 Damian Nowak 2014-01-10 21:08:41 UTC
Hleb, would you please try out openttd and confirm or deny the glitches Anthony is experiencing? Thanks.
Comment 23 Hleb Valoshka 2014-01-10 22:12:01 UTC
(In reply to comment #22)
> Hleb, would you please try out openttd and confirm or deny the glitches
> Anthony is experiencing? Thanks.

No, I don't have nothing like "every couple of seconds a small rectangle will fill with black/white" the image is clean, scrolling speed is good (1280x1024), but X11 CPU usage is rather high (~30% of 1.8 GHz).

(I've haven't tested it too long cause I don't play openttd.)
Comment 24 Anthony Waters 2014-01-12 16:21:37 UTC
I have another computer with a radeon 6570 with more stable software so I will try that to see if the cause is with my particular setup or not.
Comment 25 Alexander Tsoy 2014-01-15 11:02:43 UTC
(In reply to comment #7)
> Created attachment 91380 [details] [review] [review]
> Speed up glamor_copy_area for certain use cases

I can confirm that this patch fixes performance problem in openttd and I don't see any glitches. There are some lags (especially in mouse cursor movements) on the introduction screen, but the game performance is great now.
Comment 26 Anthony Waters 2014-01-17 21:11:59 UTC
Created attachment 92306 [details]
OpenTTD black rectangles

Here is an example of the black rectangles that I am seeing.  They pop on the screen and then disappear very quickly.
Comment 27 Anthony Waters 2014-01-18 02:31:54 UTC
I tried testing this on another machine with a Radeon 6570 with more stable software (kernel 3.12, mesa 9.2.5) and I still experienced the issue.  For those that do not have the issue can you report your video card along with the version of mesa/kernel/libdrm?
Comment 28 Anthony Waters 2014-01-18 03:12:07 UTC
I tried the llvmpipe driver and it also had the issue so I'll have to figure this out more.
Comment 29 Alexander Tsoy 2014-01-18 11:27:25 UTC
(In reply to comment #27)
> I tried testing this on another machine with a Radeon 6570 with more stable
> software (kernel 3.12, mesa 9.2.5) and I still experienced the issue.  For
> those that do not have the issue can you report your video card along with
> the version of mesa/kernel/libdrm?

Cape Verde PRO [Radeon HD 7750]

media-libs/mesa-10.0.2
sys-devel/llvm-3.4
sys-kernel/hardened-sources-3.12.6-r4
x11-drivers/xf86-video-ati-9999 (latest git))
x11-libs/glamor-9999 (latest git)
x11-libs/libdrm-2.4.50

Also tried xf86-video-ati-7.2.0

Note, that I disabled ColorTiling2D due to the massive screen corruption (bug 71488).
Comment 30 Michel Dänzer 2014-01-23 01:25:44 UTC
(In reply to comment #7)
> Created attachment 91380 [details] [review] [review]
> Speed up glamor_copy_area for certain use cases

This patch introduces some warnings, see below. Please clean it up and submit it to the glamor mailing list.

../../src/glamor_copyarea.c: In function 'glamor_copy_n_to_n_textured':
../../src/glamor_copyarea.c:186:42: warning: pointer of type 'void *' used in arithmetic [-Wpointer-arith]
    src_data = src_pixmap->devPrivate.ptr + (box[i].y1 + dy +
                                          ^
../../src/glamor_copyarea.c:187:33: warning: pointer of type 'void *' used in arithmetic [-Wpointer-arith]
         src_y_off) * src_stride +
                                 ^
../../src/glamor_copyarea.c:160:28: warning: unused variable 'src_status' [-Wunused-variable]
  enum glamor_pixmap_status src_status = GLAMOR_NONE;
Comment 31 Damian Nowak 2014-01-25 18:27:01 UTC
@Anthony, @Michel, in the mean-time other guys fixed the problems with rendering lines. Now gtkperf works smoothly and doesn't make the OS unresponsive. LibreOffice Calc works as expected. SoapUI is faster but still just a bit choppy.

No change in speed for applications that record what's happening on the screen though (Skype, TeamViewer, Kdenlive).

If we get this patch merged into upstream, I think I should close this one. A new bug report will be just about screen-recording software.
Comment 32 Anthony Waters 2014-01-26 18:24:40 UTC
I'll see if I can split the this into two patches, one that adds the stride parameter to upload pixmap to texture and the other as the one that accelerates the corner case.
Comment 33 Anthony Waters 2014-01-29 16:22:32 UTC
I submitted it as two separate patches.


bug/show.html.tmpl processed on Mar 25, 2017 at 19:33:09.
(provided by the Example extension).