Bug 33172 - [r600g] ingame rendering broken (black screen) in ut2003
Summary: [r600g] ingame rendering broken (black screen) in ut2003
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/r600 (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-01-15 15:01 UTC by Tobias Jakobi
Modified: 2011-02-01 13:04 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Jakobi 2011-01-15 15:01:10 UTC
Hello!

Found some time to retest this popular game with fresh git pulls and it looks like that it completly broke. The menu renders fine, but upon entering the actual game you just get a black screen.

The kernel log then produces these nice messages:
[drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
...

System:
ATI Technologies Inc Radeon HD 4770 [RV740]

drm-radeon-testing kernel
libdrm, mesa and xf86-video-ati are all git master
xorg-server-1.9.3.901

Greets,
Tobias
Comment 1 Jan Buecken 2011-01-15 15:21:09 UTC
I have the same problem with ut2004 (r600g-64bit), and my kernel log is filled with
[drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
also.
(ut2003 simply crashes ingame with r600g-32bit , its all ok with r600c)

System:
Radeon HD Mobility 2600 (rv630)
amd64 architecture

d-r-t-git and 2.6.37 tested
libdrm, mesa, xf86-video-ati are all git master
xorg-server-1.9.3.901
(gentoo)
Comment 2 Tobias Jakobi 2011-01-19 14:35:02 UTC
We (Jan and me) did some tests today and found out that the issue is probably related to the use of VBOs (or more specifically: not using them).

In ut2004 there is a option called 'UseVBO' for the OpenGL renderer. I guess enabling this one lets the engine use the 'ARB_vertex_buffer_object' extension. It turned out that in my ut2004 config it was enabled, but Jan had it disabled. So after enabling it for Jan the rendering suddenly worked. And when I disabled UseVBO on my system it suddenly failed and produced the black screen, plus the relocation parser errors in the kernel log.

I can only guess here, but maybe the problem is with Gallium's immediate mode implementation -- if that's how the engine submits vertices when ARB_vbo is not used.

The next thing we found out is even more interesting: In ut2003 there is no such option, so he had to stick to the 'immediate mode' rendering path. All the tests were done on Jan's system. We noticed that is was possible to get ingame when being logged in as root. This only worked for a short time, maybe like 10 seconds, before the game segfaulted. After it segfaulted, it wasn't possible any more to get ingame. The game just instantly segfaulted. Restarting X didn't help, only a full reboot did the trick.

Another thing that worked: Reboot, start ut03 as root, watch some game scenary for like 3 seconds, quickly exit the game, start ut03 as root, repear procedure...

The maximum amount of time we managed to get into game was three. After that it didn't work any more.

It was like we hit some memory leak, maybe in VRAM?

Then we switched over to ut2004 and disabled UseVBO there. We got the black screen (with the kernel messages) when we got ingame and then we waited a bit. But just like ut03 the game segfaulted after some seconds and we even managed it at one time to trigger the kernel OOM killer.
Comment 3 Tobias Jakobi 2011-01-26 11:46:00 UTC
New tests on my system with ut2004. UseVBO is disabled, so I only get a black screen ingame.

I can still play though (by ear so to speak) and while doing this I watched memory consumption of the process:
Monitoring ut2004-bin with htop showed that during peak times the process has more than 50GiB virtual mem (VIRT) allocated. So there's clearly a mem leak here.

Could valgrind help to detect such a leak?
Comment 4 Henri Verbeet 2011-01-27 07:28:26 UTC
(In reply to comment #3)
> Monitoring ut2004-bin with htop showed that during peak times the process has
> more than 50GiB virtual mem (VIRT) allocated. So there's clearly a mem leak
> here.
> 
That's 64-bit ut2004, right?

> Could valgrind help to detect such a leak?
Probably, but it's certainly not going to make it any faster.
Comment 5 Tobias Jakobi 2011-01-27 07:49:02 UTC
(In reply to comment #4)
> That's 64-bit ut2004, right?
Yes.

> Probably, but it's certainly not going to make it any faster.
That's a given. And it didn't work anyway, since it looks like that gentoo strips the library loader. valgrind apparantly doesn't like that and fails on startup.

Have to take another look when I find some time.
Comment 6 Tobias Jakobi 2011-02-01 13:04:35 UTC
Looks like the problem got fixed by the recent changes to the vertex buffer upload code. Both ut2003 and ut2004 now work flawlessly.

Thanks Marek!


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.