- ATI rv350
- 64meg of vram
- LVDS 1400x1050 no external monitor attached
(II) RADEON(0): Allocating from a screen of 65536 kb
(II) RADEON(0): Will use 32 kb for hardware cursor 0 at offset 0x011e0000
(II) RADEON(0): Will use 32 kb for hardware cursor 1 at offset 0x011e4000
(II) RADEON(0): Will use 18304 kb for front buffer at offset 0x00000000
(II) RADEON(0): Will use 18304 kb for back buffer at offset 0x011e8000
(II) RADEON(0): Will use 18304 kb for depth buffer at offset 0x023c8000
(II) RADEON(0): Will use 5248 kb for textures at offset 0x035a8000
(II) RADEON(0): Will use 5344 kb for X Server offscreen at offset 0x03ac8000
Having only 5344 offscreen caused completely unusable performance - for example
... For example running top in gnome-terminal fullscreen consumed 90% cpu.
All the time was spent migrating pixmaps out of vram ... if you think about
it, with only 5Meg offscreen, the "back buffer" pixmap that GTK+ creates
to draw in is going to be about that size if it needs to do a full window
redraw, so there won't be any memory to allocate mask pixmaps, etc.
I couldn't find an actual virtal size in Xorg.log, but 18304M works out
to 3328x1408, among other possibililities.
Owen, I think that /var/log/Xorg.0.log attached to this bug shouldn't hurt ;-).
I'm going to go out on a limb and say I've provided the information that
is needed here. Happy to provide more on request.
OK, I will let Dave fight this.
This seems like the sort of thing that would be caused by the patch to set a bigger default virtual size:
+ /* Make room for an external monitor if we have enough video ram */
+ if (scrn->VideoRam >= 65536)
+ width += 1920;
+ else if (scrn->VideoRam >= 32768)
+ width += 1280;
+ else if (scrn->VideoRam >= 16384)
+ width += 1024;
And the 18.4 M is very likely the result of a new virtual size of
(2560 + 1920) x 1050
So it seems like the previous width would have been 2560. This *would* have been the case earlier, but we have a patch in the ati driver to report more sane limits (the radeon-6.9.0-remove-limit-heuristics.patch).
You can get the virtual size from the first line of xrandr --verbose.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.
More information and reason for this action is here:
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '10'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 10's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 10 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
This should be resolved in F12 and later, since we're using KMS and DRI2 on that card so we should be allocating buffers dynamically.
Okay, maybe not resolved, but at least differently broken.