Mupen64 1.2 Makefile

[julroy]

I think you should use -march=native in Mupen64's pre.mk and RiceVideoLinux Makefile. I have tried for me, and it's working perfectly, it is not much but it can choose better what the proc needs.

# set special flags per-system
ifeq ($(CPU), X86)
  ifeq ($(ARCH), 64BITS)
    CFLAGS += -march=native
  else

and -march=native stands for :

This selects the CPU to tune for at compilation time by determining the processor type of the compiling machine. Using -mtune=native will produce code optimized for the local machine under the constraints of the selected instruction set. Using -march=native will enable all instruction subsets supported by the local machine (hence the result might not run on different machines).

:drool:

 

[TD-Linux]

Why do you have to check for 64 bits? Shouldn't that work 32 bits too?

That should be off by default, because the makefiles are designed for creating releases it seems.

Which reminds me, why isn't there a 'normal' compiling makefile? Am I missing it? I'm using SVN.

 

[Richard42]

Which reminds me, why isn't there a 'normal' compiling makefile? Am I missing it? I'm using SVN.

What do you mean by 'normal' makefile? All makefiles are custom-designed for the project.. Perhaps you are referring to the autotools (automake/autoconf)? Mupen64 was never setup with this build system, and I'm not a big fan of it so I don't see any need to spend time on it. The makefiles that we have now are actually quite a bit better than the ones used in v0.5.

 

[Richard42]

I think you should use -march=native in Mupen64's pre.mk and RiceVideoLinux Makefile. I have tried for me, and it's working perfectly, it is not much but it can choose better what the proc needs.

Thanks for pointing this out. I build the binary releases automatically from a particular machine, but I really need to select the architecture which is the lowest common denominator for all the CPUs, for maximum compatibility. This applies to the 32-bit build as well as the 64-bit one. Since AMD invented the 64-bit extensions, I figured the 'athlon64' CPU type would be best. I think the inclusion of 3DNow instructions can cause problems for P4 or Core 2 chips though, so I am going to do some testing and experimenting with this. Maybe I'll add a RELEASE build flag which will compile with generic CPU settings, and use march=native when this flag is not set.

 

[julroy]

For the moment I personally didn't have any problem, I've tested few games and demos, but I've not played so much for the moment. A bit more testing can only be good.

And I'm using -march=native on all my system (a big amount ^^), because I'm using Gentoo and I have defined this flag that is not so used, because it was introduced in GCC 4.1 (I think).

-> I forgot to mention, only above ~GCC 4.0 or 4.1, the 3.x don't have for sure.

 

[Richard42]

For the moment I personally didn't have any problem, I've tested few games and demos, but I've not played so much for the moment. A bit more testing can only be good.

Do you know exactly which version of GCC you're using? Are you on the unstable branch of Gentoo? I checked last night, and both my Gentoo-amd64-stable machine and my Fedora 8 box are using GCC 4.1.2, and this compiler does not support the -march=native option.

 

[julroy]

I'm sure it's working on GCC 4.2.2, but last sync I went to GCC 4.2.3. And yes I'm using the unstable branch.

I've asked on Gentoo's IRC channel and it was introduced on GCC 4.2, I thought it was introduced earlier :/ So a bit waiting for what I proposed, GCC 4.2 isn't on any binary distribution. Maybe add later, or make a check of GCC version.

 

[TD-Linux]

What I meant by weird makefiles is that they always make a zip, which is annoying... can you add a default target (not requiring VER) that just does a normal build and plops a binary somewhere more convenient?

Also, mupen64 needs to be installable soon, if we ever want to get into any distros or repos.

 

[Richard42]

What I meant by weird makefiles is that they always make a zip, which is annoying... can you add a default target (not requiring VER) that just does a normal build and plops a binary somewhere more convenient?

Also, mupen64 needs to be installable soon, if we ever want to get into any distros or repos.

You're using the makefile in the base of the trunk; I wrote that for creating releases, which is why it generates the zips. Each project (Mupen64-amd64, RiceVideoLinux, and Glide64) has its own makefile in the module's sub-folder. Use these makefiles to build the individual projects; they only build the binaries.

Ebenblues has made a lot of progress on the gui/nogui merge, and as part of this work he is adding the functionality which will allow Mupen64 to be installed in a normal way with binary distributions.