https://bugs.freedesktop.org/show_bug.cgi?id=33172

Jan Buecken jb.faq@gmx.de changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |jb.faq@gmx.de

--- Comment #1 from Jan Buecken jb.faq@gmx.de 2011-01-15 15:21:09 PST --- 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)

https://bugs.freedesktop.org/show_bug.cgi?id=33172

--- Comment #2 from Tobias Jakobi liquid.acid@gmx.net 2011-01-19 14:35:02 PST --- 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.

https://bugs.freedesktop.org/show_bug.cgi?id=33172

--- Comment #4 from Henri Verbeet hverbeet@gmail.com 2011-01-27 07:28:26 PST --- (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.

https://bugs.freedesktop.org/show_bug.cgi?id=33172

Tobias Jakobi liquid.acid@gmx.net changed:

What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED

--- Comment #6 from Tobias Jakobi liquid.acid@gmx.net 2011-02-01 13:04:35 PST --- 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!