>-----Original Message----- >From: dri-devel [mailto:dri-devel-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Daniel Vetter >Sent: Friday, March 16, 2018 1:43 AM >To: Xiong, James <james.xiong@xxxxxxxxx> >Cc: intel-gfx@xxxxxxxxxxxxxxxxxxxxx; dri-devel@xxxxxxxxxxxxxxxxxxxxx >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@xxxxxxxxx> >> >> 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@xxxxxxxxxxxxxxxxxxxxx >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > >-- >Daniel Vetter >Software Engineer, Intel Corporation >http://blog.ffwll.ch >_______________________________________________ >dri-devel mailing list >dri-devel@xxxxxxxxxxxxxxxxxxxxx >https://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
