[Mesa-dev] Backporting bufmgr fixes to libdrm_intel (Was Re: [PATCH 6/9] i965/bufmgr: Garbage-collect vma cache/pruning)

[Kenneth Graunke]

On Monday, April 10, 2017 7:11:18 AM PDT Emil Velikov wrote:
> Hi all,
> 
> On 10 April 2017 at 08:18, Kenneth Graunke <kenneth at whitecape.org> wrote:
> > From: Daniel Vetter <daniel.vetter at ffwll.ch>
> >
> > This was done because the kernel has 1 global address space, shared
> > with all render clients, for gtt mmap offsets, and that address space
> > was only 32bit on 32bit kernels.
> >
> > This was fixed  in
> >
> > commit 440fd5283a87345cdd4237bdf45fb01130ea0056
> > Author: Thierry Reding <treding at nvidia.com>
> > Date:   Fri Jan 23 09:05:06 2015 +0100
> >
> >     drm/mm: Support 4 GiB and larger ranges
> >
> > which shipped in 4.0. Of course you still want to limit the bo cache
> > to a reasonable size on 32bit apps to avoid ENOMEM, but that's better
> > solved by tuning the cache a bit. On 64bit, this was never an issue.
> >
> While this patch is _not_ a bugfix, it inspired an interesting question/topic:
> 
> Do we want to backport fixes from mesa's bufmgr to libdrm_intel?
> 
> Or in general what's the plan about the library - leave it as-is, sync
> fixes, remove it, other.
> Can we have the decision documented somewhere, please?
> 
> After all: good science/engineering is good documentation.
> 
> Thanks
> Emil

It makes sense to backport bug fixes, given that there are still
libdrm_intel uses out there (libva, beignet, i915_dri).

That said, brw_bufmgr is diverging enough that backporting fixes
probably means reimplementing the same idea in the other codebase.
If we find a nasty bug, we certainly should, but I imagine most
patches won't apply and that's OK.

--Ken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170410/7cb89da1/attachment.sig>