PCSX2 Documentation/Chroot and 64-bit Linux

From PCSX2 Wiki
Revision as of 17:02, 19 July 2015 by Krysto (talk | contribs) (→‎Arch Linux)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

This is only a rough draft.

More and more linux users have 64 bit distributions. The purpose of this wiki page is to explain the current situation and possible solutions. Status updates on the following distributions are welcome (as are others we may have overlooked): Debian / Ubuntu / Fedora / Gentoo / ArchLinux / Mandriva / Opensuse / Slackware.

Introduction

Pcsx2 does not support running as a 64 bit application for various reasons.

  • The code is architecture dependent (for performance reasons).
  • It would need a complete rewrite of the emulator core.
  • No gain in performance, actually it could be slower.
  • Lack of programmers both willing and able to write and maintain the 64-bit code and keep it up to date with the 32-bit code. (Which has been largely rewritten since the old 64 bit code was removed.)

While it is possible to run a 32 bit program on a 64 bit operating system, you have to have 32 bit versions of all the libraries it uses as well. With the libraries Pcsx2 uses, this can be impractical, which is why we generally recommend a 32 bit chroot.

TO DO: Talk about what a 32 bit chroot is. (Well, it's really a full 32 bit copy of Linux sitting in a folder on your hard drive, which Linux can cleverly start up and run programs from, but detail might be nice to have here...)

Pcsx2 is not 64-bit compatible by design

Most software only needs to be recompiled to support a new architecture. Portability was one goal of the C language over assembly. However, some types of software do not follow this rule. For example,virtual machines, dynamic recompilers, JIT compilers, and compilers in general. These programs directly generate assembly code for the type of processor targeted. There are a few types of programs that do this:

  • In some cases, the assembly code being used is static. It will be generated once, and then will be executed at a later time. The major example is gcc. The code that generates x86 instructions is completely different from, say, the code targeting the powerpc. Each architecture has a special backend.
  • Then there are programs that dynamically generate instructions for the processor as they are running. You generate the instructions during the execution of the program, and the program executes them. In those cases, the generator could be portable, but not the instruction generated by it. Some examples are the Java virtual machine, Javascript & the flash virtual machine (Which should be well known to people trying to play flash in 64 bit browsers.), Perl's virtual machine, Python's virtual machine, etc... And, of course, Pcsx2. All these programs must be rewritten for each new architecture supported: x86, amd64, powerpc...

So, why would we go through all this hassle in the first place? The main reason is speed. A virtual machine or a JIT compiler is globally 10 to 100 times faster than a basic interpreter of the language. Would it be faster still to code everything in assembly? Well, maybe. But there are a few reasons why that wouldn't be a good idea:

  • Sometimes it is not possible (or very difficult) to port the original code.
  • You can do optimization based on run-time values which can not be done easily otherwise.
  • Assembly is not exactly readable. Having code that is easy to read and can be debugged easily can be worth a slight speed decrease.
  • Additionally, sometimes the compiler is already doing a good job on the C code, and there is just no reason to optimize.

In some cases, optimization isn't even desirable. It may be that optimization over-complicates things and allows bugs to creep in for something that that may be rarely executed and is not time dependent. There is at least one piece of code in Pcsx2 that has a note by it saying not to optimize it.

  • Another reason is portability. While the code for the program itself may not be portable, it would in theory be possible to write multiple generators for different processors. We may not be doing that currently, but we don't have to rule that out for the future. That is the beauty of virtual machines, and why you can run Java programs pretty much anywhere, for example.

For more information, you may want to look up virtual machines in google or wikipedia. Other topics of interest might be Infocom, and their "Z-Machine" virtual machine, code optimization, portability, well, a lot of things, really. Talking about it too much would be beyond the scope of this document, though, however interesting...

Chroot environment

The recommended way except on Ubuntu/Debian. Chroot was superseeded by "multiarch".

Standard library

The least problematic way to install pcsx2 on a 64 bit system is to create a 32 bits chroot. Each distribution has a specific way, largely because what you really are doing is installing a small install of that distribution in a folder. For now, this section is mainly stubbed out. Usually googling "32 bit chroot" with the name of your distribution will get you decent results.

A few links that could help:

TODO: add other distributions : Archlinux / Mandriva / Opensuse / Slackware

Proprietary Driver

NVIDIA

  • Do not know ^^ (arcum42 -- I've got an nvidia card, so I'll have to check some time...)

ATI/AMD (Note: library paths depend on distributions)

  1. Use the 32bits glxinfo to check that direct rendering is enabled
  2. You need to overwrite the libGL.so.* libraries provided by mesa with the 32bits version in fglrx.
  3. You must add the 32bits fglrx_dri.so

IA32 libs / Multi-arch

Some distributions give you the ability to install 32 bit libraries in an amd64 architecture. Note: it is still necessary to install the 64 bit development packages, and some distributions miss some of the required libraries:

Debian / Ubuntu

ia32-libs-dev and ia32-libs-gtk are DEPRECATED, don't use them.

Multi-arch which allow to install any architecture library in any architecture system (ease also cross-compilation). You need to add :i386 suffix when you install a package. For example <source lang="bash"> apt-get install pcsx2:i386 </source>

  • Ubuntu: Upgrade to 12.04.
  • Debian: expected in Wheezy and later.

Arch Linux

Seem to be working for some users.

Some of the required packages to build PCSX2 are available only in AUR unsupported. So, the use of an AUR helper (ex: yaourt) is highly advised! Hopefully all 32 bits package can be found. <source lang="bash">

  1. update /etc/pacman.conf

[Multilib] Include = /etc/pacman.d/mirrorlist

  1. Refresh package

pacman -Sy </source>

Fedora 14: Status, compile and run OK (fedora 14).

search for packages ending with ".i686" <source lang="bash"> yum install cmake bzip2.i686 bzip2-devel.i686 glew.i686 glew-devel.i686 mesa-libGL.i686 mesa-libGL-devel.i686 mesa-libGLU.i686 mesa-libGLU-devel.i686 mesa-libGLw.i686 mesa-libGLw-devel.i686 mesa-libOSMesa.i686 mesa-libOSMesa-devel.i686 alsa-lib.i686 alsa-lib-devel.i686 Cg Cg.i686 libXxf86vm.i686 libXxf86vm-devel.i686 xorg-x11-proto-devel libX11.i686 libX11-devel.i686 xorg-x11-xtrans-devel libCg.i686 SDL.i686 SDL-devel.i686 sparsehash-devel freetype.i686 freetype-devel.i686 gtk2.i686 gtk2-devel.i686 zlib.i686 zlib-devel.i686 libjpeg-devel libjpeg libjpeg-static wxGTK-devel.i686 libCg.i686 portaudio.i686 portaudio-devel.i686 glib2-devel.i686 gdk-pixbuf2-devel.i686 gdk-pixbuf gdk-pixbuf-devel gdk-pixbuf.i686 gdk-pixbuf-devel.i686 atk-devel.i686 pango-devel.i686 cairo-devel.i686 libjpeg-turbo.i686 libjpeg-turbo-devel.i686 </source>

Opensuse: Status unknown

  • search for packages ending with "-32bit"

TODO complete other distributions : Mandriva(still exists ?) / Gentoo / Slackware


Retrieved from "https://wiki.pcsx2.net/index.php?title=PCSX2_Documentation/Chroot_and_64-bit_Linux&oldid=38269"