<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - radeonsi with glamor has very poor performance with primitives drawing" href="https://bugs.freedesktop.org/show_bug.cgi?id=68524#c20">Comment # 20</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - radeonsi with glamor has very poor performance with primitives drawing" href="https://bugs.freedesktop.org/show_bug.cgi?id=68524">bug 68524</a> from <a class="email" href="mailto:awatry@gmail.com" title="Aaron Watry <awatry@gmail.com>"> Aaron Watry</a> <pre>(In reply to <a href="show_bug.cgi?id=68524#c16">comment #16</a>) > 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>