Dave Airlie wrote: >>> >>> >> 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 ... > Agreed. > >> 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.. > Indeed. There are certainly different use-cases. In some cases a sub-allocator is beneficial and in some cases we gain more by not using them. I had a concern that they would be considered generally useless and that the needed kernel support would go away.
/Thomas > 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
