W liście z wto, 30-09-2003, godz. 20:35, Alan Hourihane pisze: > 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. No, there is no such requirement. I was just asking whether I'll screw up something if I change it ;), Thanks.
-- Jacek Rosik <[EMAIL PROTECTED]> ------------------------------------------------------- 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
