I was trying to run an OpenGL application on a i440BX + Radeon 9200 system with Xorg 1.6, and it turned out that it is almost fast enough but not quite. Looking at the performance options available I tried to switch between 16bit and 32bit textures in the application itself (32bit was faster but it's somewhat expected since I did not switch the X server to 16bit) I also tried page flipping but if anything it made things worse. The X log suggests to reduce Virtual, and indeed I could save a few megs there .. but the memory is divided as follows: front, back, depth buffer ~ 3*8 = 24M GL textures ~ 52M EXA offscreen ~ 52M which suggests I could save perhaps 12M on the screen buffers but I have 52M of completely unused memory. There is an option that allows changing the percentage of VRAM allocated to the GL textures, I set it to 90 and the X server would merrily inform me that the option was ignored. Switching to XAA resolves the problem. I get ~ 100M for GL textures which is enough to mitigate FPS drops. With XAA the X server also informs that it uses 8M of GART memory although I have set up 128M in the BIOS. Changing to 64M there has no effect. With EXA I do not get that information at all.
X logs in the default configuration are here: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/370205
> Looking at the performance options available I tried to switch between 16bit > and 32bit textures in the application itself (32bit was faster but it's > somewhat expected since I did not switch the X server to 16bit) Actually, I'd expect 16 bit textures to always be faster... However, the screen depth may indeed override the application hint depending on the value of the driconf option texture_depth. > front, back, depth buffer ~ 3*8 = 24M > > GL textures ~ 52M > EXA offscreen ~ 52M > > which suggests I could save perhaps 12M on the screen buffers but I have 52M > of completely unused memory. If by 'completely unused memory' you mean the EXA offscreen memory, EXA needs it for 2D acceleration. Unfortunately, we can't really do better than this static partitioning of video RAM without a graphics memory manager, which will only come with kernel modesetting. > There is an option that allows changing the percentage of VRAM allocated to > the GL textures, I set it to 90 and the X server would merrily inform me that > the option was ignored. I assume you mean Option "FBTexPercent" "90" Please attach a log file that shows this being ignored. > With XAA the X server also informs that it uses 8M of GART memory although I > have set up 128M in the BIOS. Changing to 64M there has no effect. Again, without a graphics memory manager the X driver can only allocate GART memory statically, and unused GART memory is wasted system memory, which is why the driver doesn't allocate the full GART aperture size by default. Current versions of the driver use 32 by default though. So maybe you're using an old driver, which may also explain why Option "FBTexPercent" isn't working. Note that the Mesa r200 driver doesn't use GART memory for textures unless there is no video RAM available for textures at all, which requires Option "FBTexPercent" "0" All in all I think any real issues here are either already fixed or will be fixed more or less automagically with a graphics memory manager and can't be without one.
(In reply to comment #2) > > Looking at the performance options available I tried to switch between 16bit > > and 32bit textures in the application itself (32bit was faster but it's > > somewhat expected since I did not switch the X server to 16bit) > > Actually, I'd expect 16 bit textures to always be faster... However, the screen > depth may indeed override the application hint depending on the value of the > driconf option texture_depth. I would expect the texture format matching the framebuffer format to be the fastest which is also what I have seen. > > > front, back, depth buffer ~ 3*8 = 24M > > > > GL textures ~ 52M > > EXA offscreen ~ 52M > > > > which suggests I could save perhaps 12M on the screen buffers but I have 52M > > of completely unused memory. > > If by 'completely unused memory' you mean the EXA offscreen memory, EXA needs > it for 2D acceleration. Unfortunately, we can't really do better than this > static partitioning of video RAM without a graphics memory manager, which will > only come with kernel modesetting. I guess I don't need EXA acceleration for OpenGL. > > > With XAA the X server also informs that it uses 8M of GART memory although I > > have set up 128M in the BIOS. Changing to 64M there has no effect. > > Again, without a graphics memory manager the X driver can only allocate GART > memory statically, and unused GART memory is wasted system memory, which is why > the driver doesn't allocate the full GART aperture size by default. Current > versions of the driver use 32 by default though. So maybe you're using an old > driver, which may also explain why Option "FBTexPercent" isn't working. > > Note that the Mesa r200 driver doesn't use GART memory for textures unless > there is no video RAM available for textures at all, which requires > So the allocated GART texture memory is also unused. I am not sure how much memory X allcates, though.
Created attachment 25917 [details] XAA log
Created attachment 25918 [details] EXA log
Created attachment 25919 [details] xorg.conf
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.