From: Alan H. <al...@fa...> - 2003-09-30 16:53:46
|
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. |
From: Jacek R. <jr...@us...> - 2003-09-30 17:23:07
|
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. 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. -- Jacek Rosik <jr...@us...> |
From: Alan H. <al...@fa...> - 2003-09-30 17:30:44
|
On Tue, Sep 30, 2003 at 07:21:14PM +0200, Jacek Rosik wrote: > W li=C5=9Bcie z wto, 30-09-2003, godz. 18:52, Alan Hourihane pisze:=20 > > In radeon_dri.c in the TransitionTo2d/3d there's some offscreen memor= y > > allocation going on for info->backArea and info->depthTexArea. > >=20 > > The trouble is - I can't see anywhere where these allocations are act= ually > > used. > >=20 > > Are these leftovers ?? > >=20 > > Alan. > Hi >=20 > 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. =20 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=20 info->textureOffset. I don't see what purpose info->backArea and info->depthTexArea have. > 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.=20 Look in the CreateContext routines to see how to check visuals. Alan. |
From: Jacek R. <jr...@us...> - 2003-09-30 17:57:18
|
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. > > 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. -- Jacek Rosik <jr...@us...> |
From: Keith W. <ke...@tu...> - 2003-09-30 20:11:04
|
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. This is my understanding also. We used to statically allocate the buffers, but Mark V. changed it so the driver frees the memory for use as pixmap cache/whatever when there are no active 3d contexts. This is less good in some respects than dynamically allocated private back and depth buffers, but it has the nice effect of not crippling 2d when 3d is not active. Keith |
From: Jacek R. <jr...@us...> - 2003-10-01 07:29:22
|
W liście z wto, 30-09-2003, godz. 22:02, Keith Whitwell pisze: > 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. > > This is my understanding also. We used to statically allocate the buffers, > but Mark V. changed it so the driver frees the memory for use as pixmap > cache/whatever when there are no active 3d contexts. > > This is less good in some respects than dynamically allocated private back and > depth buffers, but it has the nice effect of not crippling 2d when 3d is not > active. > > Keith Is there a plan to move to dynamic allocation someday? Has anybody worked on it? Do all the drivers use this semi-static allocation scheme? -- Jacek Rosik <jr...@us...> |
From: Alan H. <al...@fa...> - 2003-10-01 10:43:50
|
On Wed, Oct 01, 2003 at 09:29:13AM +0200, Jacek Rosik wrote: > Is there a plan to move to dynamic allocation someday? Has anybody > worked on it? Do all the drivers use this semi-static allocation scheme? It would be nice to move to full dynamic allocation although that's some work. Not all drivers do ahve this semi-static allocation scheme. Alan. |
From: Ian R. <id...@us...> - 2003-10-01 15:55:37
|
Jacek Rosik wrote: > W li=B6cie z wto, 30-09-2003, godz. 22:02, Keith Whitwell pisze:=20 >=20 >>This is less good in some respects than dynamically allocated private b= ack and=20 >>depth buffers, but it has the nice effect of not crippling 2d when 3d i= s not=20 >>active. >=20 > Is there a plan to move to dynamic allocation someday? Has anybody > worked on it? Do all the drivers use this semi-static allocation scheme= ? I have done *some* work on it, but not for a very long time. I hope to=20 get back to it sometime before my hair turns gray. :) You should search=20 the archives for texmem-0-0-2 or perhaps texmem-0-1-0. The idea was to=20 rewrite the texture memory allocator so that blocks of memory could be=20 pinned (i.e., not stolen by other contexts). This mode of allocation=20 could then be used for back-buffers, depth-buffers, front-buffers for=20 pbuffers, acceleration of CopyTexImage, acceleration of=20 SGIS_generate_mipmaps, and others. I did a fair amount of work on a=20 user-mode mock-up of the allocator. There are a couple race conditions=20 in it that I want to resolve before sending it to the list. |
From: Alan H. <al...@fa...> - 2003-09-30 18:36:56
|
On Tue, Sep 30, 2003 at 07:54:00PM +0200, Jacek Rosik wrote: > W li=C5=9Bcie z wto, 30-09-2003, godz. 19:29, Alan Hourihane pisze:=20 > > On Tue, Sep 30, 2003 at 07:21:14PM +0200, Jacek Rosik wrote: > > > W li=C5=9Bcie z wto, 30-09-2003, godz. 18:52, Alan Hourihane pisze:= =20 > > > > In radeon_dri.c in the TransitionTo2d/3d there's some offscreen m= emory > > > > allocation going on for info->backArea and info->depthTexArea. > > > >=20 > > > > The trouble is - I can't see anywhere where these allocations are= actually > > > > used. > > > >=20 > > > > Are these leftovers ?? > > > >=20 > > > > Alan. > > > Hi > > >=20 > > > These are used used by 3D driver back depth/stencil buffers and tex= ture > > > memory. This memory is reserved so it wont get overwritten by 2D dr= iver. > > > It is used by means of RADEONInfoRec::frontOffset, > > > RADEONInfoRec::backOffset etc... It can be freed if no 3D is active. > > =20 > > Not from what I can see. The allocation of back, depth/stencil is don= e > > in radeon_driver.c before passing what's left onto the FBManager. The= se > > areas are pointed to by info->backOffset, info->depthOffset and=20 > > info->textureOffset. >=20 > 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. >=20 >=20 > (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 >=20 > > I don't see what purpose info->backArea and info->depthTexArea have. >=20 > 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. =20 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 d= o it > > > by checking Visual, but no clue how to get it. Can someone give me = some > > > clues.=20 > >=20 > > Look in the CreateContext routines to see how to check visuals. > >=20 > > Alan. > THX >=20 > 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. |
From: Alan H. <al...@fa...> - 2003-09-30 21:06:56
|
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=C5=9Bcie z wto, 30-09-2003, godz. 19:29, Alan Hourihane pisze:=20 > > > On Tue, Sep 30, 2003 at 07:21:14PM +0200, Jacek Rosik wrote: > > > > W li=C5=9Bcie z wto, 30-09-2003, godz. 18:52, Alan Hourihane pisz= e:=20 > > > > > In radeon_dri.c in the TransitionTo2d/3d there's some offscreen= memory > > > > > allocation going on for info->backArea and info->depthTexArea. > > > > >=20 > > > > > The trouble is - I can't see anywhere where these allocations a= re actually > > > > > used. > > > > >=20 > > > > > Are these leftovers ?? > > > > >=20 > > > > > Alan. > > > > Hi > > > >=20 > > > > These are used used by 3D driver back depth/stencil buffers and t= exture > > > > 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 acti= ve. > > > =20 > > > Not from what I can see. The allocation of back, depth/stencil is d= one > > > in radeon_driver.c before passing what's left onto the FBManager. T= hese > > > areas are pointed to by info->backOffset, info->depthOffset and=20 > > > info->textureOffset. > >=20 > > These offsets are only calculated. Only front buffer area is allocate= d, > > 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. > >=20 > >=20 > > (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 > >=20 > > > I don't see what purpose info->backArea and info->depthTexArea have. > >=20 > > Believe me, recently I had quite a few chances to see contents of the= se > > areas and normally they are used by 2D apps (mainly XMMS ;)). So if w= e > > wont reserve them screen corruption may occur. > =20 > 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. >=20 > 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=20 transitioning ? Alan. |
From: Keith W. <ke...@tu...> - 2003-09-30 23:02:49
|
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. Keith |
From: Alan H. <al...@fa...> - 2003-10-01 08:44:13
|
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=C5=9Bcie z wto, 30-09-2003, godz. 19:29, Alan Hourihane pisze:=20 > >>> > >>>>On Tue, Sep 30, 2003 at 07:21:14PM +0200, Jacek Rosik wrote: > >>>> > >>>>>W li=C5=9Bcie z wto, 30-09-2003, godz. 18:52, Alan Hourihane pisze= :=20 > >>>>> > >>>>>>In radeon_dri.c in the TransitionTo2d/3d there's some offscreen m= emory > >>>>>>allocation going on for info->backArea and info->depthTexArea. > >>>>>> > >>>>>>The trouble is - I can't see anywhere where these allocations are= =20 > >>>>>>actually > >>>>>>used. > >>>>>> > >>>>>>Are these leftovers ?? > >>>>>> > >>>>>>Alan. > >>>>> > >>>>>Hi > >>>>> > >>>>>These are used used by 3D driver back depth/stencil buffers and te= xture > >>>>>memory. This memory is reserved so it wont get overwritten by 2D=20 > >>>>>driver. > >>>>>It is used by means of RADEONInfoRec::frontOffset, > >>>>>RADEONInfoRec::backOffset etc... It can be freed if no 3D is activ= e. > >>>> > >>>> > >>>>Not from what I can see. The allocation of back, depth/stencil is d= one > >>>>in radeon_driver.c before passing what's left onto the FBManager. T= hese > >>>>areas are pointed to by info->backOffset, info->depthOffset and=20 > >>>>info->textureOffset. > >>> > >>>These offsets are only calculated. Only front buffer area is allocat= ed, > >>>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 th= ese > >>>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 neve= r > >>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 botto= m > >>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 tota= l > >FbMapSize and not the remaining after static allocation. > > > >But what I still don't understand properly is how can we guarantee tha= t > >the backOffset etc, that is passed to the kernel module and backArea > >which is allocated dynamically are pointing to the same location when=20 > >transitioning ? >=20 > I don't know enough about the XFree86 offscreen memory manager, but tha= t's=20 > they intention of the code - to temporarily give back the 3D buffers fo= r=20 > use as pixmaps/whatever for the period while no 3d contexts are active.= =20 > 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 inform= ation 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. Low= er than the magic 8192 scanlines. In fact on my 8500, with 1280x1024@32bpp I have over 26000 scanlines available.=20 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 are= a. 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. |
From: Jacek R. <jr...@us...> - 2003-10-01 07:26:58
|
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 <jr...@us...> |
From: Jacek R. <jr...@us...> - 2003-10-05 11:42:07
|
W liście z wto, 30-09-2003, godz. 19:29, Alan Hourihane pisze: > > 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. Ok I got it, but I have a question. In DRITransitionXXXXX functions in dri.c DRIClipNotifyAllDrawables is called. I don't quite understand purpose of this functions but I think it should also get called in my DRITransitionToStereo/Mono as functionality is more less the same as DRITransitiontoShared/PrivateBuffers. Correct me if I'm wrong. -- Jacek Rosik <jr...@us...> |
From: Keith W. <ke...@tu...> - 2003-10-06 08:39:28
|
Jacek Rosik wrote: > W liście z wto, 30-09-2003, godz. 19:29, Alan Hourihane pisze: > > >>>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. > > > Ok I got it, but I have a question. In DRITransitionXXXXX functions in > dri.c DRIClipNotifyAllDrawables is called. I don't quite understand > purpose of this functions but I think it should also get called in my > DRITransitionToStereo/Mono as functionality is more less the same as > DRITransitiontoShared/PrivateBuffers. Correct me if I'm wrong. > This function sets a flag in shared memory to let each client know that their cliprects have changed. When they next grab the lock, they'll notice this and issue a request to the X server to get the current cliprects. Keith |
From: Jacek R. <jr...@us...> - 2003-10-06 13:02:13
|
W li=B6cie z pon, 06-10-2003, godz. 10:38, Keith Whitwell pisze:=20 > > Ok I got it, but I have a question. In DRITransitionXXXXX functions i= n > > dri.c DRIClipNotifyAllDrawables is called. I don't quite understand > > purpose of this functions but I think it should also get called in my > > DRITransitionToStereo/Mono as functionality is more less the same as > > DRITransitiontoShared/PrivateBuffers. Correct me if I'm wrong. > >=20 >=20 > This function sets a flag in shared memory to let each client know that= their=20 > cliprects have changed. When they next grab the lock, they'll notice t= his and=20 > issue a request to the X server to get the current cliprects. >=20 > Keith Hi Thanks figured it out too. Now my implementation switches to quadbuffers only when stereo drawable is present. But I have run into some problems. In quadbuffer mode stereosoptic and monosoptic applications rendering to=20 back buffer work fine. The problem is when monosoptic app renders to fron= t buffer,=20 then a software fallback is required (it must render into front left and = front right). So when stereo drawable is created all those apps must switch to = software fallbacks. Is it Ok to switch to fallback in radeonGetLock? Even if so th= en part of the frame may be already rendered to only one buffer. So what I t= hink of now is to flush all pending drawing operations copy left -> right and the= n switch to fallback. It my be quite hard with my current knowledge about radeon p= ipeline so I have to educate myself. Could You point me towhere to start looking? I know that vertex are accumulated and then are sent to the hardware. Is it possible (hard?) to do something like this in order to render=20 into more than buffer. radeonSetBuffer(GL_FRONT_LEFT) radeonSendDataToHardware(); radeonSetBuffer(GL_FRONT_RIGHT) radeonSendDataToHardware(); Another problem is that when using shadowfb in order to update other buff= ers and 3d window is moved contents of right buffer get overwritten by contents o= f left one. Is there a way to disable shadowfb for 3d windows? Regards --=20 Jacek Rosik <jr...@us...> -- ------------------------ konta e-mail 100 MB od 3 zl m-c serwery www 60 MB od 7 zl m-c AlphaNet, www.alpha.pl=20 ------------------------ |
From: Keith W. <ke...@tu...> - 2003-10-06 13:29:06
|
Jacek Rosik wrote: > W lis'cie z pon, 06-10-2003, godz. 10:38, Keith Whitwell pisze: > >>>Ok I got it, but I have a question. In DRITransitionXXXXX functions in >>>dri.c DRIClipNotifyAllDrawables is called. I don't quite understand >>>purpose of this functions but I think it should also get called in my >>>DRITransitionToStereo/Mono as functionality is more less the same as >>>DRITransitiontoShared/PrivateBuffers. Correct me if I'm wrong. >>> >> >>This function sets a flag in shared memory to let each client know that their >>cliprects have changed. When they next grab the lock, they'll notice this and >>issue a request to the X server to get the current cliprects. >> >>Keith > > Hi > > Thanks figured it out too. Now my implementation switches to quadbuffers > only when stereo drawable is present. But I have run into some problems. > In quadbuffer mode stereosoptic and monosoptic applications rendering to > back buffer work fine. The problem is when monosoptic app renders to front buffer, > then a software fallback is required (it must render into front left and front > right). So when stereo drawable is created all those apps must switch to software > fallbacks. Is it Ok to switch to fallback in radeonGetLock? Even if so then > part of the frame may be already rendered to only one buffer. So what I think of > now is to flush all pending drawing operations copy left -> right and then switch > to fallback. It my be quite hard with my current knowledge about radeon pipeline > so I have to educate myself. Could You point me towhere to start looking? > > I know that vertex are accumulated and then are sent to the hardware. > Is it possible (hard?) to do something like this in order to render > into more than buffer. > > radeonSetBuffer(GL_FRONT_LEFT) > radeonSendDataToHardware(); > radeonSetBuffer(GL_FRONT_RIGHT) > radeonSendDataToHardware(); Yes, that sort of thing is possible. If you look at the older 3d drivers, eg. r128, you'll see that we had to use a loop to dispatch regular vertices as we could only send a few cliprects to the kernel at a time. You could do a similar loop over the two buffers. > Another problem is that when using shadowfb in order to update other buffers and > 3d window is moved contents of right buffer get overwritten by contents of left one. > Is there a way to disable shadowfb for 3d windows? Shadowfb is only used for pageflipping, right? Keith |
From: Jacek R. <jr...@us...> - 2003-10-06 17:48:19
|
W li=B6cie z pon, 06-10-2003, godz. 15:28, Keith Whitwell pisze:=20 > > Another problem is that when using shadowfb in order to update other = buffers and > > 3d window is moved contents of right buffer get overwritten by conten= ts of left one. > > Is there a way to disable shadowfb for 3d windows? >=20 > Shadowfb is only used for pageflipping, right? I don't quite know what You mean. Generally it works like pageflipping but I have four buffers. In case of one 3d stereosoptic window I switch right<->left on vblank and front<->back when buffer swap is performed. If there are several 3d wndows and at least one is stereosoptic then i switch only left<->right on vblank. So all the time I use shadowfb need to keep front_right updated and sometimes back_left, back_right too. If You mean whether I use it to any other purpose, then I don't. I can post a patch when I clean it a little bit. --=20 Jacek Rosik <jr...@us...> -- ------------------------ konta e-mail 100 MB od 3 zl m-c serwery www 60 MB od 7 zl m-c AlphaNet, www.alpha.pl=20 ------------------------ |
From: Jacek R. <pa...@fa...> - 2003-10-06 23:31:16
|
W liście z pon, 06-10-2003, godz. 15:28, Keith Whitwell pisze: > > I know that vertex are accumulated and then are sent to the hardware. > > Is it possible (hard?) to do something like this in order to render > > into more than buffer. > > > > radeonSetBuffer(GL_FRONT_LEFT) > > radeonSendDataToHardware(); > > radeonSetBuffer(GL_FRONT_RIGHT) > > radeonSendDataToHardware(); > > Yes, that sort of thing is possible. > > If you look at the older 3d drivers, eg. r128, you'll see that we had to use a > loop to dispatch regular vertices as we could only send a few cliprects to the > kernel at a time. You could do a similar loop over the two buffers. Do You think that it would be better to first try to understand r128 driver (which is probably simplier than radeon) or the two drivers differ too much. -- Jacek Rosik <pa...@fa...> |
From: Keith W. <ke...@tu...> - 2003-10-08 12:55:34
|
Jacek Rosik wrote: > W liście z pon, 06-10-2003, godz. 15:28, Keith Whitwell pisze: > >>>I know that vertex are accumulated and then are sent to the hardware. >>>Is it possible (hard?) to do something like this in order to render >>>into more than buffer. >>> >>>radeonSetBuffer(GL_FRONT_LEFT) >>>radeonSendDataToHardware(); >>>radeonSetBuffer(GL_FRONT_RIGHT) >>>radeonSendDataToHardware(); >> >>Yes, that sort of thing is possible. >> >>If you look at the older 3d drivers, eg. r128, you'll see that we had to use a >>loop to dispatch regular vertices as we could only send a few cliprects to the >>kernel at a time. You could do a similar loop over the two buffers. > > > Do You think that it would be better to first try to understand r128 > driver (which is probably simplier than radeon) or the two drivers > differ too much. I'm only talking about a single function in r128_ioctl.c -- r128FlushVerticesLocked() which has a loop to submit drawing commands multiple times to the kernel. Keith |
From: Alan H. <al...@fa...> - 2003-09-30 21:24:48
|
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=C5=9Bcie z wto, 30-09-2003, godz. 19:29, Alan Hourihane pisze:= =20 > > > > On Tue, Sep 30, 2003 at 07:21:14PM +0200, Jacek Rosik wrote: > > > > > W li=C5=9Bcie z wto, 30-09-2003, godz. 18:52, Alan Hourihane pi= sze:=20 > > > > > > In radeon_dri.c in the TransitionTo2d/3d there's some offscre= en memory > > > > > > allocation going on for info->backArea and info->depthTexArea. > > > > > >=20 > > > > > > The trouble is - I can't see anywhere where these allocations= are actually > > > > > > used. > > > > > >=20 > > > > > > Are these leftovers ?? > > > > > >=20 > > > > > > Alan. > > > > > Hi > > > > >=20 > > > > > These are used used by 3D driver back depth/stencil buffers and= texture > > > > > memory. This memory is reserved so it wont get overwritten by 2= D driver. > > > > > It is used by means of RADEONInfoRec::frontOffset, > > > > > RADEONInfoRec::backOffset etc... It can be freed if no 3D is ac= tive. > > > > =20 > > > > 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=20 > > > > info->textureOffset. > > >=20 > > > These offsets are only calculated. Only front buffer area is alloca= ted, > > > rest is left to be allocated only on demand. Memory manager is > > > initialised to maximum possible memory then area for framebuffer i= s > > > reserved. Lines necessary for other buffers is only calculated. > > >=20 > > >=20 > > > (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 > > >=20 > > > > I don't see what purpose info->backArea and info->depthTexArea ha= ve. > > >=20 > > > Believe me, recently I had quite a few chances to see contents of t= hese > > > areas and normally they are used by 2D apps (mainly XMMS ;)). So if= we > > > wont reserve them screen corruption may occur. > > =20 > > No they're not. The memory IS allocated because the FBManager is neve= r > > 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 botto= m > > 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. > >=20 > > 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. >=20 > O.k. I've got it. I can see that scanlines is calculated from the total > FbMapSize and not the remaining after static allocation. >=20 > 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=20 > 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. |
From: Michel <mi...@da...> - 2003-10-01 08:57:58
|
On Tue, 2003-09-30 at 23:23, Alan Hourihane wrote: > > 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. TIA, I tried to document how it works (yes, I'm to blame for it, not Mark :) but obviously failed to do so well enough. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer |