> > > 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. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
