| Priority | medium |
|---|---|
| Bug ID | 66632 |
| Assignee | dri-devel@lists.freedesktop.org |
| Summary | Very low FPS when video memory is full (GART & ram <-> vram swapping) |
| Severity | major |
| Classification | Unclassified |
| OS | Linux (All) |
| Reporter | sonichedgehog_hyperblast00@yahoo.com |
| Hardware | All |
| Status | NEW |
| Version | 7.0 |
| Component | Drivers/DRI/Radeon |
| Product | Mesa |
Although I heard this issue was discussed, I couldn't find other bug reports and wanted to post my observations on the matter. At this point it's the only reason why I'm sticking with fglrx and can't switch to Radeon, and so far couldn't find a workaround either. Although Radeon and fglrx seem to run games as fast when no bugs occur, Radeon has a major problem. If video memory is filled and textures have to be stored on system memory, FPS drops unusably low. This can be noticed when a program uses high quality content such as a lot of high resolution textures, enough to fill up the video memory. The best and only test case I know of (also the reason this problem affects me) is the project Xonotic. When ran from the GIT repository, it has a lot of high-res textures in original format (some as large as 2048px). Even when texture compression is enabled, they quickly fill up my 1GB of video ram. Therefore, when looking in certain areas of a map, FPS decreases enormously (down to 3 FPS). I ran several tests in the past and tried further debugging this today on IRC. As other users pointed out, the constant swapping of items between the RAM and VRAM is the most likely cause of the problem. A better GART formula is apparently needed in order to swap only when necessary and not all the time. Someone posted a log based on their tests: http://bpaste.net/raw/lhJKFAYFyl0DNOMr9hwc/ At least one more user could replicate the exact behavior I'm getting, and confirmed Xonotic is unplayable when full-res textures are used and a map loads a lot of them. I was also linked a patch, which was said to fix the issue although it wasn't accepted yet. In case it's of any relevance, http://people.freedesktop.org/~glisse/0001-drm-radeon-keep-original-user-requested-placement-ar.patch I heard a correct formula on when to trigger VRAM <-> RAM swapping is harder to find, so I understand why this bug exists. Since it's a major issue and keeps some engines from working when they could, it would be appreciated if even a simple solution could be added in the meantime. Such as disabling swapping altogether (what was placed in vram stays in vram and what's in gart stays in gart) or only triggering swapping after a longer amount of time rather than each frame (eg: 30 or 60 seconds).
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
