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 ? Alan. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
