[Intel-gfx] [intel-gfx][PATCH] intel: add a new interface drm_intel_bo_alloc_direct

[Zou, Nanhai]

>>-----Original Message-----
>>From: intel-gfx-bounces+nanhai.zou=intel.com at lists.freedesktop.org
>>[mailto:intel-gfx-bounces+nanhai.zou=intel.com at lists.freedesktop.org] On
>>Behalf Of Eric Anholt
>>Sent: 2010年5月28日 2:59
>>To: Xiang, Haihao
>>Cc: intel-gfx at lists.freedesktop.org
>>Subject: Re: [Intel-gfx] [intel-gfx][PATCH] intel: add a new interface
>>drm_intel_bo_alloc_direct
>>
>>On Thu, 27 May 2010 11:22:02 +0800, "Xiang, Haihao" <haihao.xiang at intel.com>
>>wrote:
>>> On Thu, 2010-05-27 at 04:52 +0800, Eric Anholt wrote:
>>> > On Tue, 25 May 2010 13:06:50 +0800, "Xiang, Haihao"
>><haihao.xiang at intel.com> wrote:
>>> > > This interface is the same as drm_intel_bo_alloc except the allocated
>>> > > size isn't rounded up, so it bypasses the cache bucket.
>>> > >
>>> > > The size of the BO created by drm_intel_bo_alloc for a 1920x800,4:2:0
>>YUV
>>> > > planar surface is 4M, it is about 2.2M if using drm_intel_bo_alloc_direct.
>>> >
>>> > You could just init a cache bucket of that size, and get BO caching with
>>> > no overhead and no new interfaces.
>>>
>>> I ever considered modifying the cache bucket, including a new interface
>>> to override the default cache bucket. The problem is that the the size
>>> of the surface BO and related BO may vary from case to case, we don't
>>> know the right size when initializing cache bucket.
>>
>>We should probably just make a bunch more buckets.  It's not like video
>>is the only thing that suffers from overallocation.  Mipmapped textures
>>will tend to be 1.5 times a power of two in size.


Maybe a new API to create a new size of bucket, because sizes of buckets in libdrm can not precisely match app's requests.

Another issue to use the built-in buckets in libdrm for H.264 is that libdrm is
doing too much caching than necessary.

Thanks
Zou Nan hai