On Monday, April 10, 2017 7:11:18 AM PDT Emil Velikov wrote: > Hi all, > > On 10 April 2017 at 08:18, Kenneth Graunke <kenn...@whitecape.org> wrote: > > From: Daniel Vetter <daniel.vet...@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 <tred...@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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
