Jerome Glisse wrote: > On Wed, 2009-07-22 at 15:16 +0200, Michel Dänzer wrote: > >> On Tue, 2009-07-21 at 21:22 +0200, Jerome Glisse wrote: >> >>> On Tue, 2009-07-21 at 20:00 +0200, Jerome Glisse wrote: >>> >>>> On Tue, 2009-07-21 at 19:34 +0200, Jerome Glisse wrote: >>>> >>>>> On Thu, 2009-06-25 at 17:53 +0200, Thomas Hellström wrote: >>>>> >>>>>> 4) We could now skip the ttm_tt_populate() in ttm_tt_set_caching, since >>>>>> it will always allocate cached pages and then transition them. >>>>>> >>>>>> >>>>> Okay 4) is bad, what happens (my brain is a bit meltdown so i might be >>>>> wrong) : >>>>> 1 - bo get allocated tt->state = unpopulated >>>>> 2 - bo is mapped few page are faulted tt->state = unpopulated >>>>> 3 - bo is cache transitioned but tt->state == unpopulated but >>>>> they are page which have been touch by the cpu so we need >>>>> to clflush them and transition them, this never happen if >>>>> we don't call ttm_tt_populate and proceed with the remaining >>>>> of the cache transitioning functions >>>>> >>>>> As a workaround i will try to go through the pages tables and >>>>> transition existing pages. Do you have any idea for a better >>>>> plan ? >>>>> >>>>> Cheers, >>>>> Jerome >>>>> >>>> My workaround ruin the whole idea of pool allocation what happens >>>> is that most bo get cache transition page per page. My thinking >>>> is that we should do the following: >>>> - is there is a least one page allocated then fully populate >>>> the object and do cache transition on all the pages. >>>> - otherwise update caching_state and leaves object unpopulated >>>> >>>> This needs that we some how reflect the fact that there is at least >>>> one page allocated, i am thinking to adding a new state for that : >>>> ttm_partialy_populated >>>> >>>> Thomas what do you think about that ? >>>> >>>> Cheers, >>>> Jerome >>>> >>> Attached updated patch it doesn't introduce ttm_partialy_populated >>> but keep the populate call in cache transition. So far it seems to >>> work properly on AGP platform >>> >> Yeah, this one works for me as well. >> >> >>> and helps quite a lot with performances. >>> >> Can't say I've noticed that however. How did you measure? >> > > gears Hmm, In gears there shouldn't really be any buffer allocation / freeing going on at all once the display lists are set up, and gears should really be gpu bound in most cases.
what's the source of the buffer allocations / frees when gears is run? /Thomas ------------------------------------------------------------------------------ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
