Bug 71813

Other apps that are slow:

TeamViewer - when sharing my screen
Skype - when sharing my screen

Java (at least AWT) applications are extremely slow. It is painfull to use some IP-KVMs.

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.

This is probably related to bug 68524, or may be even a duplicate.

(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.

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.

Created attachment 91380 [details] [review]
Speed up glamor_copy_area for certain use cases

Thank you Anthony, I will check it out tomorrow.

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.

OK. Please keep me informed. I didn't have time to try the patch today though, but I'll take a look asap. Thanks.

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.

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.

(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?

@Anthony, the more patches the better, I will test everything you port here. ;-)

@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.

(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.

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.

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?

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.

"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)

(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).

Hleb, would you please try out openttd and confirm or deny the glitches Anthony is experiencing? Thanks.

(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.)

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.

(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.

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.

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?

I tried the llvmpipe driver and it also had the issue so I'll have to figure this out more.

(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).

(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;

@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.

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.

I submitted it as two separate patches.

Patches are in git:
http://cgit.freedesktop.org/xorg/driver/glamor/commit/?id=654e1536a6d6539dcc30d9151122536c1807f34a
http://cgit.freedesktop.org/xorg/driver/glamor/commit/?id=6ffa4b88be5ac1580d29193b6cd3d216415d9be2