From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [RFC] drm/i915: Add variable gem object size support to i915 Date: Mon, 7 Jul 2014 10:34:54 +0200 Message-ID: <20140707083454.GD5821@phenom.ffwll.local> 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> <53AAB6B1.7070107@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by gabe.freedesktop.org (Postfix) with ESMTP id AC2D988ED6 for ; Mon, 7 Jul 2014 01:34:47 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id n15so6254024wiw.17 for ; Mon, 07 Jul 2014 01:34:45 -0700 (PDT) Content-Disposition: inline In-Reply-To: <53AAB6B1.7070107@linux.intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: "Siluvery, Arun" Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Wed, Jun 25, 2014 at 12:46:57PM +0100, Siluvery, Arun wrote: > 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? This smells badly like premature optimization. For y-tiled a page-row is 32 lines which means even for giant mipmap levels we'll deal with just a few ioctls to establish/remove a mipmap level. If you can benchmark this in a real-world tests (or even a microbenchmark that includes a little bit of texture upload) I'll be impressed. So a linear start/end, page-aligned, sounds more than good enough to me for now. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch