• Login
  • Register
  • Dolphin Forums
  • Home
  • FAQ
  • Download
  • Wiki
  • Code


Dolphin, the GameCube and Wii emulator - Forums › Dolphin Emulator Discussion and Support › Development Discussion v
« Previous 1 ... 9 10 11 12 13 ... 116 Next »

Compiling Win32 ARM64
View New Posts | View Today's Posts

Pages (5): 1 2 3 4 5 Next »
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Thread Modes
Compiling Win32 ARM64
03-26-2018, 12:41 AM
#1
Gerdya Offline
Junior Member
**
Posts: 20
Threads: 1
Joined: Mar 2018
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:Big GrinSPEmitter> g_dsp_jit;
2) In DSPTables.cpp -> const std::array<DSPOPCTemplate, 214> where DSPOPCTemplate is again related to JIT::x64:Big GrinSPEmitter
3) In DSPLLE.cpp -> several references to std::unique_ptr<JIT::x64:Big GrinSPEmitter> g_dsp_jit

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

Help or some pointers would be appreciated.

BR,
Gerdya
Find
Reply
03-26-2018, 01:22 AM
#2
JosJuice Offline
Developer
**********
Developers (Some Administrators and Super Moderators)
Posts: 8,837
Threads: 7
Joined: Oct 2014
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.
Find
Reply
03-26-2018, 03:21 AM
#3
Gerdya Offline
Junior Member
**
Posts: 20
Threads: 1
Joined: Mar 2018
(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 Smile

BR,
Gerdya
Find
Reply
03-26-2018, 03:38 AM
#4
JosJuice Offline
Developer
**********
Developers (Some Administrators and Super Moderators)
Posts: 8,837
Threads: 7
Joined: Oct 2014
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.
Find
Reply
03-26-2018, 04:44 AM
#5
Gerdya Offline
Junior Member
**
Posts: 20
Threads: 1
Joined: Mar 2018
(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?
Find
Reply
03-26-2018, 05:42 AM (This post was last modified: 03-26-2018, 05:43 AM by Gerdya.)
#6
Gerdya Offline
Junior Member
**
Posts: 20
Threads: 1
Joined: Mar 2018
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!
Find
Reply
03-26-2018, 03:29 PM
#7
mbc07 Offline
Wiki Caretaker
*******
Content Creators (Moderators)
Posts: 3,562
Threads: 47
Joined: Dec 2010
(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...
Avell A70 MOB: Core i7-11800H, GeForce RTX 3060, 16 GB DDR4-3200, Windows 11 (Insider Preview)
ASRock Z97M OC Formula: Pentium G3258, GeForce GT 440, 16 GB DDR3-1600, Windows 10 (22H2)
Find
Reply
03-27-2018, 03:46 AM (This post was last modified: 03-27-2018, 03:50 AM by degasus.)
#8
degasus Offline
Developer
**********
Developers (Some Administrators and Super Moderators)
Posts: 1,827
Threads: 10
Joined: May 2012
(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.
Find
Reply
03-27-2018, 09:43 PM
#9
degasus Offline
Developer
**********
Developers (Some Administrators and Super Moderators)
Posts: 1,827
Threads: 10
Joined: May 2012
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 Big Grin
Find
Reply
03-28-2018, 06:29 AM (This post was last modified: 03-28-2018, 06:29 AM by Gerdya.)
#10
Gerdya Offline
Junior Member
**
Posts: 20
Threads: 1
Joined: Mar 2018
(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 Smile
Find
Reply
« Next Oldest | Next Newest »
Pages (5): 1 2 3 4 5 Next »


  • View a Printable Version
  • Subscribe to this thread
Forum Jump:


Users browsing this thread: 1 Guest(s)



Powered By MyBB | Theme by Fragma

Linear Mode
Threaded Mode