DolphinQt: Support compiling on ARM64

[stenzek]

Still no ffmpeg yet, but I was planning on making this a completely external dependency and loading it at runtime at some point anyway.

Briefly tested by someone very helpful on IRC and confirmed to be working, but I am unable to test it myself as I do not have access to a device.

[stenzek]

Build will fail until the submodule is updated, this is expected. See dolphin-emu/ext-win-qt#10

[shuffle2]

I only had to place libGLESv2, will libEGL be used in some case?

[stenzek]

If we want to use it for the software rasterizer or GL backend, potentially

[shuffle2]

lgtm

[stenzek]

Submodule PR updated to Qt 5.14.0.

[stenzek]

@shuffle2 btw, there were a couple of errors in your build instructions from the other thread. Posting here for future reference:

• Calling vcvarsall.bat breaks the ARM64 build, seems to cause it to build moc/uic/etc as ARM64 instead of x86. So, just a plain old developer command prompt should be used.
• -angle is required, otherwise configure fails with a precondition error if you don't use -dynamic, and using -dynamic fails building QOpenGL.
• I believe the errors later on with regard to translation were because the x86 host tools build was incomplete. With a complete build, it'd probably go through fine.

FWIW, this was the command line I used:
..\qt-everywhere-src-5.14.0\configure -opensource -confirm-license -nomake tests -nomake examples -skip webengine -opengl es2 -angle -mp -xplatform win32-arm64-msvc2017 -external-hostbindir C:\build\qt5_x86\qtbase\bin

[shuffle2]

for vcvarsall, you can only call this once per cmd process (it just appends to environment variables, doesn't clear improper things out). So doing it once for each x86 and x86_arm64 toolchain should be fine(?)

anyway glad it worked out

[stenzek]

Yeah, I'm aware (I was using separate cmd windows for each). The key ended up being to not call vcvarsall at all, and let qt/qmake/whatever figure out the compiler on its own.

[shuffle2]

Still no ffmpeg yet, but I was planning on making this a completely external dependency and loading it at runtime at some point anyway.

Making the existing ffmpeg config (https://github.com/shuffle2/FFmpeg/tree/dolphin) produce shared libs results in:

$ ls -lh ext-win-ffmpeg/x64/bin/
total 6.6M
-rwxrwxrwx 1 shawn shawn  2.2M Jan  8 04:07 avcodec-58.dll
-rwxrwxrwx 1 shawn shawn   46K Jan  8 04:07 avcodec.lib
-rwxrwxrwx 1 shawn shawn 1018K Jan  8 04:07 avformat-58.dll
-rwxrwxrwx 1 shawn shawn   38K Jan  8 04:07 avformat.lib
-rwxrwxrwx 1 shawn shawn  1.4M Jan  8 04:07 avutil-56.dll
-rwxrwxrwx 1 shawn shawn  116K Jan  8 04:07 avutil.lib
-rwxrwxrwx 1 shawn shawn  699K Jan  8 04:07 swresample-3.dll
-rwxrwxrwx 1 shawn shawn  6.3K Jan  8 04:07 swresample.lib
-rwxrwxrwx 1 shawn shawn  1.2M Jan  8 04:07 swscale-5.dll
-rwxrwxrwx 1 shawn shawn  8.6K Jan  8 04:07 swscale.lib

this seems somewhat annoying as the filenames are versioned, and I don't think there is an option to compile into a single file (?). So assuming users will find and place the correct files in a place dolphin expects them is unreasonable to me.

edit: Actually, ffmpeg doesn't provide windows builds, and the external site they point you towards doesn't even distribute libs (nor arm64 at all). So these should be provided by dolphin anyways.

I don't see an advantage to loading ffmpeg libs dynamically.

[stenzek]

@shuffle2 the advantage is we shrink our download sizes for a feature that most users don't use. Uses less disk space on our servers. I remember correctly delroth has mentioned in the past that the archives are quite large.

[shuffle2]

Dolphin would still need to host the binaries for the reasons I outlined (you may as well just remove it wholesale from windows builds if binaries aren't provided), and the dlls add more space than static libs.

[stenzek]

Yes, I was thinking adding an auto-download the first time it would be used. The difference would be we'd only need to host one copy of the dlls, as opposed to bloating every single build/PR.

[shuffle2]

Also, such arguments (and the micro-space saving commits made recently) are pretty funny considering stuff like #8063 (comment)

I haven't measured ffmpeg's static lib contribution to dolphin.exe size, but we barely use any functionality of ffmpeg...it should be very small.

[stenzek]

Indeed. Adding 10MB for a single feature seems a bit.. unreasonable. But that's just my opinion ;)

[shuffle2]

on x64 build:

-rwxrwxrwx 1 shawn shawn 12715520 Jan  8 03:50 Dolphin_ffmpeg.exe
-rwxrwxrwx 1 shawn shawn 11297280 Jan 11 21:47 Dolphin_noffmpeg.exe

~1.4MiB
.. opposed to 5 versioned dlls of ~6MiB

[shuffle2]

Depending on the tradeoffs wanted on the build server, maybe it makes more sense to enable ltcg in any case; aside from ffmpeg topic. This is toggle-able via "DolphinRelease" msbuild property, but last i knew, buildserver wasn't enabling it. I think dolphin was hitting some codegen bugs which required disabling it, but I can't remember the details...and that was a few compiler versions ago.

[stenzek]

Hmm, okay. That's... much less of a difference than I expected. Not really worthwhile then :/

LTCG could have some minor speed improvements too, so I think it's worthwhile investigating.

[mrcobra92]

So I feel bad for posting this, but how do I run this? I am not super savvy with coding or compiling code, I just want to run dolphin on my Surface Pro X. Is there a pre-compiled installer for the ARM64 build of dolphin on windows? Thanks!

[shuffle2]

I think @delroth was looking at building arm64 on buildbot, but not posting builds to the main site. https://buildbot.dolphin-emu.org/#/workers/4 currently the builder doesn't seem to be setup, so you'll have to wait or compile for yourself for now.

[mrcobra92]

Got it working! Did a bit of reading and figured out how to compile the program. It works really REALLY well on the Surface Pro X. Would love to see this as an official download option from the website for others who are looking for the same.

[stenzek]

@mrcobra92 thanks for the feedback! It's a bit difficult for me to test it since I don't have a device, and the person who tested the previous iteration was using a different Qt build. Glad to hear it all worked.

FWIW, compiling for ARM64 should be the same as compiling for x64. Should only have to change the configuration drop-down in Visual Studio.