Quoting: WienerWuerstelAre there any games besides the Feral ports that do this? I'm relly curious because I'm likely to upgrade to a RX 480 in the next couple months.

To be honest, I haven't been keeping track. I generally just click past the warning and don't see a problem. The only game I have that's actually problematic right now is Dying Light - on Mesa due to a lack of OpenGL 4.4/4.5, and on AMDGPU-Pro because it runs slow as heck to the point of almost being unplayable.

View this comment - View article - View full comments

Hopefully it supports AMDGPU-Pro upon release (or better yet, Mesa with its current OpenGL 4.3 compatibility) and doesn't complain on start-up that you're not using an Nvidia card. That behaviour has to stop.

I vaguely recall that I enjoyed the first Homefront, so I expect I'll be picking this game up as well, so long as it's not broken on AMD cards.

View this comment - View article - View full comments

Quoting: KohriasI did not think I would need xorg in 32-bit as well - that sound quite troubesome.

You don't actually run Xorg in a chroot though. It's only installed there for the libraries and headers, and the chroot is only used for compiling. It'll probably automatically pull most (all?) of the required Xorg bits in when running $ sudo apt-get build-dep wine
If you need something else for the optional libdrm or the AMDGPU DDX steps, most probably you'll get everything you need with: $ sudo apt-get build-dep xserver-xorg Not a problem at all. :)

Of course, you could instead setup your schroot config file to include the lines:
personality=linux32
preserve-environment=true
Then you could compile and run Wine there, forget all the 64-bit stuff, and not have to worry about installing :i386 packages on your amd64 host. There are plenty of options.

View this comment - View article - View full comments

Quoting: KohriasCan you share how you build 32-bit mesa with the appropriate flags?

I also build the latest DRM (from git://anongit.freedesktop.org/mesa/drm), and then the AMDGPU (from git://anongit.freedesktop.org/xorg/driver/xf86-video-amdgpu). Say those are configured with --prefix=/opt/xorg and LLVM/clang was installed to /opt/llvm, for compiling Mesa I would use:

CC="ccache gcc-6" \
    LD_LIBRARY_PATH=/opt/xorg/lib:${LD_LIBRARY_PATH} \
    PKG_CONFIG_PATH=/opt/xorg/lib/pkgconfig:/opt/xorg/share/pkgconfig:/usr/lib/x86_64-linux-gnu/pkgconfig:/usr/lib/i386-linux-gnu/pkgconfig:/usr/lib/pkgconfig \
    LLVM_CONFIG=/opt/llvm/bin/llvm-config \
    ../mesa/autogen.sh \
    --prefix=$XORG_PATH \
    --with-gallium-drivers=radeonsi,swrast \
    --with-dri-drivers=radeon \
    --with-egl-platforms=drm \
    --enable-driglx-direct \
    --enable-gallium-osmesa \
    --enable-gles1 \
    --enable-gles2 \
    --enable-glx \
    --enable-glx-tls \
    --enable-nine \
    --enable-shared-glapi \
    --enable-texture-float

ccache significantly helps reduce build times. Also note the ../mesa/autogen.sh, as I'm building outside of the source directory (which is recommended... maybe required).

Then I hop over to the 32-bit schroot, and basically run the same thing... only I would use /opt/llvm-x86 and /opt/xorg-x86 for everything instead of /opt/llvm and /opt/xorg, and have /opt exported to the schroot like /home (so installing to /opt/xorg-x86 installs to the host too).

I also had to create some symlinks, some of which were for the Wine Gallium patches to find the required files.

/usr/include/d3dadapter -> ../../opt/xorg/include/d3dadapter
/usr/lib/i386-linux-gnu/d3d -> ../../../opt/xorg-x86/lib/d3d
/usr/lib/x86_64-linux-gnu/d3d -> ../../../opt/xorg/lib/d3d
/usr/lib/x86_64-linux-gnu/dri -> ../../../opt/xorg/lib/dri

That last link is ugly, because /usr/lib/x86_64-linux-gnu/dri has to be moved out of the way to create the link (and I don't generally like messing with things installed through the package manager). In theory that shouldn't be required if LIBGL_DRIVERS_PATH=/opt/xorg/lib/dri:/opt/xorg-x86/lib/dri is set in /etc/environment, but lightdm didn't seem to use it which prevented me from being able to log in. This is just a hack until I find a better way to deal with the display manager.

The appropriate d3dadapter and d3d links should also go in the schroot.
/usr/include/d3dadapter -> ../../opt/xorg-x86/include/d3dadapter
/usr/lib/i386-linux-gnu/d3d -> ../../../opt/xorg-x86/lib/d3d

I also have /etc/X11/xorg.conf.d/01-module-path.conf with the following:
Section "Files"
    #ModulePath "/usr/lib/xorg/modules"
    ModulePath "/opt/xorg/lib/xorg/modules,/usr/lib/xorg/modules"
EndSection

Section "Device"
   Identifier "amdgpu"
   Driver "amdgpu"
   Option "DRI" "3"
EndSection

In /etc/ld.so.conf.d/custom-llvm.conf I have:
# LLVM/Clang
/opt/llvm/lib
/opt/llvm-x86/lib

In /etc/ld.so.conf.d/custom-mesa.conf I have:
# libdrm
/opt/xorg/lib
/opt/xorg-x86/lib

# Xorg DDX drivers
/opt/xorg/lib/xorg/modules/drivers
/opt/xorg-x86/lib/xorg/modules/drivers

# mesa
/opt/xorg/lib/d3d
/opt/xorg-x86/lib/d3d
/opt/xorg/lib/dri
/opt/xorg-x86/lib/dri
#/opt/xorg/lib/gallium-pipe
#/opt/xorg-x86/lib/gallium-pipe
/opt/xorg/lib/vdpau
/opt/xorg-x86/lib/vdpau

# experimental
/usr/lib/i386-linux-gnu/d3d
/usr/lib/x86_64-linux-gnu/d3d

Don't forget to run $ sudo ldconfig each time you install files into these directories. This eliminates the need to use LD_LIBRARY_PATH for everything going forward.

Hope that helps.

View this comment - View article - View full comments

Quoting: Dax TailorDo you have a link with a description how to build wine? I tried but there is a problem with the freetype dev lib because it can't be installed in 64 and 32 bit. Most games need the 32 bit wine version. (I could use a chroot environment but it will take some work to setup one.)

I just posted my script here [External Link] for building Wine with 32-bit and 64-bit support. You may need to adjust some of the values. It uses a chroot environment configured with schroot by default (named $(lsb_release -cs)-i386 - "stretch-i386" in my case since I mainly use Debian testing) which has all the wine headers installed. The script should also work with Jessie, and probably any recent Ubuntu release.

To configure a wine build environment just run:
$ apt-get build-dep wine
both inside and outside of your schroot environment. When you run the script, it'll inform you if other header file packages needed for compilation are missing and tell you what needs to be installed. I'm not sure it checks for all of them, but probably the main ones that the above command misses.

The script expects a directory called "git" to exist in the current working directory with a copy of the wine source code, so get that via:
$ git clone git://source.winehq.org/git/wine.git
You can check out a tagged release or whatever. I assume you know the git basics.

You will also need 32-bit versions of wine libraries installed on your 64-bit host. ie. not just having them exist in the chroot. So if you haven't already done so:
$ sudo dpkg --add-architecture i386
$ sudo apt-get update
$ sudo apt-get install libopenal1:i386 libxext6:i386 ... etc

Make sure your schroot environment is configured to use your host home directory when you log in (the default), and that the script and git directory are also located in your home directory. At this point, if I'm not forgetting anything, you're good to start building.
$ ./winebuilder.sh

You should end up with the resulting build in ./build/<timestamp>/ which can be moved to wherever you want to install it to. I'll assume ~/opt/wine
$ mv ./build/<timestamp ~/opt/wine

Before running Wine, we need to let it know where its libraries are.
export LD_LIBRARY_PATH="${HOME}/opt/wine/lib:${HOME}/opt/wine/lib64:${LD_LIBRARY_PATH}"

It's also convenient to add it to the path.
export PATH="${HOME}/opt/wine/bin:${PATH}"

And that this point, you have built the latest Wine with support for both 32-bit and 64-bit programs. Before using it, I recommend running a final check to make sure you aren't missing any 32-bit libraries.

find ${HOME}/opt/wine -type f -exec ldd {} \; | grep 'not found' | sort | uniq
If any "not found" library errors are printed, install the required package through apt-get and run the command again until all errors are gone. Errors would indicate a :i386 package installed in the schroot during compilation that is still missing on the host.

Compiling Clang, Mesa and wine patches would require too much typing for this post... maybe I could add it to the Gaming on Linux wiki at some point?

Not sure about your freetype question, as I don't recall ever having an issue with that. Maybe you need to upgrade your distribution?
$ dpkg -l | grep freetype
ii  libfreetype6:amd64          2.6.3-3+b1          amd64        FreeType 2 font engine, shared library files
ii  libfreetype6:i386           2.6.3-3+b1          i386         FreeType 2 font engine, shared library files
ii  libfreetype6-dev            2.6.3-3+b1          amd64        FreeType 2 font engine, development files

View this comment - View article - View full comments

Finally got around to building the latest git LLVM/Clang, and then using that to build the latest git Mesa with Gallium Nine, and then using that to build Wine 1.9.12 with the Gallium Nine patches. Took a while to figure it all out, but the performance I'm getting is amazing!

Can finally play Alan Wake's American Nightmare, Cryostasis, etc at 2560x1440 with all max detail settings and they run great! Even AMDGPU-Pro with normal Wine doesn't let me max out the detail settings at this resolution (and actually crashes when I try due to not having enough video RAM), so I'm very excited by all this.

Heck, I'm getting 67.6 FPS on average in Tomb Raider 2013, whereas AMDGPU-Pro only got me up to 48.0 with the same (normal) detail settings.

I was playing Dying Light under the proprietary drivers, but I'm going to put that aside for now until Mesa adds the remaining OpenGL features to get it working. If other games are any indication, it will be worth the wait!

View this comment - View article - View full comments

Nice. Added.

View this comment - View article - View full comments

GOG was saying "Also available for Windows and soon for Linux" over a year ago.
https://web.archive.org/web/20150505161751/http://www.gog.com/galaxy [External Link]

Now they offer a free game (System Shock 2) for the next 24 hours or whatever it is, but only to those running Galaxy which is available on all platforms except GNU/Linux. How nice of them! That totally makes me want to go and spend money on their sale. :/

At least Galaxy runs under Wine, but not very well. Well enough to get the game and launch it, only... too bad that unlike Steam, GOG doesn't provide GNU/Linux builds for System Shock 2 either.

View this comment - View article - View full comments

According to my records I originally finished this under Windows 7 back in 2011, as I did dual-boot with Windows 7 up until around mid-2012. But I also remember running this under Wine back around 2013 with Nvidia drivers on a GTX660M, and I recall it running amazingly well.

Normally you would only expect great performance from a game like this when the engine uses OpenGL, but I do not believe that was the case for Hard Reset. Quite impressive! I am aware there is some minor graphical corruption (in parts of the menu at least) when playing the original using fglrx and AMDGPU-Pro, but that's sadly not too unusual for AMD drivers with Wine.

In any case, I'll pick this up as soon as a GNU/Linux version is released. I recall it being a relatively short game (under 8 hours I think), which I actually appreciate since I don't have a lot of free time these days.

View this comment - View article - View full comments

I bought Dead Island: Riptide on launch and played it under Wine. When I saw it was a DirectX9-compatible game, I expected it was using the same engine and took a chance (the game came with a number of bonus items, such as a gaming headset). Sure enough, the game worked perfectly. Of course way back then there was no GNU/Linux versions of most games - Steam for GNU/Linux had only just launched in beta.

These days, Wine isn't good enough to play the latest games. All AAA games require DirectX11, which Wine hasn't implemented enough of. Even if it did, Wine seems to need OpenGL 4.3 or higher for some of the translations which Mesa still doesn't support in a stable release that distributions would include (but you do want to use Mesa for Gallium Nine, for older DirectX9 titles). Then you've got Shadow of Mordor, which seems to require OpenGL 4.4 or 4.5, so even development versions of Mesa likely won't cut it - and if it's anything like Tomb Raider on Mesa, the performance will be absolutely horrible.

It feels like we're in this awkward spot right now where there is no perfect gaming solution. You can use proprietary drivers and miss out on Gallium Nine, or you can use free software drivers and forgo compatibility with some AAA games and get reduced performance.

Next year we should be in a really nice place. Mesa should have easily finished off OpenGL 4.5 for all modern hardware and will be working on performance improvements. Wine should be running a large chunk of DirectX 11 games, if not most of them. Hopefully AMD's had some time to implement FreeSync and Crossfire support into AMDGPU. And then AMD's new high-end cards will be out next year too with what we can expect will be day 1 support via free software drivers. I just hope the performance of the hardware is competitive.

When GNU/Linux gets to that gaming nirvana sometime next year, I'm hopeful we'll start seeing more companies develop for GNU/Linux because it will be easier to support, be easier to use (for those with AMD at least) and be more competitive with other operating systems. This is even more true when you consider most people will be Khronos-ready, especially since AMD have committed to releasing the source code for their implementation - so we can reasonably expect to see it in all distributions out of the box.

And who knows... maybe next year sometime, even GOG will have gotten around to releasing Galaxy?

View this comment - View article - View full comments