On 02/08/17 05:59 AM, Eric Anholt wrote: > Scissors provide a critical hint to tiled renderers as to what tiles > need to be load/stored because they could be modified by the > rendering. > > The bounds calculation here is limited to when we have a small number > of rects (large enough to cover rounded window corners, but probably > not xeyes) to avoid overhead on desktop GL. > > No performance difference on i965 with x11perf -rect1 -repeat 1 -reps > 10000 (n=50) > > Signed-off-by: Eric Anholt <e...@anholt.net> > --- > glamor/glamor_rects.c | 26 ++++++++++++++++++++++---- > glamor/glamor_utils.h | 35 +++++++++++++++++++++++++++++++++++ > 2 files changed, 57 insertions(+), 4 deletions(-) > > diff --git a/glamor/glamor_rects.c b/glamor/glamor_rects.c > index cc029c8c04a6..6cbb040c18ea 100644 > --- a/glamor/glamor_rects.c > +++ b/glamor/glamor_rects.c > @@ -53,6 +53,7 @@ glamor_poly_fill_rect_gl(DrawablePtr drawable, > char *vbo_offset; > int box_index; > Bool ret = FALSE; > + BoxRec bounds = glamor_no_rendering_bounds(); > > pixmap_priv = glamor_get_pixmap_private(pixmap); > if (!GLAMOR_PIXMAP_PRIV_HAS_FBO(pixmap_priv)) > @@ -60,6 +61,12 @@ glamor_poly_fill_rect_gl(DrawablePtr drawable, > > glamor_make_current(glamor_priv); > > + if (nrect < 100) { > + bounds = glamor_start_rendering_bounds(); > + for (int i = 0; i < nrect; i++) > + glamor_bounds_union_rect(&bounds, &prect[i]); > + }
Did your testing hit the nrect == 99 cases? I'd expect those to have the most potential impact on throughput. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel