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

Reply via email to