Please attach your xorg log and dmesg output.

Created attachment 84596 [details]
Xorg log

Created attachment 84597 [details]
dmesg

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.

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.

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

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

Is my #68524 a duplicate of this one?

https://bugs.freedesktop.org/show_bug.cgi?id=68524

#68524 is THIS bug report.

*** Bug 70385 has been marked as a duplicate of this bug. ***

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.

@Michel, Sorry, I meant https://bugs.freedesktop.org/show_bug.cgi?id=71813

(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

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

This specific slowdown is as a result of glamor_poly_lines not implementing acceleration for diagonal lines.

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

I tried the patch but it does not fix our gtk issue.

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

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

Basically, one needs to implement support for diagonal lines or improve the fallback handling.  I'm not sure which would be easier off hand.

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/

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

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.

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.

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

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.

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

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

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

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

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.

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.

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.

"polylines: Handle diagonal lines" (https://bugs.freedesktop.org/attachment.cgi?id=91802) definitely fix the Calc issue!

Thanks Aaron Watry!

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!!!

Native backend is still much faster (especially while scrolling), but at least raster is usable now.

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

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

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.

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!

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

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?

"use mi fallbacks for lines" does fix the Calc issue indeed, unfortunately it doesn't fix the raster backend one.

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

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

I forgot to add - I'm using radeonsi with Radeon R9 270.

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

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

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.

Created attachment 92331 [details]
Xorg log file

Created attachment 92332 [details]
dmesg log file

Created attachment 92333 [details]
xorg.conf file

Created attachment 92337 [details]
Video through -vo opengl

Created attachment 92338 [details]
Video through -vo xv

Sorry, created separate report. My problem differs from topic.

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

No, my report is here: https://bugs.freedesktop.org/show_bug.cgi?id=73765

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.

attachment 91814 [details] is working too slow.

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.

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

> 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

Created attachment 97702 [details]
Xorg.0.log from glamor-server compiled X

Thank you, I haven't realised that --enable-glamor configure option is required when building xorg-server from glamor-server branch.

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

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

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.