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

[Daniel Vetter]

On Fri, Mar 16, 2018 at 05:10:44PM +0000, Emil Velikov wrote:
> On 16 March 2018 at 08:43, Daniel Vetter <daniel at ffwll.ch> wrote:
> > 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.
> >
> > I think you want to port your changes over to mesa to future proof it,
> > merging this to upstream makes little sense.
> 
> Perhaps it can have in both? After all i915, libva and beignet still
> make use of libdrm_intel.
> The Mesa copy has changed drastically so this series might need serious rework.

Yeah, we can have both, but then the series needs to be updated to have
relative improvements for the stacks still using libdrm. Apparently our
new media stack has it's own copy of libdrm (like everyone else nowadays),
so fairly limited. But I think the platform this was done for is still
using the older libva, so would benefit.

Just want to make sure the commit justification reflects actual upstream
reality instead of what we had 2 years ago.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch