[Bug 21649] EXA cannot allocate memory for OpenGL

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Sun May 10 07:08:38 PDT 2009


http://bugs.freedesktop.org/show_bug.cgi?id=21649


Michel Dänzer <michel at daenzer.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX




--- Comment #2 from Michel Dänzer <michel at daenzer.net>  2009-05-10 07:08:37 PST ---
> 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.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the xorg-driver-ati mailing list