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).
I wonder if you could send me memory traces from such cases? Instructions: http://www.phoronix.com/scan.php?page=news_item&px=MTU2Nzk
First of all, I should note that this has gotten a LOT better since Mesa 9.2. Whereas in Mesa 8 Xonotic would barely run on maps with large textures, I'm now able to run it almost perfectly with maximum details! It still lags in some areas however, and I need to use texture compression to reduce memory use as much as possible. As for that link: First of all, thank you for looking into the vram issues... it's comforting to see someone being to the point about it and willing to tackle the problem. I'll gladly help if I can, and if the fixes you make will go into Mesa and the Radeon driver. However, I can't do anything that requires getting unstable / unofficial system packages, or hacking into the system and drivers... as I can't risk breaking my system and usually fear going too far. I use openSUSE (13.1 currently) and only the stable system packages provided by it in the official repositories. Mesa 9.2.3, Xorg-X11 7.6, xf86-video-ati 7.2. Will the test work with these?
No, I'm afraid you need git + patches to test. You can build a local mesa and test it without installing, that way your system is not at risk. ./configure --etc etc && make export LD_LIBRARY_PATH=lib export LIBGL_DRIVERS_PATH=lib/gallium # now everything in this shell will use the new driver glxinfo # check the output xonotic --etc-etc
Oh... so I can build Mesa in any local folder I want, then launch the game's binary with an URL specifying where to load it from? Without having to boot with special parameters or making permanent system changes? In that case I might be able to test.
Yes, no boot params or system changes needed.
Alright. After a lot of work, I managed to get Mesa to compile from GIT, together with the libdrm from latest GIT. However, I'm barely able to test anything with it, as any game I open crashes. I tried with 3 projects, and they all crash the moment any 3D is to be rendered. There was however a very simple game that would run, although it uses very small textures so there's barely anything to test. If you know a simple application that can use a lot of vram and simulate the transfer, please point it out.
Let's fix your crashes first. Can you get a backtrace from one? You might want to come to #dri-devel on Freenode to debug this (I'm cand there).
I spoke with Lauri on IRC and we got it working. If anyone else has an use for the results, this is the compressed log file, containing memory usage statistics useful to debug the lag: http://www.sendspace.com/file/pjur0t Taken with Xonotic, 1680 x 1050 full screen. All effects set to maximum, compression disabled, and using the GIT version of Xonotic (therefore original uncompressed high-res textures, mostly tga). I played on the map Solarium with 5 bots at maximum skill level, for about 4 minutes.
(In reply to comment #1) > I wonder if you could send me memory traces from such cases? > > Instructions: http://www.phoronix.com/scan.php?page=news_item&px=MTU2Nzk Hello Lauri, I read all about this and your thesis on phoronix last night ;-) But I couldn't get the patch set (compare) from your stats6, tree. I do not need a complete next Mesa git tree. How can I check out only the 12 patches for my Mesa git tree? Do I only have to checkout stats6 in my tree? I'll do some logs for you on my RV730 AGP (1 GB) with Celestia, Blender, FreeCAD,...
(In reply to comment #9) What I did was to simply checkout the stats6 branch and compile it. GIT clone the repository, then create a local branch and pull stats6 into it. After that compile, enable the debug flag, and run the application through the new version of Mesa.
When you have my mesa repo cloned, you can output a complete patch with "git diff master..stats6", which you can then apply in other trees. But be aware that it might not apply to old versions, being against git master.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/446.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.