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. > > > BTW: As I'am working on stereo now I need to allocate additional > > > buffers for left eye buffers. Currently I allocate them whenever > > > TransitionTo3D is called, but I think it would be quite useful if I > > > would add TransitionToStereo/Mono functions and allocate/free them then. > > > I looked at DRICreatedrawable code but I have no clue how to check > > > whether drawable is stereo (if it does make sense). I think I can do it > > > by checking Visual, but no clue how to get it. Can someone give me some > > > clues. > > > > Look in the CreateContext routines to see how to check visuals. > > > > Alan. > THX > > Another question: Is there any reason why memory manager is initialised > to pScrn->displayWidth width? Can it be allocated to > pScrn->displayWidth*2? I know it must fit 8192x8192 area for radon. Is there some requirement that you have to have both stereo buffers next to each other and increase the displayWidth ?? You'd screw up the accelerator normally by doing this, but I don't know what the requirements are for stereo. 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
