Bug 469871
Summary: | Virtual size exhausts VRAM | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Owen Taylor <otaylor> |
Component: | xorg-x11-server | Assignee: | Dave Airlie <airlied> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 10 | CC: | mcepl, sandmann, xgl-maint |
Target Milestone: | --- | Keywords: | Triaged |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-12-14 18:52:47 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 465130 |
Description
Owen Taylor
2008-11-04 15:48:52 UTC
... 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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping 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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping 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. |