On Tue, Sep 30, 2003 at 10:05:44PM +0100, 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 ?
O.k. Now I get it all after closer examination. Apologies to Jacek. I think I'm gonna add a little documentation to this after scratching my head for a while there. 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
