On Wed, Oct 01, 2003 at 12:02:15AM +0100, Keith Whitwell wrote: > 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.
O.k. I've had time to digest this overnight. :) And I thought something looked fishy and it is...... In low memory configurations the code works fine - where the back, depth and texture memory all fit within the magic 8192 scanlines. But.... In high memory configurations we actually kill a lot of the pixmap cache area for no reason. In this semi-static allocation routine we allocate all the pointer information in radeon_driver.c, and so if you've got a 128MB board all your pointers for the back, depth and texture memory are really low down in memory. Lower than the magic 8192 scanlines. In fact on my 8500, with [EMAIL PROTECTED] I have over 26000 scanlines available. Now, when we come to TransitionTo3D we now grab a bunch of scanlines from the FBManager to save for our back, depth and texture memory again which is wrong. The current allocations sit well outside the FBManager's realm. So in my configuration (to run glxgears) the Xserver ends up pinching 4096 scanlines from the cache for nothing, which is half of the cache area. We need a little more sophisticated checking in the Transition* functions to check for this and for regions that only slightly overlap into the FBManager's alloted area. I'll work on this. 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
