From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Siluvery, Arun" Subject: Re: [RFC] drm/i915: Add variable gem object size support to i915 Date: Wed, 25 Jun 2014 12:46:57 +0100 Message-ID: <53AAB6B1.7070107@linux.intel.com> References: <1398697289-5607-1-git-send-email-arun.siluvery@linux.intel.com> <20140625105133.GA3938@strange.amr.corp.intel.com> <20140625111454.GB3938@strange.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by gabe.freedesktop.org (Postfix) with ESMTP id CD58E6E66A for ; Wed, 25 Jun 2014 04:46:59 -0700 (PDT) In-Reply-To: <20140625111454.GB3938@strange.amr.corp.intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Damien Lespiau Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On 25/06/2014 12:14, Damien Lespiau wrote: > 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). > Hi Damien, Thank you for your comments and the idea to improve this ioctl. At the moment start, end of a region are expected to be page-aligned; ioctl can be modified to accept a multiple ranges and modify them in one go to reduce the overhead of the ioctl. We can define how we want to specify multiple ranges, if userspace can provide the list as (start, end) pairs kernel can directly use them but what would be the preferred way from the user point of view? regards Arun