Re: [RFC] drm/i915: Add variable gem object size support to i915

[Daniel Vetter <daniel@ffwll.ch>]

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