Kubuntu FMV performance, glibc versions, compiling issues

[Queen Fiona]

I've recently transitioned from Windows to Kubuntu, and Dolphin was one of the first packages I installed, from the master branch. I only recently got to test it out, and performance seemed just about perfect (as expected)...until I tried to play an FMV. (The game in question is R: Racing Evolution, but as seen below it doesn't seem to be unique to this title.)

Now, it took a while, but I did eventually figure out that the problem wasn't me - it was glibc. That was clearly stated in the November 2016 progress report. Embarassingly, it didn't show up easily and I was incredibly confused as I tried stable, master, and Ishiiruka with various settings.

That said, it appears Ubuntu is still using a glibc version that suffers from this bug; it uses 2.24 while the latest is 2.25. I couldn't find even an unofficial package to upgrade, and I really didn't want to mess around and end up ruining my system due to replacing a vital system library, so I tried to look for ways of solving the issue. An earlier bug report noted that using the compiler options "-O3 -march=native" solved the issue. I set up a build environment for Dolphin's master branch, but editing CMakeLists.txt to include those options, both using methods listed here (I only used -O3 and -march=native though) and others, but nothing I compiled worked.

It seems like this problem should be more well-known and widespread than it is, so I'm not entirely convinced that it isn't just my configuration or system setup. It might also be an unrecognized Dolphin bug. But I'm fairly sure I'm just compiling this thing wrong, as I know nothing about CMake syntax, let alone how to parse the complex file Dolphin uses and how my arguments might be ignored or overwritten. Anyone have any ideas?

[Shonumi]

I haven't built the most recent builds from master, but nothing should be completely broken in CMake as far as I know. What do those CMake errors look like on your system? Do you have a log we can see? It's usually pretty easy to tell what the problem is, since CMake will generally complain about specific issues and doesn't often give vague details (in my experience at least).

[Helios]

We have been making a bunch of CMake changes the past couple months. We might have broken something.

[Queen Fiona]

Sorry, I should have been more clear. After editing the CMake files, Dolphin compiles fine, but fails to display any changes in FMV performance as noted in the third link in my post. It's not an issue of not being able to compile, just not knowing if the -O3 and/or -march=native flags are properly enabled, or how I would apply them to a build if they aren't.

There are various errors, but they seemed like simple compiler warnings. I can try to provide them if needed, but I think it's human error on my part and not anything to do with the build process, although the errors did seem different depending on which flags I tried to enable. I think it also sometimes compiled slower (as you would expect for -O3), but that might just be an unclean build environment or observer effect.

[Shonumi]

Well, if it compiles fine, you're probably using the compiler flags just fine. Using add_definitions() isn't anything really fancy; it's a pretty straight-forward one-liner addition to CMakeLists.txt, so I doubt human error or anything like that.

I suppose multiple older versions of glibc handle things differently; not sure degasus tested his fix on 2.24 specifically or anything. At any rate, you can try older revisions instead of the latest code from master. Just do:

Code:

git checkout somelonghashoflettersandnumbers

You can browse Dolphin's github Commit log to get the hashes, or browse the download page. Pick a date that looks good and test it out, and see if it works better. The culprit is glibc, but only because it leaves some unoptimized code floating around when compiling stuff in VideoCommon. So it's worth a shot to go back far enough where VideoCommon didn't cause glibc to freak out.

[Helios]

I don't think we actually bothered committing any fixes to work around the glibc issue, FWIW. We just shrugged and waited for glibc to fix it and then distros to catch up.

[Queen Fiona]

As far as I know, Zesty Zapus uses the same revision of glibc that Xenial does. So even upgrading isn't a guarantee. I'm really annoyed with my Ubuntu experience when it comes to dependencies; tons of libraries have substantial bugs and dependency issues. It took me around 8 hours in Wine to get Warframe to kind of work because of Wine and Winetricks revision issues, and perhaps more relevant, I can't actually run another X session of any variety without crashing my main one, nor can I run, say, RetroArch in KMS mode regardless of whether I use AMD's open-source or proprietary drivers.

Open source software (with the notable exception of excellent projects like Dolphin, or other emulation packages) has a weird tendency to ignore problems if there's some way to get it working. At the very least, I understand Ubuntu's looking for stability before merging in updates, but it does just seem like it's being delayed despite existing bugs, not because of upstream ones.

Anyway, back to the matter at hand. Mostly I was wondering if adding -march=native after other march or instruction set tags caused the native command to be ignored (I put it at the end of the file). Going back into the repos won't work because it's broken in 5.0 stable (with a tiny patch for pie issues under 16.10) as well as master, so I'd have to go all the way back into the 4.0 revisions.

Another option would be if there were a way to not compile with AVX at all (ie, as though I were using Nehalem), or otherwise disable it in some matter. Sure, I'd take a performance hit, but better for the JIT to work all the time but a bit slower rather than working fine sometimes and becoming utterly unplayable at others. I don't even know if you support pre-Sandy Bridge processors at all, though.

[Helios]

We support any x86_64 CPU.

I dunno. I use Arch Linux now a days. I'd need to spin up a KVM VM with Ubuntu when I get home to see if the glibc bug is still there in the latest release.

[Shonumi]

(03-28-2017, 02:11 AM)Queen Fiona Wrote: so I'd have to go all the way back into the 4.0 revisions.

My bad, I was under the impression that glibc started acting up after 5.0, not before. Guess I didn't read the other forum thread carefully enough, otherwise I wouldn't have suggested trying previous revisions.

Fwiw, even though anything older than 5.0 is not supported, nothing is stopping you from using old 4.0-xxxx builds. If those work for you, then they work for you. We just can't help you with any bugs or errors. I'm not endorsing the idea, just saying that I've seen lots of people stick with older versions until a problem with their OS or hardware changes.

[Queen Fiona]

I suppose I could try, but how far back would it take? AVX has been around for six years by now - I should know, that's when I first built my desktop. There's no telling if it would actually help, let alone if another related bug would crop up in something more important overall than video decoding.

I tried a couple of Konami's WiiWare games and they seemed to perform fine, for the record. The progress report said there might be other effects, but I haven't seen any...although I haven't been testing any 3D games yet.

Tell me if you plan to test things out. I kind of think I should've used Arch given that their wiki is a first reference point for me...I actually switched off Fedora due to poor multimedia options and ended up with a bunch of new problems. I can't imagine Arch is any less user-friendly than Kubuntu at this point, given that I've gotten used to the terminal after a few years of OpenWrt.