[Mesa-dev] [PATCH 0/7] vbo: introduce a minmax_index cache

[Roland Scheidegger]

Am 08.01.2016 um 05:01 schrieb Timothy Arceri:
> On Thu, 2016-01-07 at 19:57 -0500, Nicolai Hähnle wrote:
>> Hi,
>>
>> this series is intended to address a (big) part of the performance
>> problems
>> that occur when games use an index buffer from a VBO together with
>> vertex
>> attributes supplied by user pointer. On a lower-end Radeon (Carrizo),
>> it
>> lifts This War Of Mine (the worst offender I've seen) from basically
>> unplayable
>> to an acceptable ~22fps.
> 
> Hi Nicolai,
> 
> A while back I added a SSE41 min/max optimisation for the INT path. I
> never added it to BYTE/SHORT as the games I was benchmarking never hit
> those paths. It would be interesting to know which path "This War Of
> Mine" is hitting.

I always thought ushort index buffers were quite popular. IIRC there was
even hardware which didn't support 32bit index buffers, but just 16bit
ones. Albeit not 8bit ones, those are just too limiting (and they'd
pretty much have to be small, well technically not but how useful could
a large index buffer with just 8bit indices be...).
But maybe they got out of fashion - they'd have the advantage you could
do them with just sse2 with minimal additional cost though (just two
xors per loop iteration ;-)). Though of course argued that way the ubyte
ones you could handle with just sse2 natively...
I wonder if there's apps which are using this and also restart index -
could of course handle that as well pretty easily (albeit another
comparison, plus two pblendvb with sse41 per loop iteration).
Theoretically the sse2/41 assembly should be even more of a win for
16bit buffers than 32bit buffers of course.
I am wondering if there's compilers trying to auto-vectorize that on
their own...

Roland


> 
> A quick Google shows Carrizo should have SSE41 right?
> 
> 
> 
>>
>> There are really two parts to the performance inefficiency:
>> (1) the fact that we have to compute min/max in the first place
>> (2) the fact that games developers like to helpfully declare the
>> index buffer
>> as STATIC_DRAW, which means it ends up in VRAM, making things much
>> worse than
>> they would be with (1) alone.
>>
>> The series does this simply by caching (or memoizing, if you like)
>> the result
>> of vbo_get_minmax_indices. This makes sense since while the caching
>> itself of
>> course has some overhead, it is only used for VBOs - and the people
>> who mix
>> VBO index buffers with non-VBO vertex data seem to do so precisely
>> because
>> their index buffers are static, hence caching is a win.
>>
>> The cache is disabled permanently for VBOs that we detect to be
>> written to by
>> GPU operations. It is invalidated on other writes (Buffer(Sub)Data
>> etc.).
>>
>> I originally considered putting the caching in st/mesa instead of
>> vbo, but that
>> would have required duplicating some of the logic in
>> vbo_get_minmax_indices for
>> iterating over primitives inside the Gallium statetracker. I wanted
>> to avoid
>> this code duplication, hence why I put it in vbo.
>>
>> Please review!
>>
>> Thanks,
>> Nicolai
>> --
>>  src/mesa/Makefile.sources             |   1 +
>>  src/mesa/main/bufferobj.c             |  41 +++-
>>  src/mesa/main/mtypes.h                |   7 +
>>  src/mesa/main/transformfeedback.h     |   3 +
>>  src/mesa/vbo/vbo.h                    |   3 +
>>  src/mesa/vbo/vbo_exec_array.c         | 148 ------------
>>  src/mesa/vbo/vbo_minmax_index.c       | 342
>> ++++++++++++++++++++++++++++
>>  src/util/hash_table.c                 |  25 ++
>>  src/util/hash_table.h                 |   2 +
>>  src/util/tests/hash_table/Makefile.am |   1 +
>>  src/util/tests/hash_table/clear.c     |  91 ++++++++
>>  11 files changed, 507 insertions(+), 157 deletions(-)
>>
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>