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. Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
