Re: TTM eviction & ghost object

Re: TTM eviction & ghost object

[Donnie Fang]

[-- Attachment #1.1: Type: text/plain, Size: 2337 bytes --]

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?
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?
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

2009/12/16 Jerome Glisse <glisse@freedesktop.org>

> On Wed, Dec 16, 2009 at 12:12:13AM +0800, Donnie Fang wrote:
> > Hi Thomas,
> >       I conclude your meaning as below:
> > a. When CPU join in, it must wait for the sync object to really free the
> > device address space.
> > b. When CPU absent, but there are two indepent HW engines relevant to the
> > space, the one must wait for the sync object.
> > c.  Fully pipelined bo move support when only one HW engine related to
> the
> > space.
> > Am i right?
> > About *b*, let's say,
> > 1)schedule copy the bo from VRAM based on HW DMA engine.
> > 2) Put a corresponding sync object on the manager.
> > 3) Free the vram region.
> > 4) Region gets allocated.
> > 5) GPU 2D render to this region.
> > since GPU 2D and HW DMA engine is totally independent from each other, so
> > sync object still needs to be signaled in this situation.
>
> Some hw have way to synchronize btw different part of the GPU so for
> instance you can tell the 2D pipeline to wait on the hw dma engine before
> doing any work. If hw doesn't have such synchronization capabilities
> i believe it's better to only use 1 pipeline of the hw (so forget about
> hw dma engine and do bo move using the 2d or 3d engine), otherwise you
> will have to put the CPU in the loop and that would mean stalling the
> GPU (will more than likely end up in suboptimal use of the GPU).
>
> Cheers,
> Jerome
>

[-- Attachment #1.2: Type: text/html, Size: 2883 bytes --]

[-- Attachment #2: Type: text/plain, Size: 390 bytes --]

------------------------------------------------------------------------------
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 

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: TTM eviction & ghost object

[Jerome Glisse]

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 
--

Re: TTM eviction & ghost object

[Thomas Hellström]

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 
--