[Intel-gfx] GEM memory horror is back :/

Daniel Vetter daniel at ffwll.ch
Sun Apr 11 11:13:43 CEST 2010


On Sun, Apr 11, 2010 at 09:15:20AM +0100, Chris Wilson wrote:
> On Sun, 11 Apr 2010 17:54:16 +1000, Dave Airlie <airlied at gmail.com> wrote:
> > I've wondered before, back when I worked on a TTM driver as well, whether
> > the 1MB needed backing pages allocated to it, or if you just needed a 1MB
> > space in the GTT.
> 
> True. It's a combination of an alignment constraint on both the origin of
> the surface and the pitch, and ensuring that sufficient pages are
> allocated to fulfil tiled access of the last pixel. Being able to have an
> independent num-of-pages and fenced size would be useful... Except that
> the userspace allocator rounds sizes up to the next power of two.
> 
> The simplest method would seem to be another ioctl to set the 'realized'
> size of bo, or perhaps to supply width and height. Size would seem to be
> the most explicit.

I've tossed around ideas like that, too. The next step would be to make
fences independent of the bos, placing multple small bos into on large
fenced region. This way we could save fences, hopefully fixing tiling on
i8xx for xrender (execbuf2 along doesn't help too much, I'll post the
patches + benchmarks shortly).

Of course, this would create memory fragmentation hell. But we only need
fences (and oversized gtt allocations) for the blitter. And that one is
almost exclusively used for pixmaps. So my idea is to create a new tiling
mode, TILING_X_MAX, with a pitch that equals the hw maximum. The pitch
specified in the ioctl would then be the logical width of the buffer.

Of course this requires a 2d-allocator in the gem (with the potential for
gross amounts of fragmentation). But I think restricting the widht to
powers of twos should go a long way towards efficiently handling this (in
combination with a buddy-style allocator). End result:
- all pixmaps can be tiled, not just the ones > 1mb
- no more overallocation by a factor of 4 (worst-case) for large pixmaps
- no gross gtt space wasting (mind the i8xx with feeble amounts of gtt
  space)
- only uses few fences for all pixmaps (I don't think we'll get away with
  just one fence)
And all that without a static fenced region allocation.

</braindump>
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48



More information about the Intel-gfx mailing list