Big series, a lot to take in! But from what I can tell, Reviewed-by: Edward O'Callaghan <[email protected]>
Obviously someone else's Rb would be good too due how big this change is. Thanks for breaking it down the way you did though! On 09/13/2016 07:56 PM, Nicolai Hähnle 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. > > 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. > > Please review! Thanks, > Nicolai > -- > src/gallium/auxiliary/Makefile.sources | 2 + > src/gallium/auxiliary/pipebuffer/pb_cache.h | 2 +- > src/gallium/auxiliary/pipebuffer/pb_slab.c | 195 ++++++++++ > src/gallium/auxiliary/pipebuffer/pb_slab.h | 115 ++++++ > src/gallium/auxiliary/util/u_math.h | 12 + > src/gallium/drivers/r300/r300_emit.c | 19 +- > src/gallium/drivers/r300/r300_texture.c | 2 +- > src/gallium/drivers/radeon/r600_cs.h | 6 +- > src/gallium/drivers/radeon/r600_texture.c | 2 + > src/gallium/drivers/radeon/radeon_uvd.c | 3 +- > src/gallium/drivers/radeon/radeon_vce.c | 3 +- > src/gallium/drivers/radeon/radeon_winsys.h | 11 +- > src/gallium/winsys/amdgpu/drm/amdgpu_bo.c | 330 +++++++++++++--- > src/gallium/winsys/amdgpu/drm/amdgpu_bo.h | 47 ++- > src/gallium/winsys/amdgpu/drm/amdgpu_cs.c | 248 +++++++++--- > src/gallium/winsys/amdgpu/drm/amdgpu_cs.h | 26 +- > .../winsys/amdgpu/drm/amdgpu_winsys.c | 13 + > .../winsys/amdgpu/drm/amdgpu_winsys.h | 5 + > .../winsys/radeon/drm/radeon_drm_bo.c | 331 +++++++++++++++-- > .../winsys/radeon/drm/radeon_drm_bo.h | 40 +- > .../winsys/radeon/drm/radeon_drm_cs.c | 228 +++++++++--- > .../winsys/radeon/drm/radeon_drm_cs.h | 16 +- > .../winsys/radeon/drm/radeon_drm_winsys.c | 26 +- > .../winsys/radeon/drm/radeon_drm_winsys.h | 7 + > 24 files changed, 1449 insertions(+), 240 deletions(-) > > _______________________________________________ > mesa-dev mailing list > [email protected] > https://lists.freedesktop.org/mailman/listinfo/mesa-dev >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
