Messages in this thread | | | Date | Thu, 23 Jul 2009 09:27:13 +1000 | Subject | Re: TTM page pool allocator | From | Dave Airlie <> |
| |
On Thu, Jul 23, 2009 at 9:24 AM, Keith Whitwell<keithw@vmware.com> wrote: > On Wed, 2009-07-22 at 15:35 -0700, Jerome Glisse wrote: >> On Wed, 2009-07-22 at 21:13 +0200, Thomas Hellström wrote: >> > 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 >> >> We free reallocate vertex buffer each frame iirc. > > Gears does everything in display lists which means geometry is held in > VBOs retained for the life of the application. Once the first frame is > rendered there shouldn't be any more uploads. >
I don't think the r300 driver does proper vbo's yet.
Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |