>>-----Original Message----- >>From: intel-gfx-bounces+nanhai.zou=intel....@lists.freedesktop.org >>[mailto:intel-gfx-bounces+nanhai.zou=intel....@lists.freedesktop.org] On >>Behalf Of Eric Anholt >>Sent: 2010年5月28日 2:59 >>To: Xiang, Haihao >>Cc: intel-gfx@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.xi...@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.xi...@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 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
