Bug 21649

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