On 06/25/2014 01:57 PM, Damien Lespiau wrote:
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?
That's a good question to ask a GL team. In the light of sparse
textures I think the region idea would be better.
We would need to define what the coordinates mean, for instance:
- 2D view of the buffer, and the kernel takes care of translating what
it means for the underlying pages?
- See the buffer object as an array of pages, and those numbers define
a region of pages.
This would mean kernel has to know about all possible tiling formats?
Would that be asking a bit too much (of the kernel)?
How (im)possible would it be to allocate backing store on demand, on
page by page basis, on write rather than on binding into address space?
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
