[PATCH] drm: Add support for two-ended allocation, v2

On Wed, 02 Apr 2014 13:00:00 +0200 Christian K?nig wrote: > Nice idea, but I wouldn't put the decision where to place the buffer > into TTM based on it's size. > > Instead please make that a proper TTM placement flag because for example > for VM page tables we want them to be at the end of VRA

[PATCH] drm: Add support for two-ended allocation, v2

Am 02.04.2014 16:54, schrieb Lauri Kasanen: > On Wed, 02 Apr 2014 13:00:00 +0200 > Christian K?nig wrote: > >> Nice idea, but I wouldn't put the decision where to place the buffer >> into TTM based on it's size. >> >> Instead please make that a proper TTM placement flag because for example >> for

[PATCH] drm: Add support for two-ended allocation, v2

Nice idea, but I wouldn't put the decision where to place the buffer into TTM based on it's size. Instead please make that a proper TTM placement flag because for example for VM page tables we want them to be at the end of VRAM, not because they are big (which they are anyway) but because they

[PATCH] drm: Add support for two-ended allocation, v2

Clients like i915 need to segregate cache domains within the GTT which can lead to small amounts of fragmentation. By allocating the uncached buffers from the bottom and the cacheable buffers from the top, we can reduce the amount of wasted space and also optimize allocation of the mappable portion

[PATCH] drm: Add support for two-ended allocation

Clients like i915 need to segregate cache domains within the GTT which can lead to small amounts of fragmentation. By allocating the uncached buffers from the bottom and the cacheable buffers from the top, we can reduce the amount of wasted space and also optimize allocation of the mappable portion