Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Platform support for Windows-on-ARM64 #8495

Open
wants to merge 4 commits into
base: master
from

Conversation

@stenzek
Copy link
Contributor

stenzek commented Nov 26, 2019

What the title says. Enables Dolphin to run natively on Windows-on-ARM64 devices, such as the Surface Pro X. Most of the lines changed are in the vcxproj files...

I don't have a device to test, but some users have reported that these changes do work.

No Qt build yet as I've had issues compiling Qt for ARM64, so there's only NoGUI for now. If we do want to merge this, we'd want to split out the VS2019 update and the Win32 NoGUI platform.

@stenzek stenzek force-pushed the stenzek:windows-arm64 branch from 02d1d2c to 3dac988 Nov 26, 2019
@@ -368,7 +368,17 @@ void JitArm64::cntlzwx(UGeckoInstruction inst)

if (gpr.IsImm(s))
{
gpr.SetImmediate(a, __builtin_clz(gpr.GetImm(s)));
const u32 imm = gpr.GetImm(s);
#ifdef _MSC_VER

This comment has been minimized.

Copy link
@degasus

degasus Nov 26, 2019

Member

Please just avoid the intrinsic here. This can be done in pure C++

return DefWindowProc(hwnd, msg, wParam, lParam);
}

#if 0

This comment has been minimized.

Copy link
@degasus

degasus Nov 26, 2019

Member

dead code?

@@ -692,7 +692,7 @@
# else
# define LZO_INFO_ARCH "arm"
# endif
#elif defined(__arm__) || defined(_M_ARM)
#elif defined(__arm__) || defined(_M_ARM) || defined(_M_ARM64)

This comment has been minimized.

Copy link
@cremno

cremno Nov 26, 2019

Contributor

What about updating the bundled LZO files instead? The current version seems to support arm64.

@@ -95,6 +95,8 @@
<AdditionalOptions>/Zo %(AdditionalOptions)</AdditionalOptions>
<!--Treat sources as utf-8-->
<AdditionalOptions>/utf-8 %(AdditionalOptions)</AdditionalOptions>
<!--Treat sources as utf-8-->
<AdditionalOptions>/utf-8 %(AdditionalOptions)</AdditionalOptions>

This comment has been minimized.

Copy link
@JosJuice

JosJuice Nov 26, 2019

Contributor

Aren't these two lines the same as the previous two lines?

This comment has been minimized.

Copy link
@stenzek

stenzek Nov 27, 2019

Author Contributor

Indeed. Not sure how that snuck in there.

Copy link
Member

BhaaLseN left a comment

With the SLN and everything updated to Visual Studio 2019, is there any particular reason to stick to the v142 toolset (rather than using v150 or higher)? This is mainly for binary compatibility if 3rd party components aren't updated to the new toolset yet; and I don't recall any binaries in there that we didn't precompile ourselves.

<ProjectConfiguration Include="Release|x64">
<Configuration>Release</Configuration>
<Platform>x64</Platform>
</ProjectConfiguration>
</ItemGroup>
<PropertyGroup Label="Globals">
<ProjectGuid>{8ADA04D7-6DB1-4DA4-AB55-64FB12A0997B}</ProjectGuid>
<WindowsTargetPlatformVersion>10.0.17134.0</WindowsTargetPlatformVersion>
<WindowsTargetPlatformVersion>10.0</WindowsTargetPlatformVersion>

This comment has been minimized.

Copy link
@BhaaLseN

BhaaLseN Nov 26, 2019

Member

Note: this requires a recent MSBuild (and/or Visual Studio 2019?) Version to work correctly. This basically means "use the latest available 10.0 SDK" while not limiting it to a specific build; but older versions of MSBuild/VS don't support this and simply fail with "Cannot find Windows SDK version 10.0" instead.
I think this needs at least 16.3, but I don't remember exactly if it was just any 16.x (since I've seen similar failures while attempting to do this with VS 2019 on the developer machine but VS 2017 build tools on the CI builders)

This ofc. goes for all the projects, not just this one.

This comment has been minimized.

Copy link
@stenzek

stenzek Nov 27, 2019

Author Contributor

The builders have been updated to VS2019, so I don't think this should be a problem.

This comment has been minimized.

Copy link
@BhaaLseN

BhaaLseN Nov 27, 2019

Member

Good to know. But now that you mention this; I think we also need to update the developer requirements in our README. Or does this still build on VS 2017 without installing additional things?

@@ -473,10 +482,10 @@
<ProjectReference Include="$(CoreDir)VideoBackends\D3D\D3D.vcxproj">
<Project>{96020103-4ba5-4fd2-b4aa-5b6d24492d4e}</Project>
</ProjectReference>
<ProjectReference Include="$(CoreDir)VideoBackends\OGL\OGL.vcxproj">
<ProjectReference Include="$(CoreDir)VideoBackends\OGL\OGL.vcxproj" Condition="'$(Platform)'!='ARM64'">

This comment has been minimized.

Copy link
@BhaaLseN

BhaaLseN Nov 26, 2019

Member

I get the feeling you wrote this one by hand, while all the others are VS generated. All the others could be more compact if they just did a Platform check instead of a combined Platform/Configuration one; but VS won't do that using the UI.

#ifdef _WIN32
g_available_video_backends.push_back(std::make_unique<DX11::VideoBackend>());
g_available_video_backends.push_back(std::make_unique<DX12::VideoBackend>());
#endif
g_available_video_backends.push_back(std::make_unique<Vulkan::VideoBackend>());
#ifdef HAS_OPENGL

This comment has been minimized.

Copy link
@BhaaLseN

BhaaLseN Nov 26, 2019

Member

Uh, why is the Software Renderer dependant on OpenGL? That sounds...odd?

This comment has been minimized.

Copy link
@JosJuice

JosJuice Nov 26, 2019

Contributor

It uses OpenGL for scanout but not rendering.

@stenzek

This comment has been minimized.

Copy link
Contributor Author

stenzek commented Nov 27, 2019

With the SLN and everything updated to Visual Studio 2019, is there any particular reason to stick to the v142 toolset (rather than using v150 or higher)? This is mainly for binary compatibility if 3rd party components aren't updated to the new toolset yet; and I don't recall any binaries in there that we didn't precompile ourselves.

Isn't VS2019 v142?

@stenzek stenzek force-pushed the stenzek:windows-arm64 branch from 3dac988 to 9f27f04 Nov 27, 2019
@BhaaLseN

This comment has been minimized.

Copy link
Member

BhaaLseN commented Nov 27, 2019

Isn't VS2019 v142?

Well yeah, not sure why I had v150 in my head; but you're right. The v14x series is simply binary compatible, while v140 came with VS 2015, vs141 with 2017 and v142 with 2019.
I think during previews they had a v150 toolset with newer C++ Standard support; but I guess they figured out how to include that in the same runtime.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
5 participants
You can’t perform that action at this time.