Jerome Glisse wrote: > On Thu, 2009-11-19 at 16:29 +0800, Donnie Fang wrote: > >> Hi all, >> after reviewed the radeon fence scheme, there are lots of chances >> that it needs create a new fence object, and also there are lots of >> chances need to destroy these fence objects. >> In my opinion, is it possible to maintain a list for recording >> some freed fence object for later usage and hence save performance. Am >> i right? >> Donnie. >> >> > > Idea is that kernel allocator already do that for us. I would like to > avoid having many pools in the driver, i don't think it's well behaving > to do so. And fence are small enough to take advantage of any slab/slub > allocator kernel has. > > However if you have benchmark that shows that fence allocation is > slowing down, by huge margin, application than we might consider doing > so. But i don't think fence are biggest bottleneck, i am pretty sure > memory management is. > > Cheers, > Jerome > > I've also had some concerns about fence object allocation / destruction in the past, but it seems, just like Jerome points out, that the slab / slub allocator does its job just fine, and I've never seen this end up high on benchmarks.
/Thomas > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > -- > _______________________________________________ > Dri-devel mailing list > Dri-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dri-devel > ------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel