Jerome Glisse wrote: > On Tue, Jan 12, 2010 at 01:03:02AM +0800, Donnie Fang wrote: > >> I want to dig much more into this asynchronous memory manager mechanism. >> Now I have several questions: >> 1.According to Thamos's suggestion, each memory manager will has a fence >> object with it, which is delivered from driver's *move* function, my >> question is what's relationship between the memory manager's fence object >> and each BO's fence object? >> > > Thomas's idea was (AFAICT) that the fence associated to the manager should > always be the lastest one, ie: > fence *fence_lastest(*fencea, *fenceb) > And doing > fence = driver->move(bo, ...) // fence is the same as BO's fence object > lock > manager->fence = fence_lastest(fence, manager->fence) > unlock > > This is true to some extent. The fence that sits on the manager should be the last fence associated with a move out operation from that manager.
This can be extended to allow some granularity: For example instead of having one fence per manager, one could have one fence per free region in the manager, but with each level of optimization we introduce more complexity to the point where noone will be able to understand the code.... /Thomas ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
