Koylio

Sorry, missed this. You can use Lutris or winetricks to install steam + dxvk and their dependencies. I used winetricks, but you need a rather recent version. Then install Arma 3, and with steam running in wine, run arma 3 from commandline. Exact steps would depend on your distro etc. You might need to install some dlls or other components if you get errors.

Did a quick test few weeks ago, and I did get A3 windows version to run with wine and dxvk. The launcher didn't work, but that's the situation with the ports too. I didn't run benchmarks, try battleye or play for long, so there might be issues. Wine might be your best option to keep version parity with your windows running friends.

Did some quick benchmarks on Windows 10 vs. Linux with Arma 3 Benchmark v0.51 Stratis. I did my best to make sure a fair comparison by eg. disabling security features on W10, but I'm not really familiar with W10. I was lazy with the benchmarks, and only did multiple runs with first run or when there were some disk activity during benchmark. There were differences in enviroments, for example linux version was run from NFS share vs. W10 from local HDD. Using the average results where multiple runs were done, all results are average FPS of said benchmark. Graphics setting Linux Windows low 109 106 standard 92 93 high 79 83 very high 70 74 ultra 55 62 This is with Intel i5-4690K and Radeon R390 on some mesa git version between 17.3 and 17.4. Version 1.76 of Arma was used on both.

I have been using that for Arma 3 a while, with no issues. It helps with most, if not all, VP ports. Which version of mesa are you using? I might test it with Arma:CWA port too, and ask them to be included in mesa so everyone would benefit from it out-of-the-box. For now, I would recommend mesa users to enable it in /etc/drirc by adding following lines.

In case someone else is having rendering issues with trees on radeonsi, there is a bug open at b.f.o you might be interested to follow: https://bugs.freedesktop.org/show_bug.cgi?id=101739

If I would have to guess, you won't be getting the full windows experience on linux until windows version runs on wine. And thats fine with me, I'm not interested to eg. give root privleges to battleye. There are lots of things to consider in multi-platform game developement, if you are interested take a look at linux gaming sites for articles about those. I'm patiently waiting for the 64-bit version to come some day.

You can try the "legacyports" branch. See https://community.bistudio.com/wiki/Arma_3_Experimental_Ports#Cross-Platform_Windows_Compatibility

I haven't had any luck to get joysticks to work with the port. I have tried with old analog stick connected to game port, and Steam Controller on another box. Everything else works with SC, except joystick movement. I can map the buttons, stick etc. to keys and mouse, but not as joystick. The analog stick doesn't work at all. The community wiki has this to say: I'm quite not sure what "modifying the mapping text" means. I have configured both with Steam BPM, so SDL_GAMECONTROLLERCONFIG is defined, and the logs show that, but in game joysticks still wont work. Has someone had any luck with analog joystick inputs on the linux port?

In case some one else has the same issues, something I have found out while battling with the analog joystick: 1. You need to define mapping in SDL2 format either in Steam BPM, SDL2_GAMECONTROLLERCONFIG enviroment variable, SDLGamepad.config file in installation direcory, or --eon_gamepad_mapping= command line option, unless you already have a model listed in SDLGamepad.config. Only later evdev API gamepads are supported. 2. Despite what wiki says, remapping buttons and axis in game via Options -menu works. 3. Default bindings are gamepad keys A,B,X,Y for buttons, dpad for POV-hat, left stick for controls, and triggers/shoulderbuttons for thrust/rudder. 4. Joystick doesn't work every time the game is launched, for me atleast. 5. Inverting axis (and maybe other recent additions to SDL2_gamecontrollerdb) via mapping is not supported. Trying to get the SC to work next.

According to community wiki, the ports are limited to 768 MB of VRAM on Linux due to being 32bit OpenGL application. Hope we get an upgrade to 64bit builds to fix this. https://community.bistudio.com/wiki/Arma_3_Experimental_Ports#Known_Issues

I case this is news to you, linux and mac versions of Cold War Assault (renamed OFP) are in beta. Arma 2 runs in wine with AMD graphics and gallium-nine as fast as in windows, and without issues. Gallium-nine unfortunately doesn't work with Nvidia, and there is a bug report about graphics issues with Nvidia drivers. Maybe we'll get ports for Arma and Arma 2 too in the future.

If you have AMD graphics and OSS drivers, upgrading mesa will fix this.

You are propably using mesa prior version 12. If so, an upgrade to mesa version 12+ will solve your issue.

Just to let you know, that the videoram is now limited to 768Mb on my system too, so limiting VRAM is not nvidia only issue anymore. More info in the generated .rpt file at "~/.local/share/bohemiainteractive/arma3/AppDataLocal/Arma\ 3/". I still can set the textures to high, so this issue with low textures is propably caused by something else.

Might be worth checking that you have enought space for temporary files. Atleast version 1.54 required about 2gb of available disk space in /tmp, or it crashed. On your system it's on root partition, df -h will tell if that's the case. If you think it's an issue with display drivers, there might be other forums where you might have more people who might be able to help you.

I did get CUP Terrains to load. It gave errors about some missing stuff and had some visual effects wrong, but started. I tried with complete pack versions 1.1.0 and 1.2.0, no other mods. Some people have issues with corrupted workshop downloads, or could be your startup parameters missing escaping backslash. Would you mind posting how exactly did you start the game?

Moving the audio stream with pavucontrol works for me, but moving a surround stream to stereo device has it's issues. I do run steam as a dedicated user with pulseaudio set to pass audio through unix socket.

I did some experimenting with linux client, and wanted to share what I found out. I started with a benchmark result of 40fps on i5-4690K and Radeon 390 with open source driver. First test was to try AMDgpu kernel driver instead of radeon, as some performance increase was reported with it. Unfortunetly for A3, I didn't see an improvement with FPS, but another benchmark benefitted slighly with it. Long story short, I ended up with radeon and DRI3 enabled, witch gave me the same results and less tearing than DRI2. Arma seemed CPU-limited, so that was on the agenda next. Changing the governor from ondemand to performance showed an increase of ~3fps. Changing the CPU frequency scaling driver from acpi to pstate allowed the CPU to rise frequency to 3.9GHz, and and performance was increased to ~45fps. Selected governor didn't seem to matter anymore. Patching the kernel with BFS scheduler gave an another boost of ~2fps. Some other kernel optimizations (CONFIG_CC_STACKPROTECTOR_NONE, CONFIG_JUMP_LABEL, CONFIG_CC_OPTIMIZE_FOR_SIZE) had barely effect. Compiling mesa with more optimizations after -march=native -O2 decreased performance, and disabling steam runtime and using the --eon_disable_catalyst_workaround switch didn't improve anyting. Either did running steam in big picture mode without desktop. New si-scheduler in mesa did show improvement in other benchmarks, and seemed to help A3 run more smoothly, but didn't show an increase in fps. In the end I had an average of 48,5fps of two runs. With W7 I had average of 47fps, but it was a more recent version of A3. Improvement also showed in Arma 2 with wine, performance is now on par with windows. Hope you find these results interesting. What I still want to try is experiment with kernel timer frequency and scheduler.

If you have an AMD gpu and are running mesa drivers, you might want to update to latest git-version. Git-3f10067 gave me a nice increase to 50,7fps (average of three runs of Arma 3 benchmark v.0.51 Stratis) from 48,3fps with git-3fb4a9b from last week.

VP (the company thats making these ports) seems to be testing both with mesa and AMD drivers. They mentioned mesa (radeonsi) working better than fglrx inhouse. Haven't had the time to try these beta drivers, I guess I'm not going to bother with them anymore.

Just in case you wan't to try the opensource driver too, it works but you need a fairly new git version. Radeonsi driver in mesa had it's maximum shader sampler count increased in april 7th, before it you needed to set shadows to disabled in graphics settings to play.

Reporting here because feedback.arma3.com is down, and someone else might run to this too. Linux port version 1.54 (and ealier too) crashes without meaningful error message, when /tmp is full. I noticed this while using 512Mb tmpfs (a ram disk) as /tmp partition. While game is running, it seems to use 651Mb of temporary file storage space in my case, but this propably depends on map and other variables. Looking at strings in the binary, there seems to be a check for failure in temp folder creation, but not one for running out of space. It would be nice to have a meaningful error message instead of crash. Just checking for space at start isn't sufficent, since /tmp is usualy world writeable and can be filled up by another processes or users. Also it would be nice to allow for user to set the location of temporary files, now /tmp seems to be hard coded.

About running with intel graphics, one of the intel developers posted a note on mesa bugzilla that arma 3 runs with linux intel driver. He didn't mention the hardware used or anything about performance, and you might require installing the current developement version yourself. Phoronix is asking help with setting an automatic benchmarking profile for Arma 3 linux client. If someone knows a good benchmark mission and how to run it from commandline, you can share your knowledge in the comments to see some professionally run benchmarks of Arma 3.

I thought that amdgpu is just a new kernel interface that both mesa and later catalyst could use. I think there was an article at phoronix about that. Drivers would still mostly live in userspace. Regardind catalyst performance, I also recall that someone reported that --eon-disable-catalyst-workarounds might improve performance with latest catalyst drivers on VP ported titles. Some other people have found with other games that one can activate driver optimizations by renaming the game binary to some other games binary that has optimized profile. I haven't tried those, since catalyst fails to compile on me with 4.2.0 kernel, and I prefer the OSS driver. For Mesa shader issue, there is a bug report on bugs.freedesktop.org, lets see how it turns out.

I might have to do that, but I am really not a fan of fglrx driver. With mesa-11.0.0-rc2, game runs and performance is OK. VR Training works, but trying any challenges or showcases on real maps crashes with, for example, a shader error: [thread 0000000f][E][48888]: Program from shader GL_FRAGMENT_SHADER with length 20611 and CRC 0xae61bc1c has not been successfully linked. Program info log: error: Too many fragment shader texture samplers This could be a driver issue, but after the crash some stale tmp files are left, and trying to launch the game makes it crash instantly again: [thread 00000004][W][154]: REGISTRY OPERATION: RegOpenKeyExW() returns ERROR_NOT_FOUND (subkey not found) key = HKEY_LOCAL_MACHINE, subkey = Software\Bohemia Interactive\Arma 3\Expansions [thread 00000004][W][154]: REGISTRY OPERATION: RegOpenKeyExW() returns ERROR_NOT_FOUND (subkey not found) key = HKEY_LOCAL_MACHINE, subkey = Software\Bohemia Interactive\Arma 3\Expansions Removing /tmp/arma3* makes this go away, and arma 3 runs again, so another minor issue here. Let's see what I can break next, plan was to take a look at the shader issue with debugger, and maybe try with fglrx.