[Intel-gfx] [PATCH libdrm 0/5] improve reuse implementation

[Xiong, James]

>-----Original Message-----
>From: dri-devel [mailto:dri-devel-bounces at lists.freedesktop.org] On Behalf Of Daniel Vetter
>Sent: Friday, March 16, 2018 1:43 AM
>To: Xiong, James <james.xiong at intel.com>
>Cc: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org
>Subject: Re: [PATCH libdrm 0/5] improve reuse implementation
>
>On Thu, Mar 15, 2018 at 06:20:09PM -0700, James Xiong wrote:
>> From: "Xiong, James" <james.xiong at intel.com>
>> 
>> With gem_reuse enabled, when a buffer size is different than the sizes 
>> of buckets, it is aligned to the next bucket's size, which means about 
>> 25% more memory than the requested is allocated in the worst senario. 
>> For example:
>> 
>> Orignal size    Actual
>> 32KB+1Byte      40KB
>> .
>> .
>> .
>> 8MB+1Byte       10MB
>> .
>> .
>> .
>> 96MB+1Byte      112MB
>> 
>> This is very memory expensive and make the reuse feature less 
>> favorable than it deserves to be.
>> 
>> This series aligns the reuse buffer size on page size instead to save 
>> memory. Performed gfxbench tests on Gen9 without LLC, the performances 
>> and reuse ratioes (reuse count/allocation count) were same as before, 
>> saved memory usage by 1% ~ 7%(gl_manhattan: peak allocated memory size 
>> was reduced from 448401408 to 419078144).
>> 
>> v2: split the patch to a series of small functional changes (Chris)
>
>Mesa gen driver stopped using the libdrm buffer allocator. The gen2/3 driver still uses it, but I think that's not the one you benchmarked. The
>17.1 release was the first one with that change.
>
Thanks for the tip, Daniel. I tested it on mesa 13.0.5.
>I think you want to port your changes over to mesa to future proof it, merging this to upstream makes little sense.
>-Daniel
I am not sure about mesa and other components that use embedded libdrm, at least for the project I am currently working on, though we have
our owner libdrm repo, we heavily rely on the open source community, and we keep an eye on the upstream and pull in fixes we think might help
 with our customers, actually that's the only way we merge a libdrm patch to our repo. I think it would help to merge the patches to upstream(only
 if the patches make sense of course) so that the component owner can decide themselves whether to take and rebase it to their own, IMHO.
>
>> 
>> Xiong, James (5):
>>   drm: add a macro DRMLISTFOREACHENTRYREVERSE
>>   intel: reorganize internal function
>>   intel: get a cached bucket by size
>>   intel: get a cached buffer by size for reuse
>>   intel: purge cached bucket when its cached buffer is evicted
>> 
>>  intel/intel_bufmgr_gem.c | 180 +++++++++++++++++++++++++----------------------
>>  libdrm_lists.h           |   6 ++
>>  2 files changed, 100 insertions(+), 86 deletions(-)
>> 
>> --
>> 2.7.4
>> 
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>--
>Daniel Vetter
>Software Engineer, Intel Corporation
>http://blog.ffwll.ch
>_______________________________________________
>dri-devel mailing list
>dri-devel at lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel