Re: [Dri-devel] radeon & Transition functions

[Keith W. <ke...@tu...>]

Alan Hourihane wrote:
> On Tue, Sep 30, 2003 at 07:35:46PM +0100, Alan Hourihane wrote:
> 
>>On Tue, Sep 30, 2003 at 07:54:00PM +0200, Jacek Rosik wrote:
>>
>>>W liście z wto, 30-09-2003, godz. 19:29, Alan Hourihane pisze: 
>>>
>>>>On Tue, Sep 30, 2003 at 07:21:14PM +0200, Jacek Rosik wrote:
>>>>
>>>>>W liście z wto, 30-09-2003, godz. 18:52, Alan Hourihane pisze: 
>>>>>
>>>>>>In radeon_dri.c in the TransitionTo2d/3d there's some offscreen memory
>>>>>>allocation going on for info->backArea and info->depthTexArea.
>>>>>>
>>>>>>The trouble is - I can't see anywhere where these allocations are actually
>>>>>>used.
>>>>>>
>>>>>>Are these leftovers ??
>>>>>>
>>>>>>Alan.
>>>>>
>>>>>Hi
>>>>>
>>>>>These are used used by 3D driver back depth/stencil buffers and texture
>>>>>memory. This memory is reserved so it wont get overwritten by 2D driver.
>>>>>It is used by means of RADEONInfoRec::frontOffset,
>>>>>RADEONInfoRec::backOffset etc... It can be freed if no 3D is active.
>>>>
>>>> 
>>>>Not from what I can see. The allocation of back, depth/stencil is done
>>>>in radeon_driver.c before passing what's left onto the FBManager. These
>>>>areas are pointed to by info->backOffset, info->depthOffset and 
>>>>info->textureOffset.
>>>
>>>These offsets are only calculated. Only front buffer area is allocated,
>>>rest is left to be allocated only on demand. Memory manager is
>>>initialised  to maximum possible memory then area for framebuffer is
>>>reserved. Lines necessary for other buffers is only calculated.
>>>
>>>
>>>(II) RADEON(0): Memory manager initialized to (0,0) (1152,8191)
>>>(II) RADEON(0): Reserved area from (0,864) to (1152,866)
>>>(II) RADEON(0): Largest offscreen area available: 1152 x 7325
>>>
>>>
>>>>I don't see what purpose info->backArea and info->depthTexArea have.
>>>
>>>Believe me, recently I had quite a few chances to see contents of these
>>>areas and normally they are used by 2D apps (mainly XMMS ;)). So if we
>>>wont reserve them screen corruption may occur.
>>
>> 
>>No they're not. The memory IS allocated because the FBManager is never
>>given it. This is what happens. The front buffer is allocated at the
>>top of video memory. Then some texture memory is grabbed at the bottom
>>of video memory depending on the amount of video ram available. Next,
>>we grab a chunk for the depth buffer and finally for the back buffer.
>>
>>Then if there's more than 8191 scanlines still available we pass a
>>maximum of 8191 off to the FBManager to manage for us. This is what's
>>used by Xv.
> 
> 
> O.k. I've got it. I can see that scanlines is calculated from the total
> FbMapSize and not the remaining after static allocation.
> 
> But what I still don't understand properly is how can we guarantee that
> the backOffset etc, that is passed to the kernel module and backArea
> which is allocated dynamically are pointing to the same location when 
> transitioning ?

I don't know enough about the XFree86 offscreen memory manager, but that's 
they intention of the code - to temporarily give back the 3D buffers for use 
as pixmaps/whatever for the period while no 3d contexts are active.  The trick 
seems to work - but I can't tell you why exactly.

Keith