Bug 68524 - radeonsi with glamor has very poor performance with primitives drawing
radeonsi with glamor has very poor performance with primitives drawing
Status: RESOLVED FIXED
Product: xorg
Classification: Unclassified
Component: Driver/Radeon
7.7 (2012.06)
x86-64 (AMD64) Linux (All)
: medium normal
Assigned To: xf86-video-ati maintainers
Xorg Project Team
:
: 70385 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-25 09:41 UTC by Hleb Valoshka
Modified: 2014-08-12 09:40 UTC (History)
22 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Xorg log (39.09 KB, text/plain)
2013-08-25 14:37 UTC, Hleb Valoshka
no flags Details
dmesg (57.44 KB, text/plain)
2013-08-25 14:39 UTC, Hleb Valoshka
no flags Details
First attempt at handling diagonal lines in poly_line code (7.66 KB, patch)
2014-01-10 01:28 UTC, Aaron Watry
no flags Details | Splinter Review
glamor: Reinstate wrappers to make software fallbacks a little less inefficient (60.42 KB, patch)
2014-01-10 03:03 UTC, Michel Dänzer
no flags Details | Splinter Review
sample ods file with "many" sheets (94.57 KB, application/vnd.oasis.opendocument.spreadsheet)
2014-01-10 11:08 UTC, Kamil Páral
no flags Details
sample ods file with scrolling problems (201.92 KB, application/vnd.oasis.opendocument.spreadsheet)
2014-01-10 11:30 UTC, Kamil Páral
no flags Details
use mi fallbacks for lines (1.71 KB, patch)
2014-01-13 23:41 UTC, Dave Airlie
no flags Details | Splinter Review
Xorg log file (61.55 KB, text/plain)
2014-01-18 13:55 UTC, Eugene
no flags Details
dmesg log file (62.39 KB, text/plain)
2014-01-18 13:56 UTC, Eugene
no flags Details
xorg.conf file (179 bytes, text/plain)
2014-01-18 13:58 UTC, Eugene
no flags Details
Video through -vo opengl (589.26 KB, image/png)
2014-01-18 14:17 UTC, Eugene
no flags Details
Video through -vo xv (586.43 KB, image/png)
2014-01-18 14:17 UTC, Eugene
no flags Details
Xorg.0.log from glamor-server compiled X (40.61 KB, text/plain)
2014-04-21 20:41 UTC, Marco
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Hleb Valoshka 2013-08-25 09:41:44 UTC
While glamor acceleration is upto 5 times slower than EXA on my radeon 7750,
with primitives drawing it is slow as hell. There are results of gtkperf with
EXA and glamor:

EXA:
GtkEntry - time:  0,00
GtkComboBox - time:  0,50
GtkComboBoxEntry - time:  0,40
GtkSpinButton - time:  0,06
GtkProgressBar - time:  0,02
GtkToggleButton - time:  0,06
GtkCheckButton - time:  0,06
GtkRadioButton - time:  0,08
GtkTextView - Add text - time:  0,35
GtkTextView - Scroll - time:  0,10
GtkDrawingArea - Lines - time:  0,92
GtkDrawingArea - Circles - time:  1,51
GtkDrawingArea - Text - time:  0,68
GtkDrawingArea - Pixbufs - time:  0,08
 --- 
Total time:  4,82

Glamor:
GtkEntry - time:  0,00
GtkComboBox - time:  2,30
GtkComboBoxEntry - time:  1,86
GtkSpinButton - time:  0,26
GtkProgressBar - time:  0,07
GtkToggleButton - time:  0,10
GtkCheckButton - time:  0,05
GtkRadioButton - time:  0,11
GtkTextView - Add text - time:  0,33
GtkTextView - Scroll - time:  0,10
GtkDrawingArea - Lines - ^C

The test was aborted after running for 27 _minutes_.

The same bad visual performance is demonstated by app written in XAA ages like
WindowMaker (just try to open its menu).

The situation will be much worse if you disable color tiling (only for drawing
primitives, results for all that gtk*button/view/box will be the same).
Comment 1 Alex Deucher 2013-08-25 14:14:32 UTC
Please attach your xorg log and dmesg output.
Comment 2 Hleb Valoshka 2013-08-25 14:37:29 UTC
Created attachment 84596 [details]
Xorg log
Comment 3 Hleb Valoshka 2013-08-25 14:39:03 UTC
Created attachment 84597 [details]
dmesg
Comment 4 Zhigang Gong 2013-10-19 09:28:59 UTC
The same benchmark on Intel platform is as below:
GtkEntry - time:  0.03
GtkComboBox - time:  0.48
GtkComboBoxEntry - time:  0.31
GtkSpinButton - time:  0.07
GtkProgressBar - time:  0.11
GtkToggleButton - time:  0.22
GtkCheckButton - time:  0.07
GtkRadioButton - time:  0.11
GtkTextView - Add text - time:  1.04
GtkTextView - Scroll - time:  0.21
GtkDrawingArea - Lines - time:  0.69
GtkDrawingArea - Circles - time:  0.57
GtkDrawingArea - Text - time:  0.96
GtkDrawingArea - Pixbufs - time:  0.12
 --- 
Total time:  4.98

With glamor enabled. Just for your reference.
Comment 5 Ivan Bulatovic 2013-10-22 18:25:34 UTC
GtkEntry - time:  0.02
GtkComboBox - time:  0.49
GtkComboBoxEntry - time:  0.52
GtkSpinButton - time:  0.30
GtkProgressBar - time:  0.18
GtkToggleButton - time:  0.16
GtkCheckButton - time:  0.15
GtkRadioButton - time:  0.26
GtkTextView - Add text - time:  0.22
GtkTextView - Scroll - time:  0.14
GtkDrawingArea - Lines - time: 259.75
GtkDrawingArea - Circles - time: 33.70
GtkDrawingArea - Text - time:  0.57
GtkDrawingArea - Pixbufs - time:  0.42
 --- 
Total time: 296.89

R9 270X with glamor enabled. Lines were really a pain (desktop responsivness was equal to zero during the test), but at least it finished in just under five minutes.

No errors in both Xorg.0.log and dmesg.
Comment 6 Michel Dänzer 2013-10-23 08:22:59 UTC
(In reply to comment #4)

Zhigang, note that the radeon driver passes GLAMOR_USE_SCREEN and GLAMOR_USE_PICTURE_SCREEN to glamor_init(), so software rendering fallbacks are handled entirely within glamor, which incurs a lot of overhead in some cases such as the gtkperf Lines test.
Comment 7 Zhigang Gong 2013-11-02 12:24:37 UTC
(In reply to comment #6)
> (In reply to comment #4)
> 
> Zhigang, note that the radeon driver passes GLAMOR_USE_SCREEN and
> GLAMOR_USE_PICTURE_SCREEN to glamor_init(), so software rendering fallbacks
> are handled entirely within glamor, which incurs a lot of overhead in some
> cases such as the gtkperf Lines test.

Got it. The fallback path in glamor is extremely slow currently.
Comment 8 Damian Nowak 2013-11-25 22:51:07 UTC
Is my #68524 a duplicate of this one?
Comment 9 Damian Nowak 2013-11-25 22:51:17 UTC
https://bugs.freedesktop.org/show_bug.cgi?id=68524
Comment 10 darkbasic 2013-11-26 00:16:21 UTC
#68524 is THIS bug report.
Comment 11 Michel Dänzer 2013-12-17 08:32:09 UTC
*** Bug 70385 has been marked as a duplicate of this bug. ***
Comment 12 pfannkuchen_gesicht 2013-12-20 18:22:12 UTC
Hello, just wanted to ask if there is any progress?
I have a HD7970 and use radeonsi on Arch linux and glamor is just not usable at all due to its sluggishness.
Comment 13 Damian Nowak 2013-12-22 20:54:13 UTC
@Michel, Sorry, I meant https://bugs.freedesktop.org/show_bug.cgi?id=71813
Comment 14 Thue Janus Kristensen 2013-12-28 02:46:33 UTC
(In reply to comment #12)
> Hello, just wanted to ask if there is any progress?
> I have a HD7970 and use radeonsi on Arch linux and glamor is just not usable
> at all due to its sluggishness.

You can force it to use EXA until glamor support is fixed. This is how I did it:

t@h ~> cat /etc/X11/xorg.conf.d/20-radeon.conf
Section "Device"
        Identifier  "Radeon 7750"
        Driver      "radeon"
        Option      "SWcursor"              "off" #software cursor might be necessary on some rare occasions, hence set off by default
        Option      "EnablePageFlip"        "on"  #supported on all R/RV/RS4xx and older hardware, and set on by default
        Option      "AccelMethod"           "EXA" #valid options are XAA, EXA and Glamor. EXA is the default
        Option      "RenderAccel"           "on"  #enabled by default on all radeon hardware
        Option      "ColorTiling"           "on"  #enabled by default on RV300 and later radeon cards
        Option      "EXAVSync"              "off" #default is off, otherwise on. Only works if EXA activated
        Option      "EXAPixmaps"            "on"  #when on icreases 2D performance, but may also cause artifacts on some old cards. Only works if EXA activated
        Option      "AccelDFS"              "on"  #default is off, read the radeon manpage for more information
EndSection
Comment 15 pfannkuchen_gesicht 2013-12-28 13:57:52 UTC
(In reply to comment #14)
> (In reply to comment #12)
> > Hello, just wanted to ask if there is any progress?
> > I have a HD7970 and use radeonsi on Arch linux and glamor is just not usable
> > at all due to its sluggishness.
> 
> You can force it to use EXA until glamor support is fixed. This is how I did
> it:
> 

yes, I did that already, just wondered if we can use glamor again fairly soon.
Thanks for the heads up though!
Comment 16 Anthony Waters 2014-01-01 03:36:50 UTC
This specific slowdown is as a result of glamor_poly_lines not implementing acceleration for diagonal lines.
Comment 17 Damian Nowak 2014-01-03 00:14:55 UTC
Guys please have a look at this issue because Anthony submitted a patch which fixes OpenTTD. GTK lines not yet. https://bugs.freedesktop.org/show_bug.cgi?id=71813
Comment 18 darkbasic 2014-01-07 15:42:30 UTC
I tried the patch but it does not fix our gtk issue.
Comment 19 Aaron Watry 2014-01-09 17:06:02 UTC
(In reply to comment #18)
> I tried the patch but it does not fix our gtk issue.

Agreed. I've done runs both before/after the patch with 100 iterations each, and the Lines performance is unchanged.
Comment 20 Aaron Watry 2014-01-09 20:46:48 UTC
(In reply to comment #16)
> This specific slowdown is as a result of glamor_poly_lines not implementing
> acceleration for diagonal lines.

Same conclusion I've come to:

From glamor_polylines.c:74-78:
if (x1 != x2 && y1 != y2) {
	free(rects);
	glamor_fallback("stub diagonal poly_line\n");
	goto fail;
}

And the fallback path forces us to retrieve the pixmap to draw the line, and then send the pixmap back to the GPU. Doing this for every line is slow.


For reference, I get the following from 100 iterations of GTK Perf - Lines by default:
GtkDrawingArea - Lines - time: 242.57

When I force gtkperf to only use horizontal/vertical lines, I get the following:
GtkDrawingArea - Lines - time:  1.92

If I force a line width of 1 instead of 0 in gtkperf's source, but still allow diagonals (glamor follows a similar failure path but doesn't have the explicit prepare_access calls):
GtkDrawingArea - Lines - time: 26.33

Sadly, we can't just remove the prepare_access/finish_access calls because fbPolyLine takes completely different code paths for a width of 0 vs 1. If you try to just run fbPolyLine with a width of 0 for the line without preparing it first, you get an X server crash. 

I'm not sure what the drawbacks of forcing a line width of 1 when the current width is 0 are (other than possibly incorrect rendering... but obviously a drawn line has to have a width of something). If it turns out that we actually get identical output in all cases, it might be something to consider trying out.  Finding the solution is a bit outside of my comfort zone.

Otherwise, are there any ways that we can speed up the copy operations via map/unmap or a shadow copy of the area. I'm assuming that some of this is already going on behind the scenes, but maybe I'm wrong.
Comment 21 Alex Deucher 2014-01-09 20:57:09 UTC
Basically, one needs to implement support for diagonal lines or improve the fallback handling.  I'm not sure which would be easier off hand.
Comment 22 darkbasic 2014-01-09 21:01:58 UTC
Either one it should be *HIGH* priority. I'm not the only one who consider the actual radeonsi 2D acceleration crap: http://kparal.wordpress.com/2014/01/08/amd-radeon-r9-270-in-fedora-20-experience/
Comment 23 Kamil Páral 2014-01-09 21:30:35 UTC
(In reply to comment #22)
I see my blogpost got famous :-) But I don't want to belittle the developers or the project. I haven't said "crap". I'm very happy that radeonsi works so well (when compared e.g. to nouveau). Only in case developers want some prioritization advice, the LibreOffice Calc issue is really unfortunate, and it probably affects a lot of users.
Comment 24 darkbasic 2014-01-09 21:47:01 UTC
I don't want to offend developers too, but let's face reality:
- Calc is damn slow which surely affects a very large user base
- KDE is completely BROKEN. KDE!!! I'm pretty sure you don't use KDE because QT's raster backend is a real pain in the ass. You can use native of course but at the expense of corruption.

How is it possible that developers already started working on advanced features like Hyper-Z while we still don't have even basic functionalities? Priorities should really be questioned IMHO.
Comment 25 Aaron Watry 2014-01-10 01:28:14 UTC
Created attachment 91802 [details] [review]
First attempt at handling diagonal lines in poly_line code

First attempt at handling diagonal lines without excessive cpu<->gpu traffic

Splits a diagonal line into 2 or more horizontal/vertical lines.

Before:
GtkDrawingArea - Lines - time: 242.57

After:
GtkDrawingArea - Lines - time: 23.01

It's not amazingly fast this way, but it is a 10x performance improvement. The closer to horizontal/vertical the line is, the better it should perform. The worst case would be a line with a perfect slope of 1 or -1, which would be de-constructed to a bunch of points.

I don't know if there's a certain slope that would be a good cutoff for this handling versus the old method. Someone can feel free to play with that.
Comment 26 Aaron Watry 2014-01-10 01:41:19 UTC
(In reply to comment #24)
> I don't want to offend developers too, but let's face reality:
> - Calc is damn slow which surely affects a very large user base
> - KDE is completely BROKEN. KDE!!! I'm pretty sure you don't use KDE because
> QT's raster backend is a real pain in the ass. You can use native of course
> but at the expense of corruption.
> 
> How is it possible that developers already started working on advanced
> features like Hyper-Z while we still don't have even basic functionalities?
> Priorities should really be questioned IMHO.

Do you have a spreadsheet that you can share?  I fired up localc earlier today, and with several thousand rows and a few hundred columns, scrolling performance was fairly decent.  But that also hits the horizontal/diagonal lines criteria... so maybe you're dealing with charts, or something else... ?

I did open up a spreadsheet that had previously caused issues and things seemed pretty decent, but I believe that previously I might also have been running a bitcoin miner and EVE Online (in wine) simultaneously with working on the spreadsheet.
Comment 27 Michel Dänzer 2014-01-10 03:03:15 UTC
Created attachment 91804 [details] [review]
glamor: Reinstate wrappers to make software fallbacks a  little less inefficient

(In reply to comment #25)
> It's not amazingly fast this way, but it is a 10x performance improvement.

That's a nice improvement in performance, but it's still an order of magnitude slower than EXA, so I feel it would be better to either go directly for full-blown shader-based acceleration of diagonal lines, or to work on improving the performance of software fallbacks in general.

For the latter, this patch could serve as a starting point. It basically reinstates the glamor wrappers removed in http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=a60d2152e928a7011fc7c44a885a34c3cdd4f0fe in order to allow direct access to pixmaps for software fallbacks.

Known caveats: Tiling needs to be disabled, as software fallbacks may now access the GPU buffers directly. Trying to start xfwm4 crashes the X server for me.

But I was able to run gtkperf on a 'naked' X server with this patch, and it looks like its performance is improved pretty much across the board. The lines and circles tests still take double-digit seconds though, just to prevent everyone from getting too excited.
Comment 28 Michel Dänzer 2014-01-10 03:26:21 UTC
(In reply to comment #24)
> - KDE is completely BROKEN. KDE!!! I'm pretty sure you don't use KDE because
> QT's raster backend is a real pain in the ass.

I indeed don't use KDE on a regular basis, but I do try it every now and then, and it doesn't seem to perform as badly for me as you're describing it. As I've seen similar comments from others, I wonder if there's something weird on your system wrt the raster backend. Though I suppose the inefficiency of glamor software fallbacks might just be particularly bad for you because you seem to be using relatively high resolutions.


> How is it possible that developers already started working on advanced
> features like Hyper-Z while we still don't have even basic functionalities?
> Priorities should really be questioned IMHO.

We are taking this problem seriously, but we obviously can't drop everything else because of it.

BTW, Hyper-Z support for radeonsi was contributed by a volunteer, not by an AMD developer.
Comment 29 Aaron Watry 2014-01-10 04:04:51 UTC
(In reply to comment #27)
> That's a nice improvement in performance, but it's still an order of
> magnitude slower than EXA, so I feel it would be better to either go
> directly for full-blown shader-based acceleration of diagonal lines, or to
> work on improving the performance of software fallbacks in general.

No argument there.  I figured that there was no real chance of my patch getting committed long-term, just figured that it partially mitigates the worst of the problem for now.  If we can extend glamor to handle shader-based lines or improve the software fallbacks, great...  it's just beyond what I feel comfortable with at the moment (my background is more OpenCL, not GL, and I just took my first real look at the glamor code this morning).
Comment 30 Michel Dänzer 2014-01-10 09:57:33 UTC
(In reply to comment #27)
> Known caveats: Tiling needs to be disabled, as software fallbacks may now
> access the GPU buffers directly.

On further thought, this may be a deal breaker for this approach.

The only feasible way for improving performance of software fallbacks may be via persistent separate storage for software fallbacks, with transfers of changed pixels between that and the GPU accessible storage on demand, as is done by EXA and SNA.
Comment 31 darkbasic 2014-01-10 10:52:25 UTC
> First attempt at handling diagonal lines in poly_line code
> It's not amazingly fast this way, but it is a 10x performance improvement.

Thanks! This will surely mitigate things while waiting for a proper fix.

> glamor: Reinstate wrappers to make software fallbacks a  little less inefficient

Thank you too.

> Do you have a spreadsheet that you can share?

I have some spreadsheets (small ones!) which make calc completely unusable but unfortunately I really can't share them. If I will find something else I can share I will let you know (I don't use calc that much). Maybe Kamil Páral can help you.

> As I've seen similar comments from others, I wonder if there's something weird
> on your system wrt the raster backend. Though I suppose the inefficiency of
> glamor software fallbacks might just be particularly bad for you because you
> seem to be using relatively high resolutions.

With high resolutions it is worse of course, but trust me you will notice it if you're affected by the problem (even at lower resolutions). Just try typing something in the Konsole and then hold backspace for a few seconds before releasing it: it will keep deleting for a few seconds after you released backspace!

Something weird on my system? I exclude it: I turned upside down my graphical stack hundreds of times, I even tried a fresh install of the most widely used distribution (Ubuntu) with the very same results.

Something weird with my particular graphic card? Maybe, but it sounds strange too.

> We are taking this problem seriously, but we obviously can't drop everything
> else because of it.

Nice to hear you're taking this issue seriously.
Comment 32 Kamil Páral 2014-01-10 11:08:26 UTC
Created attachment 91813 [details]
sample ods file with "many" sheets

This is a sample ODS file that kills my Calc performance. Just to open the file takes 20 seconds, to switch to a different sheet takes 15 seconds. During that time my GNOME desktop is frozen and I can't do anything else. I believe this is caused by sheet tabs redrawing at the bottom of the document.

I've tested this on Fedora 20 with mesa 9.2.5, kernel 3.12 with dpm, xorg-x11-drv-ati 7.2 and xorg-x11-glamor 0.5.1. I tried to install Fedora 21 today to have the latest software to test, unfortunately the radeonsi driver is unusably slow in there (no errors in the log, no idea why), so I can't speak for that.

I'll also try to find a different document that I can share where scrolling is a problem, not just the number of sheets.
Comment 33 Kamil Páral 2014-01-10 11:30:44 UTC
Created attachment 91814 [details]
sample ods file with scrolling problems

This is a sample ODS file where it's almost impossible to scroll. (The contents are generated). I believe this is caused by hundreds of those little red arrows that indicate a cropped text field. If I resize all the columns to optimal width (no text cropping), the scrolling becomes fast.
Comment 34 darkbasic 2014-01-10 11:40:26 UTC
I don't have the slightest problem with your ods file, maybe because of the patches I applied to glamor git? I will try to remove them and see if something changes.
Comment 35 darkbasic 2014-01-10 11:53:07 UTC
"polylines: Handle diagonal lines" (https://bugs.freedesktop.org/attachment.cgi?id=91802) definitely fix the Calc issue!

Thanks Aaron Watry!
Comment 36 darkbasic 2014-01-10 12:07:18 UTC
It seems to be my lucky day: "Speed up glamor_copy_area for certain use cases" (https://bugs.freedesktop.org/attachment.cgi?id=91380) from bug #71813 (https://bugs.freedesktop.org/show_bug.cgi?id=71813) seems to fix my KDE raster backend issue! hurray!!!
Comment 37 darkbasic 2014-01-10 12:34:02 UTC
Native backend is still much faster (especially while scrolling), but at least raster is usable now.
Comment 38 Aaron Watry 2014-01-10 13:30:19 UTC
(In reply to comment #30)
> (In reply to comment #27)
> > Known caveats: Tiling needs to be disabled, as software fallbacks may now
> > access the GPU buffers directly.
> 
> On further thought, this may be a deal breaker for this approach.
> 
> The only feasible way for improving performance of software fallbacks may be
> via persistent separate storage for software fallbacks, with transfers of
> changed pixels between that and the GPU accessible storage on demand, as is
> done by EXA and SNA.

Yeah, that's the shadow copy idea that I was talking about in a prior post.  I guess that we're not doing that currently.  I believe that catalyst keeps a cpu-side buffer and the gpu-side buffer to speed up map/unmap for read/write oeprations in the driver.  Not sure if that's something that should be added to the drivers themselves, or if there's a way to handle it in glamor for all drivers.  Might be complicated to code either way.

(In reply to comment #27)
> (In reply to comment #25)
> > It's not amazingly fast this way, but it is a 10x performance improvement.
> 
> That's a nice improvement in performance, but it's still an order of
> magnitude slower than EXA, so I feel it would be better to either go
> directly for full-blown shader-based acceleration of diagonal lines, or to
> work on improving the performance of software fallbacks in general.

Upon a good night's sleep I also had an idea for an improvement to my patch which might be worth doing.  Currently, it reallocs the rects collection every time that it splits a line.  We already pre-calculate the maximum number of rectangles that can be added by this method, so we might as well realloc to that size initially, and then trim the list at the end to reflect how many rectangles we actually added. I honestly don't know if remalloc (and the copies that it might trigger) is a bottleneck here, but it shouldn't hurt.
Comment 39 Aaron Watry 2014-01-10 13:34:54 UTC
(In reply to comment #31)
> 
> Something weird on my system? I exclude it: I turned upside down my
> graphical stack hundreds of times, I even tried a fresh install of the most
> widely used distribution (Ubuntu) with the very same results.

Just curious, are you using Kubuntu 13.10 with the stock graphics drivers, or did you also add in either self-compiled drivers or the xorg-edgers ppa?  xorg-edgers just pulled in the latest llvm/mesa/glamor code a few days ago, which include llvm-3.4 (hopefully quite an improvement for radeonsi cards).

I'm currently using Ubuntu Gnome 13.10 with xorg-edgers and hand-compiled glamor for testing with a phenom ii x6, radeon 7850 and a 1920x1200 monitor.
Comment 40 darkbasic 2014-01-10 13:42:59 UTC
I use Gentoo with xorg-server-1.15, glamor git, xf86-video-ati git, mesa git, LLVM 3.5 git, linux 3.13-rc7. I tried Kubuntu some months ago because some peoples kept telling me they didn't have such a problem with Kubuntu.
Comment 41 Hleb Valoshka 2014-01-10 19:52:43 UTC
gtkperf results after applying "First attempt at handling diagonal lines in poly_line code" from here and "Speed up glamor_copy_area for certain use cases" from #71813:

GtkEntry - time:  0,06
GtkComboBox - time:  0,78
GtkComboBoxEntry - time:  0,63
GtkSpinButton - time:  0,17
GtkProgressBar - time:  0,03
GtkToggleButton - time:  0,10
GtkCheckButton - time:  0,07
GtkRadioButton - time:  0,11
GtkTextView - Add text - time:  0,36
GtkTextView - Scroll - time:  0,12
GtkDrawingArea - Lines - time: 54,88
GtkDrawingArea - Circles - time: 41,21
GtkDrawingArea - Text - time:  3,55
GtkDrawingArea - Pixbufs - time:  0,77
 --- 
Total time: 102,84

Good work!
Comment 42 Hleb Valoshka 2014-01-10 20:26:09 UTC
(In reply to comment #27)

> Known caveats: Tiling needs to be disabled, as software fallbacks may now
> access the GPU buffers directly. Trying to start xfwm4 crashes the X server
> for me.

Test "GtkDrawingArea - Circles" is still slow as without your patch (takes about 40 s). Another problem is a desynchronization of X client and X server: while gtkperf was already running the next test (GtkDrawingArea - Text) the X server still was drawing circles (for about 2 s).

But GtkDrawingArea - Lines - time:  5,01.
Comment 43 Dave Airlie 2014-01-13 23:41:16 UTC
Created attachment 92009 [details] [review]
use mi fallbacks for lines

can people give this a test to see if it alleviate the openoffice issues at least?
Comment 44 darkbasic 2014-01-14 11:11:58 UTC
"use mi fallbacks for lines" does fix the Calc issue indeed, unfortunately it doesn't fix the raster backend one.
Comment 45 Aaron Watry 2014-01-14 17:46:20 UTC
(In reply to comment #43)
> Created attachment 92009 [details] [review] [review]
> use mi fallbacks for lines
> 
> can people give this a test to see if it alleviate the openoffice issues at
> least?

On a radeon 5400 (Cedar) in an i7-2600k running mesa/glamor git and llvm-3.5 in gnome-shell:

Command: gtkperf -a -c 5

Before (glamor git master):
GtkDrawingArea - Lines - time:  7.22

After (dave/eric's mi lines patch):
GtkDrawingArea - Lines - time:  2.28

My previous diagonal lines patch:
GtkDrawingArea - Lines - time:  1.95

So it's an improvement over the status quo for sure.  I can probably test out the mi fallbacks patch later on the radeonsi (7850) at home, but you'll have to wait a few hours.
Comment 46 Kamil Páral 2014-01-14 17:55:15 UTC
(In reply to comment #43)
> Created attachment 92009 [details] [review] [review]
> use mi fallbacks for lines
> 
> can people give this a test to see if it alleviate the openoffice issues at
> least?

This fixes the Calc issues on two files I attached. The difference is tremendous (tested on Fedora 21). Especially the scrolling in Calc is fluent as opposed to previous heavy lagging.
Comment 47 Kamil Páral 2014-01-14 17:56:16 UTC
I forgot to add - I'm using radeonsi with Radeon R9 270.
Comment 48 Hleb Valoshka 2014-01-14 19:47:44 UTC
(In reply to comment #43)
> Created attachment 92009 [details] [review] [review]
> use mi fallbacks for lines
> 
> can people give this a test to see if it alleviate the openoffice issues at
> least?

OOo works fast, Windowmaker draws its menu fast, gtkperf reports 66,30 for lines. But desynchronization I've reported in comment 42 is present too (4-5 seconds). No other patches are applied on glamor/xf86-video-radeon.
Comment 49 Alexander Tsoy 2014-01-15 12:46:20 UTC
(In reply to comment #43)
> Created attachment 92009 [details] [review] [review]
> use mi fallbacks for lines
> 
> can people give this a test to see if it alleviate the openoffice issues at
> least?

Great! I don't use openoffice, but this patch fixed performance issues I had with IP-KVM java applet. Unfortunately, I didn't test other patches.

gtkperf results:

GtkDrawingArea - Lines - time: 30,19
GtkDrawingArea - Circles - time: 19,94

My hardware: Opteron 4332 HE + Radeon HD 7750 (CAPE VERDE)
Comment 50 Eugene 2014-01-18 13:53:17 UTC
Greetings. Just tried that glamor on my old HD2600 card. And here is my results. First, It boots ! And that is very good. But then I started to test playing some videos and there I found some issues. If I'm use opengl video out device in mplayer or mpv there is no problem but with xv that video is monochrome and colours only visible partialy or they fully disappears for short time. Please see the screenshots and other logs in attachments.
Comment 51 Eugene 2014-01-18 13:55:33 UTC
Created attachment 92331 [details]
Xorg log file
Comment 52 Eugene 2014-01-18 13:56:38 UTC
Created attachment 92332 [details]
dmesg log file
Comment 53 Eugene 2014-01-18 13:58:09 UTC
Created attachment 92333 [details]
xorg.conf file
Comment 54 Eugene 2014-01-18 14:17:19 UTC
Created attachment 92337 [details]
Video through -vo opengl
Comment 55 Eugene 2014-01-18 14:17:55 UTC
Created attachment 92338 [details]
Video through -vo xv
Comment 56 Eugene 2014-01-18 14:38:32 UTC
Sorry, created separate report. My problem differs from topic.
Comment 57 Alexander Tsoy 2014-01-18 14:43:00 UTC
(In reply to comment #50)
> Greetings. Just tried that glamor on my old HD2600 card. And here is my
> results. First, It boots ! And that is very good. But then I started to test
> playing some videos and there I found some issues. If I'm use opengl video
> out device in mplayer or mpv there is no problem but with xv that video is
> monochrome and colours only visible partialy or they fully disappears for
> short time. Please see the screenshots and other logs in attachments.

bug 72821 ?
Comment 58 Eugene 2014-01-18 16:32:44 UTC
No, my report is here: https://bugs.freedesktop.org/show_bug.cgi?id=73765
Comment 59 commiethebeastie 2014-03-04 15:42:27 UTC
GtkPerf 0.40 - Starting testing: Tue Mar  4 19:40:17 2014

GtkEntry - time:  0,04
GtkComboBox - time:  0,68
GtkComboBoxEntry - time:  0,49
GtkSpinButton - time:  0,13
GtkProgressBar - time:  0,29
GtkToggleButton - time:  0,34
GtkCheckButton - time:  0,10
GtkRadioButton - time:  0,21
GtkTextView - Add text - time:  0,36
GtkTextView - Scroll - time:  0,10
GtkDrawingArea - Lines - time: 38,61
GtkDrawingArea - Circles - time: 29,30
GtkDrawingArea - Text - time:  0,93
GtkDrawingArea - Pixbufs - time:  0,38
 --- 
Total time: 71,96


Radeon HD6850 :( Total time with EXA 3 sec.
Comment 60 commiethebeastie 2014-03-04 15:44:41 UTC
attachment 91814 [details] is working too slow.
Comment 61 Marco 2014-04-09 07:14:39 UTC
Something is moving...
I tried keithp glamor branch for xserver here:
http://cgit.freedesktop.org/~keithp/xserver/log/?h=glamor-server
It seems working reliably fast.
Comment 62 Anton L. 2014-04-21 10:30:28 UTC
(In reply to comment #61)
> Something is moving...
> I tried keithp glamor branch for xserver here:
> http://cgit.freedesktop.org/~keithp/xserver/log/?h=glamor-server
> It seems working reliably fast.

Do you use separate glamor library (libglamoregl.so) with it? Did you have direct rendering enabled when testing? What results are produced in gtkperf? Can you attach Xorg.0.log with this xorg version?
Comment 63 Marco 2014-04-21 20:39:59 UTC
> Do you use separate glamor library (libglamoregl.so) with it? Did you have
> direct rendering enabled when testing? What results are produced in gtkperf?
> Can you attach Xorg.0.log with this xorg version?

I used glamor library fromxorg server.
These are the results from gtkperf -a:

Before (master git 1.15.99.901)
GtkPerf 0.40 - Starting testing: Mon Apr 21 21:54:15 2014

GtkEntry - time:  0,00
GtkComboBox - time:  3,04
GtkComboBoxEntry - time:  2,12
GtkSpinButton - time:  1,44
GtkProgressBar - time:  1,21
GtkToggleButton - time:  0,46
GtkCheckButton - time:  0,18
GtkRadioButton - time:  0,26
GtkTextView - Add text - time:  0,58
GtkTextView - Scroll - time:  1,46
GtkDrawingArea - Lines - time: 1360,42
GtkDrawingArea - Circles - time: 908,05
GtkDrawingArea - Text - time: 12,23
GtkDrawingArea - Pixbufs - time:  1,43
 --- 
Total time: 2292,88


After (glamor-server xorg branch from keithp)
GtkPerf 0.40 - Starting testing: Mon Apr 21 21:47:58 2014

GtkEntry - time:  0,00
GtkComboBox - time:  2,02
GtkComboBoxEntry - time:  1,32
GtkSpinButton - time:  0,45
GtkProgressBar - time:  0,39
GtkToggleButton - time:  0,42
GtkCheckButton - time:  0,21
GtkRadioButton - time:  0,26
GtkTextView - Add text - time:  0,52
GtkTextView - Scroll - time:  0,40
GtkDrawingArea - Lines - time: 15,23
GtkDrawingArea - Circles - time: 11,64
GtkDrawingArea - Text - time:  1,53
GtkDrawingArea - Pixbufs - time:  0,65
 --- 
Total time: 35,07

Well, two order of magnitude.... very promising...

Using a low end amd hybrid card (Chipset: "KABINI" (ChipID = 0x9832) HD8330M

Marco
Comment 64 Marco 2014-04-21 20:41:24 UTC
Created attachment 97702 [details]
Xorg.0.log from glamor-server compiled X
Comment 65 Anton L. 2014-04-22 07:29:19 UTC
Thank you, I haven't realised that --enable-glamor configure option is required when building xorg-server from glamor-server branch.
Comment 66 darkbasic 2014-05-19 20:29:42 UTC
If someone is interested I did some tests comparing Keith Packard’s xorg-server glamor-server branch vs Catalyst 14.4 vs Intel SNA:
http://openbenchmarking.org/result/1405080-SO-1405080SO26
Comment 67 Hleb Valoshka 2014-06-19 18:09:22 UTC
Results with 1.16 RC3

GtkEntry - time:  0,07
GtkComboBox - time:  0,56
GtkComboBoxEntry - time:  0,48
GtkSpinButton - time:  0,11
GtkProgressBar - time:  0,03
GtkToggleButton - time:  0,09
GtkCheckButton - time:  0,06
GtkRadioButton - time:  0,12
GtkTextView - Add text - time:  0,38
GtkTextView - Scroll - time:  0,13
GtkDrawingArea - Lines - time:  2,22
GtkDrawingArea - Circles - time:  2,00
GtkDrawingArea - Text - time:  0,52
GtkDrawingArea - Pixbufs - time:  0,41
 --- 
Total time:  7,17
Comment 68 Michel Dänzer 2014-08-04 09:57:28 UTC
glamor from xserver 1.16.0 or particularly from current xserver Git master has greatly improved performance. gtkperf completes in under 3 seconds for me.

Any remaining issues should be tracked in separate reports.