Why is it that Radeon cannot run good old (ancient) Doom 3 engine games?

[dungeon]

Read again this:

http://www.phoronix.com/forums/showthread.php?111401-Why-is-it-that-Radeon-cannot-run-good-old-(ancient)-Doom-3-engine-games&p=460663#post460663

Your game again missed:

X..GL_ARB_vertex_buffer_object not found
X..GL_ARB_shader_objects not found

You have both those of course, as glxinfo says... do you tried under env MESA_EXTENSION_MAX_YEAR=2003 ./quake4

And again, did you remove gcc libraries?

[pingufunkybeat]

The Wither 2 runs fine, Quake 4 doesn't. It's absurd. I remember a few months ago these games couldn't even start. Now they do, but textures are completely missing. What's so hard in making the driver compatible with these games while it runs modern games fine?

I hope you manage to fix your broken Mesa installation.

I have finished Doom3, Resurrection of Evil, Prey and Quake 4 years ago, all using the radeon OSS driver. So it works fine.

[duby229]

You can't put all of the blame for breakage in the OSS graphics stack on individuals tho... I mean yeah, sure it's probably fixable, but elitists always assume individuals have way too much knowledge.

Lets face the facts here... The current stack is way too fractured and complicated. Just considering the kernel by itself there is KMS and DRM. In user space there is X, Mesa, and LLVM... That is at least 5 different parts of the the stack written by different people at different times in different styles and for different reasons. There aren't that many individuals that have the ability to deal with that.

EDIT: Package management doesn't always work perfectly.

[pingufunkybeat]

You can't put all of the blame for breakage in the OSS graphics stack on individuals tho... I mean yeah, sure it's probably fixable, but elitists always assume individuals have way too much knowledge.

Lets face the facts here... The current stack is way too fractured and complicated. Just considering the kernel by itself there is KMS and DRM. In user space there is X, Mesa, and LLVM... That is at least 5 different parts of the the stack written by different people at different times in different styles and for different reasons. There aren't that many individuals that have the ability to deal with that.

EDIT: Package management doesn't always work perfectly.

I agree in principle, but you can't say that the drivers don't work if they worked years ago.

This should work out of the box with any modern distro. The only tricky part is s3tc and 32-bit libs, but this is not the problem of the drivers, but patents (s3tc) and 32-bit libs (linux and closed source in general).

[nanonyme]

I agree in principle, but you can't say that the drivers don't work if they worked years ago.

This should work out of the box with any modern distro. The only tricky part is s3tc and 32-bit libs, but this is not the problem of the drivers, but patents (s3tc) and 32-bit libs (linux and closed source in general).

Wasn't there some patent-free successor of s3tc, btw?

[pingufunkybeat]

Wasn't there some patent-free successor of s3tc, btw?

You mean s2tc? Not all distros package it (I think Debian does by default).

[smitty3268]

Wasn't there some patent-free successor of s3tc, btw?

There is s2tc, which is a patent-free compatible implementation that can work with s3tc content, only with lower quality. Some distros use it.

The "successor" was a new format (bptc?), which only has hardware decode support in newer hardware, and which applications will need to switch over to using instead of s3tc (since it's not backwards compatible).

Since only new hardware has it, even current games can't really switch over to it yet. Maybe in 5 years we'll start seeing it get used. I think s3tc patents might run out by then anyway, but at least the new format won't reintroduce the problem, and should have higher quality.

[eydee]

Solved. Actually no one was right and my mesa install was of course not broken at all.

The issue is the very same Arch has with the Steam Runtime. Radeon conflicts with certain outdated libraries. Removing files from the game directory did it.

Renamed "libgcc_s.so.1" to "libgcc_s.so.1.bak".
Renamed "libstdc++.so.6" to "libstdc++.so.6.bak".

Game runs fine now, textures are all visible. As I thought and hoped for, performance is great, not as sluggish as with Catalyst.

(The idea came from playing around with Prey, which had sound issues. There I had to "replace" the bundled SDL library.)

[Nille]

Marek suggest this to you in Post #6 and dungeon in post #10 with file names.

I think old gcc libraries in the game directory are the culprit.

That happens when you have old gcc libs in game dir Did you tried to remove them from there? libstdc++.so.6 and libgcc_s.so.1