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 > 2.What's the difference between the HW-engine-for-move and GPU? If we use > GPU to do the move, can we treat the two behavior the same? I mean can the > BO's synchronization be achieved through memory manager's fence object? If the GPU only as 3D engine to do everythings (bo move, 2d rendering, 3d) then GPU won't care about manager's fence. If GPU has a separate hw for moving memory then you need fence btw each GPU engine. This fence will be hw specific and likely only the fence id (private to fence implementation) will be use. For instance. DMAEngine move buffer A from system to VRAM, emit fenceid 0xCAFEDEAD 3DEngine want to use buffer A from VRAM, before sending cmd which use buffer you queue a sync command waiting on fenceid 0xCAFEDEAD. This assume hw has such sync mecanism. If it doesn't have such thing then you need to wait in the CPU land until DMAEngine is done before queuing 3D command. Most HW doesn't have such limitation AFAIK (radeon, nvidia, intel). Note that sync btw different engine can be tricky from driver code pov. > 3.Now the BO's synchronization is acted by ttm_bo_wait, which is used in > evict_bo, swapout_bo, cpu_access, bo_cleanup. cpu_access and bo_cleanup need > ttm_bo_wait anyway, while the evict_bo and swapout_bo(assume GPU support > this feature) needn't call ttm_bo_wait since they use the same engine, i.e. > GPU. Am i right? > any comments will be appreciated evict_bo doesn't need ttm_bo_wait. But all others do, swapout_bo is going to swap page to the hard disk so before writing page to the disk we must wait for the gpu to have write those page content into system memory. Cheers, Jerome ------------------------------------------------------------------------------ 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
