From mboxrd@z Thu Jan  1 00:00:00 1970
From: Damien Lespiau <damien.lespiau@intel.com>
Subject: Re: [RFC] drm/i915: Add variable gem object size
 support to i915
Date: Wed, 25 Jun 2014 12:14:54 +0100
Message-ID: <20140625111454.GB3938@strange.amr.corp.intel.com>
References: <1398697289-5607-1-git-send-email-arun.siluvery@linux.intel.com>
 <20140625105133.GA3938@strange.amr.corp.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <intel-gfx-bounces@lists.freedesktop.org>
Received: from mga02.intel.com (mga02.intel.com [134.134.136.20])
 by gabe.freedesktop.org (Postfix) with ESMTP id 403846E65B
 for <intel-gfx@lists.freedesktop.org>; Wed, 25 Jun 2014 04:14:56 -0700 (PDT)
Content-Disposition: inline
In-Reply-To: <20140625105133.GA3938@strange.amr.corp.intel.com>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/intel-gfx>,
 <mailto:intel-gfx-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/intel-gfx>
List-Post: <mailto:intel-gfx@lists.freedesktop.org>
List-Help: <mailto:intel-gfx-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/intel-gfx>,
 <mailto:intel-gfx-request@lists.freedesktop.org?subject=subscribe>
Errors-To: intel-gfx-bounces@lists.freedesktop.org
Sender: "Intel-gfx" <intel-gfx-bounces@lists.freedesktop.org>
To: arun.siluvery@linux.intel.com
Cc: intel-gfx@lists.freedesktop.org
List-Id: intel-gfx@lists.freedesktop.org

On Wed, Jun 25, 2014 at 11:51:33AM +0100, Damien Lespiau wrote:
> (This is not necessarily things one would need to take into account for
> this work, just a few thoughts).
> 
> One thing I'm wondering is how fitting the "size" parameter really is
> when talking about inherently 2D buffers.
> 
> For instance, let's take a Y-tiled texture with MIPLAYOUT_RIGHT, if we
> want to allocate mip map levels 0 and 1, and use the ioctl "naively" to
> reserve the LOD1 region in one go, we'll end up over allocating the
> space below LOD1 (if I'm not mistaken that is).
> 
> This can be mitigated by several calls to this fallocate ioctl, to
> reserve columns of pages (in the case above, columns for the LOD1
> region).
> 
> So, how about trying to reduce this ioctl overhead by providing a list
> of (start, length) in the ioctl structure?

One more thing to factor in is (let's assume one future hardware will
support that):
https://www.opengl.org/registry/specs/ARB/sparse_texture.txt

So maybe what we really want is to be able to specify region of pages
that could be specified in (x, y, width, height, stride) ? (idea popped
when talking to Neil Roberts (I now have someone working on Mesa in the
office).

-- 
Damien