From: bugzilla-daemon@freedesktop.org
To: dri-devel@lists.freedesktop.org
Subject: [Bug 66632] New: Very low FPS when video memory is full (GART & ram <-> vram swapping)
Date: Fri, 05 Jul 2013 23:31:22 +0000 [thread overview]
Message-ID: <bug-66632-502@http.bugs.freedesktop.org/> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 2918 bytes --]
https://bugs.freedesktop.org/show_bug.cgi?id=66632
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.
[-- Attachment #1.2: Type: text/html, Size: 4423 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next reply other threads:[~2013-07-05 23:31 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-05 23:31 bugzilla-daemon [this message]
2014-01-12 11:31 ` [Bug 66632] Very low FPS when video memory is full (GART & ram <-> vram swapping) bugzilla-daemon
2014-01-12 12:00 ` bugzilla-daemon
2014-01-12 14:11 ` bugzilla-daemon
2014-01-12 14:17 ` bugzilla-daemon
2014-01-12 19:06 ` bugzilla-daemon
2014-01-12 21:07 ` bugzilla-daemon
2014-01-13 8:38 ` bugzilla-daemon
2014-01-13 12:52 ` bugzilla-daemon
2014-01-13 18:47 ` bugzilla-daemon
2014-01-13 21:23 ` bugzilla-daemon
2014-01-14 9:48 ` bugzilla-daemon
2014-01-26 12:24 ` bugzilla-daemon
2019-09-18 19:04 ` bugzilla-daemon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-66632-502@http.bugs.freedesktop.org/ \
--to=bugzilla-daemon@freedesktop.org \
--cc=dri-devel@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.