Compiling Win32 ARM64

[Gerdya]

Hi all, i am currently trying to compile for Win32 ARM64 using MSVC 2017 and Windows SDK 16299 and running into few issues which you might be able to help.

What i did as far is:

1) added ARM64 platform targets to project files
2) added _M_ARM_64 to defines
3) upped SDK version to 16299 in project files
4) excluded x64 specific files form compilation when $(Platform)==ARM64
5) added ARM64 specific or generic files to project but excluded them when $(Platform)==x64
6) disabled DirectInput controller module when _M_ARM_64 is defined (there are not DX8 libraries in Windows for ARM)
7) moved x64 ffmpeg libraries from externals/ffmpeg/lib to externals/ffmpeg/lib/x64
8) added ARM64 ffmpeg libraries to externals/ffmped/lib/ARM64 - changed library search path for both x64 and ARM64 accordingly in project files
9) removed a few warning in JITARM64 and die few other small changes in some sources

So things are now compiling fine for both x64 and ARM64 but i am getting linker errors under ARM64 which i cannot trivially resolve:

1) In DSPcore.cpp -> std::unique_ptr<JIT::x64:SPEmitter> g_dsp_jit;
2) In DSPTables.cpp -> const std::array<DSPOPCTemplate, 214> where DSPOPCTemplate is again related to JIT::x64:SPEmitter
3) In DSPLLE.cpp -> several references to std::unique_ptr<JIT::x64:SPEmitter> g_dsp_jit

Essentially i am having a dependency to JIT::x64:SPEmitter, which do not know how to resolve.

Help or some pointers would be appreciated.

BR,
Gerdya

[JosJuice]

If you've excluded the Core/Core/DSP/Jit/x64/ files from compilation, you should undo that. It's not ideal that Dolphin compiles the x64 DSP JIT even when it can't be used on the current CPU architecture, but that's how we're doing it for now.

[Gerdya]

(03-26-2018, 01:22 AM)JosJuice Wrote: If you've excluded the Core/Core/DSP/Jit/x64/ files from compilation, you should undo that. It's not ideal that Dolphin compiles the x64 DSP JIT even when it can't be used on the current CPU architecture, but that's how we're doing it for now.

Thanks! Indeed i did exclude these files. After i did put them back in i also had to put back in x64Emitter.cpp and x64ABI.cpp because DSPEmitter is derived from XEmitter (and is happily emitting x64 instructions).
From design point of view i assume it would be a good idea to have an abstract base class for DSPEmitter, which can be referenced in more generic code like DSPTables.cpp without generating too many host architecture related dependencies.

In any case linker errors are gone, the only issue left are references from Common.lib(WGL.obj) into opengl32.lib, which does not exist for ARM64.

I did disable the instantiation of the OGL backend as follows in VideoBackendBase.cpp

Code:

#if !defined _M_ARM_64 || !defined _WIN32
 g_available_video_backends.push_back(std::make_unique<OGL::VideoBackend>());
#endif
#ifdef _WIN32
 g_available_video_backends.push_back(std::make_unique<DX11::VideoBackend>());
#endif
#ifndef __APPLE__
 g_available_video_backends.push_back(std::make_unique<Vulkan::VideoBackend>());
#endif
 g_available_video_backends.push_back(std::make_unique<SW::VideoSoftware>());
 g_available_video_backends.push_back(std::make_unique<Null::VideoBackend>());

but that's not the whole story.
Again thanks a lot, the issues with DPSEmitter are gone

BR,
Gerdya

[JosJuice]

I wonder if you could just exclude everything that's in Source/Core/Common/GL/... I haven't really worked on the graphics backend code, so I'm not sure if that's going to lead to problems with something else.

[Gerdya]

(03-26-2018, 03:38 AM)JosJuice Wrote: I wonder if you could just exclude everything that's in Source/Core/Common/GL/... I haven't really worked on the graphics backend code, so I'm not sure if that's going to lead to problems with something else.

Its already excluded from build. However i found something disturbing:

The VideoConfig class is implemented in VideoConfig.cpp ...as far as good ... except: 

void VideoConfig::UpdateProjectionHack()

{
  ::UpdateProjectionHack(g_Config.phack);
}

Is implemented in VideoBackends/OGL/Render.cpp

Since i have excluded that file i am getting a linker error. On the other hand i do not see a single reason why it is not implemented in VideoConfig.cpp as it should be? So i moved the implementation into VideoConfig.cpp but why wasn't it there in the first place?

[Gerdya]

Finally got it compile without warnings or error and i have now a shiny new Dolphin.exe in my Dolphin/binary/ARM64 folder.

Since i do not have an actual Windows ARM device yet I did fire up QEmu runing Windows 10 Pro for ARM64.

And hey! Its working (i am using Interpreter Mode). I am actually getting a frame each few seconds :p


See:

Dolphin under Windows 10 Pro for ARM64

*cheers* thanks for the help!

[mbc07]

(03-26-2018, 04:44 AM)Gerdya Wrote: Since i have excluded that file i am getting a linker error. On the other hand i do not see a single reason why it is not implemented in VideoConfig.cpp as it should be? So i moved the implementation into VideoConfig.cpp but why wasn't it there in the first place?

AFAICT our video backend code were always a bit messy. Fortunately, stenzek and the others started refactoring that recently, and indeed it's better now, but there are still some rough edges like these, that'll eventually be fixed, I think...

[degasus]

(03-26-2018, 05:42 AM)Gerdya Wrote: Finally got it compile without warnings or error and i have now a shiny new Dolphin.exe in my Dolphin/binary/ARM64 folder.

Since i do not have an actual Windows ARM device yet I did fire up QEmu runing Windows 10 Pro for ARM64.

And hey! Its working (i am using Interpreter Mode). I am actually getting a frame each few seconds :p


See:

Dolphin under Windows 10 Pro for ARM64

*cheers* thanks for the help!

Really really nice. *thumbs up*

How bad crashes the JIT? I fear we might need to disable one register on windows.

Feel free to join #dolphin-dev on freenode, most developers are quite active on IRC.

Edit: For better performance, use DSP HLE instead of LLE and the cached interpreter for the PPC. Both are plattform independent.

[degasus]

Sorry for double post, but I was asked for a better screenshot: May you run any VC game (eg Ocarina of Time) and make a screenshot with the outer operation system? I think of a x64 -> arm -> ppc -> mips interpreter chain

[Gerdya]

(03-27-2018, 03:46 AM)degasus Wrote: Really really nice. *thumbs up*

How bad crashes the JIT? I fear we might need to disable one register on windows.

Feel free to join #dolphin-dev on freenode, most developers are quite active on IRC.

Edit: For better performance, use DSP HLE instead of LLE and the cached interpreter for the PPC. Both are plattform independent.

Have not tried JIT yet, part of the reason is i have still one thing on TODO: MSVC does not support inline assembly for ARM64 targets and i found 1 inline assembly function in the ARM64 JIT code, which is the data cache flush and instruction cache invalidation function. So my plan is to port this function into a separate *.asm file and do custom build step.

On Qemu you likely will not get any reasonable performance, my guess is that the translation from ARM64->x64 is performance degradation of around factor 20. On top of this there is no HW D3D driver under QEmu, so what you see is software emulation of D3D11