On Tue, Sep 13, 2016 at 11:56 AM, Nicolai Hähnle <nhaeh...@gmail.com> wrote:
> Hi,
> there are a bunch of games that allocate huge numbers of small buffers. This
> is especially problematic on amdgpu, where we tend to keep mmaps of buffers
> around for performance, and we hit the limit of 64k simultaneously open
> mmaps. More generally, it leads to very long buffer lists on submissions and
> the associated work in the kernel.
> This series introduces sub-allocation for buffers at the winsys level. That
> is, the winsys presents a regular pb_buffer to the driver, but internally
> allocates it from a bigger "real" buffer.
> Fences are managed for the small, sub-allocated buffers: we don't want to
> have to wait for unrelated buffers that happen to be in the same slab as
> another sub-allocated buffer that is still busy.
> Fences are also used for the parent buffers, but only to make sure that they
> are only really freed/reclaimed once they are fully idle.
> Sub-buffers do not go into the pb_cache when freed. This can be argued either
> way, but I wanted to keep sequential allocations in the same slab where
> possible (for locality), and this is easier with a separate reclaim list.
> When all entries in a large buffer are freed, the large buffer does go into
> the pb_cache.

Good call. pb_cache tends to be congested and too many small buffers
could make it worse.

> There is one aspect where the pb_buffer abstraction becomes leaky: getting a
> handle to a sub-allocated buffer is problematic in terms of process isolation.
> Right now, only textures are shared across process boundaries, and so
> textures are never placed into sub-allocated buffers. In the longer run, if
> we want to export buffers across process boundaries, we should probably
> revisit that and e.g. copy (API level) buffers into their own (kernel leve)
> buffer object when necessary. For now, the winsys just adds an offset.

Hopefully, we'll never have to share buffers between processes.

mesa-dev mailing list

Reply via email to