[Bug 68524] radeonsi with glamor has very poor performance with primitives drawing

[bugzilla-daemon at freedesktop.org]

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

--- Comment #20 from Aaron Watry <awatry at gmail.com> ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-driver-ati/attachments/20140109/3d7b9713/attachment.html>