Re: intel hw and caching interface to TTM..

[Dave A. <ai...@li...>]

> >   
> OK. We're using this functionality in Poulsbo, so we should probably
> sort this out to avoid breaking things.

Okay I'll try and fix it back up tomorrow.. 

> Yes, Eric seems to have the same opinion. I'm not quite sure I understand the
> reasoning behind it.
> Is it the added complexity or something else?
> 
> While it's super to have a fast kernel interface, the inherent latency and
> allocation granularity
> will probably always make a user-space sub-allocator a desirable thing.
> Particularly something like a slab
> allocator that would also to some extent avoid fragmentation.
> 
> My view of TTM has changed to be a bit from the opposite side:
> Let's say we have a fast user-space per-client allocator.
> What kernel functionality would we require to make sure that it
> can assume it's the sole owner of the memory it manages?

We have slightly different use-cases, I'm probably more targetting 3d 
desktop uses where sharing buffers is more important (think pixmaps etc) 
so making the allocator go as fast as possible make sense for this case as 
we need to have it in the kernel to do the sharing ...

> For a repeated usage pattern like batch-buffers we end up allocating pages
> from the kernel,
> setting up one VMA per buffer, modifying  gart- and page tables and in the
> worst case even caching policy for each and every use.
> Even if this can be made reasonably fast, I think it's a CPU overhead we
> really shouldn't be paying??

Or we end up allocating a large amount of space to store on-the-fly 
buffers, which requires more tuning per application, some apps may not 
need 65k of batchbuffer space etc..

So while I see the need for suballocators (we need one for glyphs and 
small pixmaps on 2D side in any case) I also see the need to make things 
faster for the non-sub-allocated use case...

So I don't think the goals of 3D driver vs 3D desktop are mutually 
exclusive, I think your work has fone too far towards the single app case 
and our work is trying to pull it back towards our use case..

Dave.