Michel Dänzer <[email protected]> writes: > 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 <[email protected]> >> --- >> 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.
No, I didn't. However, the other two patches were nrect=1 cases in x11perf, which I think would be even more impacted than nrect=99, and they showed improvements.
signature.asc
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
