[Glamor] [PATCH] Increase vbo size to 256K verts.

[He Junyan]

Really, it can benefit aa10text:

256k:
32000000 reps @   0.0002 msec (4940000.0/sec): Char in 80-char aa line 
(Charter 10)
32000000 reps @   0.0002 msec (4810000.0/sec): Char in 80-char aa line 
(Charter 10)
32000000 reps @   0.0002 msec (4710000.0/sec): Char in 80-char aa line 
(Charter 10)
32000000 reps @   0.0002 msec (4710000.0/sec): Char in 80-char aa line 
(Charter 10)
32000000 reps @   0.0002 msec (4710000.0/sec): Char in 80-char aa line 
(Charter 10)
160000000 trep @   0.0002 msec (4770000.0/sec): Char in 80-char aa line 
(Charter 10)

1k:
24000000 reps @   0.0002 msec (4260000.0/sec): Char in 80-char aa line 
(Charter 10)
24000000 reps @   0.0002 msec (4250000.0/sec): Char in 80-char aa line 
(Charter 10)
24000000 reps @   0.0002 msec (4240000.0/sec): Char in 80-char aa line 
(Charter 10)
24000000 reps @   0.0002 msec (4250000.0/sec): Char in 80-char aa line 
(Charter 10)
24000000 reps @   0.0002 msec (4240000.0/sec): Char in 80-char aa line 
(Charter 10)
120000000 trep @   0.0002 msec (4250000.0/sec): Char in 80-char aa line 
(Charter 10)



And the ocitysmap benchmark time seems not stable, maybe the regression 
is just an incidental.
The new result:
1k:
[ # ]  backend                         test   min(s) median(s) stddev. count
[  0]     xlib                    ocitysmap    1.139    1.158   0.88% 
10/10

256k:
[ # ]  backend                         test   min(s) median(s) stddev. count
[  0]     xlib                    ocitysmap    1.136    1.174   1.38% 
10/10




> Increase the vertex buffer can benefit those vertex stressing case such as aa10text.
> But I don't know why it brings some regressions for ocitysmap. I tested it on my machine
> And can't see any regression for ocitysmap.
>
> Anyway, can you test to decrease it to 16*1024 rather than 256K, and see whether it
> eliminate the regression.
>
> And would you also please test whether and how it can benefit aa10text on your machine?
>
> Thanks.
>
>> -----Original Message-----
>> From: He Junyan [mailto:junyan.he at linux.intel.com]
>> Sent: Thursday, August 09, 2012 5:45 PM
>> To: zhigang.gong at linux.intel.com
>> Cc: glamor at lists.freedesktop.org
>> Subject: Re: [Glamor] [PATCH] Increase vbo size to 256K verts.
>>
>> Hi Zhigang:
>>
>> On my IVB, the result is
>>
>>
>> old: small_reslt
>> new: gresult
>> Slowdowns
>> =========
>>    xlib                  ocitysmap  1547.06 (1651.89 3.28%) ->
>> 1884.77
>> (2200.61 7.73%):  1.22x slowdown
>> ▎
>>
>> seems no effect and cause ocitysmap a bit slower.
>>
>>
>>
>>> From: Zhigang Gong <zhigang.gong at linux.intel.com>
>>>
>>> Signed-off-by: Zhigang Gong <zhigang.gong at linux.intel.com>
>>> ---
>>>    src/glamor_fill.c | 1 -
>>>    src/glamor_priv.h | 2 +-
>>>    2 files changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/src/glamor_fill.c b/src/glamor_fill.c index
>>> 1d81aea..2f08d72 100644
>>> --- a/src/glamor_fill.c
>>> +++ b/src/glamor_fill.c
>>> @@ -220,7 +220,6 @@ _glamor_solid_boxes(PixmapPtr pixmap, BoxPtr
>> box, int nbox, float *color)
>>>    		}
>>>    	}
>>>
>>> -#define GLAMOR_COMPOSITE_VBO_VERT_CNT 1024
>>>    	if (unlikely(nbox > 1))
>>>    		dispatch->glBindBuffer(GL_ELEMENT_ARRAY_BUFFER,
>> glamor_priv->ebo);
>>>
>>> diff --git a/src/glamor_priv.h b/src/glamor_priv.h index
>>> 03ef6cc..5cdccf5 100644
>>> --- a/src/glamor_priv.h
>>> +++ b/src/glamor_priv.h
>>> @@ -191,7 +191,7 @@ enum glamor_gl_flavor {
>>>
>>>    #define GLAMOR_NUM_GLYPH_CACHE_FORMATS 2
>>>
>>> -#define GLAMOR_COMPOSITE_VBO_VERT_CNT 1024
>>> +#define GLAMOR_COMPOSITE_VBO_VERT_CNT (256*1024)
>>>
>>>    typedef struct {
>>>    	PicturePtr picture;	/* Where the glyphs of the cache are
>> stored */
>>>
>
> _______________________________________________
> Glamor mailing list
> Glamor at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/glamor
>