Feature Request - ARM64 support

[NeomMob]

We are starting now to see some new devices from Microsoft using ARM64 architecture. I am wondering if there is a forecasted support for them.

[kpreisser]

See also dotnet/winforms#2053 and dotnet/wpf#1817 for the progress of Windows ARM64 support in .NET Core, including WinForms and WPF.

[amaitland]

I personally have no plans to support Win ARM64, I don't own a suitable device.

For background.

• There are no builds on http://opensource.spotify.com/cefbuilds/index.html not clear if there will be any publicly available.
• From what I can tell CEF support (probably Chomium in general) for building Win ARM64 is still in it's early stages.
  • https://bitbucket.org/chromiumembedded/cef/issues/2773/windows-add-arm64-build-support
  • `https://bitbucket.org/chromiumembedded/cef/pull-requests/266
• I'm not sure Chrome has actually released an official version, so it's likely too early to look at from a stability point of view.

[amaitland]

Someone else is welcome to take responsibility for adding and supporting Win ARM64. An ongoing commitment would be required.

[amaitland]

Official Windows ARM64 builds starting with M88 will be available shortly from https://cef-builds.spotifycdn.com/index.html#windowsarm64.

As per https://bitbucket.org/chromiumembedded/cef/issues/2773/windows-add-arm64-build-support#comment-59706180

This is blocked on the linker errors when attempting to compiler CefSharp.Core.Runtime targeting .Net 5.0 (required for ARM64). As reported in #3284 (comment) which I've confirmed as being a problem.

2>MSVCMRTD_netcore.LIB(mstartup.obj) : error LNK2022: metadata operation failed (80131195) :
2>MSVCMRTD_netcore.LIB(mstartup.obj) : error LNK2022: metadata operation failed (80131195) :
2>MSVCMRTD_netcore.LIB(mstartup.obj) : error LNK2022: metadata operation failed (80131195) :
2>LINK : fatal error LNK1255: link failed because of metadata errors

The CefSharp.BrowserSubprocess.Core project compiles successfully, it's less complicated though, it's possible there's just a linker setting that's causing the problem or we might need to raise an issue with Net 5 Team.

[amaitland]

For anyone interested in tacking this it looks like the first build is up on https://cef-builds.spotifycdn.com/index.html#windowsarm64

First step would be working out how to generate libcef_dll_wrapper.lib

Currently https://github.com/cefsharp/cef-binary/blob/master/build.ps1 downloads, builds and packages the x86/x64 versions, it should be possible (haven't tried obviously) to extend this to download, build and package the arm64 target binaries.

[kpreisser]

This is blocked on the linker errors when attempting to compiler CefSharp.Core.Runtime targeting .Net 5.0 (required for ARM64). As reported in #3284 (comment) which I've confirmed as being a problem.

Note that switching to net5.0 might not actually be necessary for supporting arm64 in CefSharp. With cef.sdk 88.1.2 that includes the ARM64 versions of libcef.lib and libcef_dll_wrapper.lib (from cefsharp/cef-binary#90), I was able to successfully compile CefSharp.Core.Runtime and CefSharp.BrowseSubprocess.Core after adding arm64 as platform target, and confirmed with dumpbin.exe /headers that the produced DLLs (ijwhost.dll, CefSharp.Core.Runtime.dll, CefSharp.BrowserSubprocess.Core.dll) are actually ARM64 DLLs.

I still need to check whether building a CefSharp WinForms/OffScreen app for win-arm64 with .NET 5.0 and running it on a Windows 10 on ARM machine actually works (WPF is not yet supported for win-arm64).

[amaitland]

Thanks to @kpreisser support has been added to master, the MyGet feed should have packages that anyone can test.

https://www.myget.org/gallery/cefsharp

• It's my understanding that WinForms/WPF support for ARM64 hasn't officially been released as part of .Net 5.0
• The CEF/CefSharp builds don't run through the same automated testing that the x64/x86 builds do (there's no automated testing for CEF builds that I'm currently aware of, and there isn't any for CefSharp). I personally haven't tested these builds as I don't own the required hardware.

I'll leave this open for now as the issue will be closed when the changes make their way into a release branch.

If you have a chance please test out the nightly builds under ARM64 and report back here. Please hold off on opening new issues for now (report here instead).

[amaitland]

It looks like .Net 5.0.8 now officially supports targeting WinForms/WPF for `ARM64.

https://devblogs.microsoft.com/dotnet/net-july-2021/#windows-arm64

Once AppVeyor has updated to include the newest SDK we can look at officially releasing ARM64 builds.

https://www.appveyor.com/docs/windows-images-software/#net-framework

[ghost]

Hi @amaitland It looks like appveyor has updated the .NET SDK to 5.0.302 which is the version that includes ARM64 SDK. How complicated would it be to build CEFSharp for Windows ARM64 now? Thanks!

[amaitland]

You can test build 92.0.250-CI4152 which is now on
https://www.myget.org/gallery/cefsharp

It was hopefully build with the latest SDK.

[ghost]

@amaitland It turns out the latest version of chromiumembeddedframework.runtime package does contain win-arm64 runtime, while the latest version of CefSharp.Common.NETCore doesn't:

➜ ls -1 chromiumembeddedframework.runtime.92.0.26/CEF
win-arm64
win-x64
win-x86

➜ ls -1 cefsharp.common.netcore.92.0.260/runtimes
win-x64
win-x86

Can it be easily fixed?

[amaitland]

It turns out the latest version of chromiumembeddedframework.runtime package does contain win-arm64 runtime, while the latest version of CefSharp.Common.NETCore doesn't:

Correct. You'll need to test with a CI build as stated above.

Can it be easily fixed?

As I have no means of testing a build I'm relying on user feedback. If you can test a CI build and report back. I need at least a couple of people to confirm they're working before publishing a build.

Anyone who is interested in ARM64 support please test and report back.

[kpreisser]

Hi,
I also wanted give an updated feedback from our side: We currently use CefSharp.Common.NETCore 92.0.250-CI4152 with CefSharp.Wpf.HwndHost 91.1.230 in a WPF application (with self-hosted subprocess) that we publish for win7-x64, win7-x86 and win10-arm64, currently using .NET 5.0.9, and have encountered no issues so far regarding CefSharp when testing it on Windows 11 Build 22000 (ARM64). Our application uses only basic browser functionality, but adds some handlers like IDownloadHandler, ILoadHandler , IContextMenuHandler, IJsDialogHandler to the ChromiumWebBrowser.

For specific use cases like running the TypeScript compiler, the performance of the chromium browser in the arm64 version of the app seems to be about 3x as fast as the performance of the x64 version (that runs with emulation) on Windows ARM64.

Thank you!

[ghost]

As I have no means of testing a build I'm relying on user feedback. If you can test a CI build and report back. I need at least a couple of people to confirm they're working before publishing a build.

Anyone who is interested in ARM64 support please test and report back.

Sure, I would be happy to help, but it may take some time because right now we're just planning ARM64 support. I was asking about CEFSharp mainly to just put a checkmark in a list of dependencies 😬 If by the time we get there you'll still be in need of feedback, I'll post it here.

But I suppose you could just go ahead and give it to the public since it doesn't jeopardize other architectures in any way, and then you'll get a load of feedback from real users? Because I suppose we're not the only ones who are planning ARM64 support and seeing that the mainstream CEFSharp doesn't support it yet and consider using MS Edge Runtime instead.

[amaitland]

I also wanted give an updated feedback from our side:

@kpreisser Great, thanks for the feedback 👍

But I suppose you could just go ahead and give it to the public since it doesn't jeopardize other architectures in any way,

@A-Ovchinnikov-mx I would personally like to include ARM64 support in version 93 as it would save me some time as I can finally create the release branch from master which includes ARM64 support.

[amaitland]

Anyone who is interested in ARM64 support and has some time please check out a CI build and report back. Thanks.

[amaitland]

ARM64 has been included in 93.1.110-pre see #3780 (comment) for release details.

Please be aware that I'm relying on community to provide support for ARM64 as I personally don't own an ARM64 device.

[kpreisser]

Hi,

we now discovered an issue when using CefSharp.Wpf.HwndHost in a .NET 5.0 WPF app on Windows ARM64 when using a graphics card with hardware acceleration, and when publishing the app as self-contained application. However, it seems the issue itself is not caused by CEF/CefSharp.

The issue is that when starting the application and loading a URL, sometimes the Chromium Browser just "hangs" (displays a white page), and we can see that the renderer process has high CPU usage. However, it seems to be timing related as the issue doesn't always occur.

When enable logging (with default log level), and the hang issue occurs, the log file shows the following:

CEF logfile contents

[1007/102117.812:WARNING:angle_platform_impl.cc(49)] Debug.cpp:180 (insertMessage): GL error: HIGH: Internal D3D11 error: HRESULT: 0x8007000E: Error finding D3DCompile entry point.
[1007/102117.813:ERROR:shared_context_state.cc(73)] Skia shader compilation error
------------------------
// Vertex SKSL
uniform float4 sk_RTAdjust;in float2 position;in half4 color;out half4 vcolor_Stage0;void main() {// Primitive Processor QuadPerEdgeAAGeometryProcessor
vcolor_Stage0 = color;sk_Position = position.xy01;}
// Fragment SKSL
in half4 vcolor_Stage0;void main() {// Stage 0, QuadPerEdgeAAGeometryProcessor
half4 outputColor_Stage0;outputColor_Stage0 = vcolor_Stage0;const half4 outputCoverage_Stage0 = half4(1);{ // Xfer Processor: Porter Duff
sk_FragColor = outputColor_Stage0 * outputCoverage_Stage0;}}
// Vertex GLSL
#version 100

precision mediump float;
precision mediump sampler2D;
uniform highp vec4 sk_RTAdjust;
attribute highp vec2 position;
attribute mediump vec4 color;
varying mediump vec4 vcolor_Stage0;
void main() {
    vcolor_Stage0 = color;
    gl_Position = vec4(position, 0.0, 1.0);
    gl_Position = vec4(gl_Position.xy * sk_RTAdjust.xz + gl_Position.ww * sk_RTAdjust.yw, 0.0, gl_Position.w);
}

// Fragment GLSL
#version 100

precision mediump float;
precision mediump sampler2D;
varying mediump vec4 vcolor_Stage0;
void main() {
    mediump vec4 outputColor_Stage0;
    outputColor_Stage0 = vcolor_Stage0;
    {
        gl_FragColor = outputColor_Stage0;
    }
}


Errors:

[1007/102117.817:ERROR:shared_context_state.cc(797)] SharedContextState context lost via Skia OOM.
[1007/102117.817:ERROR:gpu_service_impl.cc(945)] Exiting GPU process because some drivers can't recover from errors. GPU process will restart shortly.
[1007/102117.860:ERROR:gpu_process_host.cc(956)] GPU process exited unexpectedly: exit_code=34
[1007/102117.860:WARNING:gpu_process_host.cc(1269)] The GPU process has crashed 1 time(s)
[1007/102118.018:WARNING:gpu_process_host.cc(984)] Reinitialized the GPU process after a crash. The reported initialization time was 15 ms
[1007/102118.080:WARNING:angle_platform_impl.cc(49)] Debug.cpp:180 (insertMessage): GL error: HIGH: Internal D3D11 error: HRESULT: 0x8007000E: Error finding D3DCompile entry point.
[1007/102118.080:ERROR:shared_context_state.cc(73)] Skia shader compilation error
------------------------
// Vertex SKSL
uniform float4 sk_RTAdjust;in float2 position;in half4 color;out half4 vcolor_Stage0;void main() {// Primitive Processor QuadPerEdgeAAGeometryProcessor
vcolor_Stage0 = color;sk_Position = position.xy01;}
// Fragment SKSL
in half4 vcolor_Stage0;void main() {// Stage 0, QuadPerEdgeAAGeometryProcessor
half4 outputColor_Stage0;outputColor_Stage0 = vcolor_Stage0;const half4 outputCoverage_Stage0 = half4(1);{ // Xfer Processor: Porter Duff
sk_FragColor = outputColor_Stage0 * outputCoverage_Stage0;}}
// Vertex GLSL
#version 100

precision mediump float;
precision mediump sampler2D;
uniform highp vec4 sk_RTAdjust;
attribute highp vec2 position;
attribute mediump vec4 color;
varying mediump vec4 vcolor_Stage0;
void main() {
    vcolor_Stage0 = color;
    gl_Position = vec4(position, 0.0, 1.0);
    gl_Position = vec4(gl_Position.xy * sk_RTAdjust.xz + gl_Position.ww * sk_RTAdjust.yw, 0.0, gl_Position.w);
}

// Fragment GLSL
#version 100

precision mediump float;
precision mediump sampler2D;
varying mediump vec4 vcolor_Stage0;
void main() {
    mediump vec4 outputColor_Stage0;
    outputColor_Stage0 = vcolor_Stage0;
    {
        gl_FragColor = outputColor_Stage0;
    }
}


Errors:

[1007/102118.094:ERROR:shared_context_state.cc(797)] SharedContextState context lost via Skia OOM.
[1007/102118.094:ERROR:gpu_service_impl.cc(945)] Exiting GPU process because some drivers can't recover from errors. GPU process will restart shortly.
[1007/102118.104:ERROR:gpu_process_host.cc(956)] GPU process exited unexpectedly: exit_code=34
[1007/102118.104:WARNING:gpu_process_host.cc(1269)] The GPU process has crashed 2 time(s)
[1007/102118.229:WARNING:gpu_process_host.cc(984)] Reinitialized the GPU process after a crash. The reported initialization time was 14 ms
[1007/102118.235:WARNING:angle_platform_impl.cc(49)] Debug.cpp:180 (insertMessage): GL error: HIGH: Internal D3D11 error: HRESULT: 0x8007000E: Error finding D3DCompile entry point.
[1007/102118.236:ERROR:shared_context_state.cc(73)] Skia shader compilation error
------------------------
// Vertex SKSL
uniform float4 sk_RTAdjust;in float2 position;in half4 color;out half4 vcolor_Stage0;void main() {// Primitive Processor QuadPerEdgeAAGeometryProcessor
vcolor_Stage0 = color;sk_Position = position.xy01;}
// Fragment SKSL
in half4 vcolor_Stage0;void main() {// Stage 0, QuadPerEdgeAAGeometryProcessor
half4 outputColor_Stage0;outputColor_Stage0 = vcolor_Stage0;const half4 outputCoverage_Stage0 = half4(1);{ // Xfer Processor: Porter Duff
sk_FragColor = outputColor_Stage0 * outputCoverage_Stage0;}}
// Vertex GLSL
#version 100

precision mediump float;
precision mediump sampler2D;
uniform highp vec4 sk_RTAdjust;
attribute highp vec2 position;
attribute mediump vec4 color;
varying mediump vec4 vcolor_Stage0;
void main() {
    vcolor_Stage0 = color;
    gl_Position = vec4(position, 0.0, 1.0);
    gl_Position = vec4(gl_Position.xy * sk_RTAdjust.xz + gl_Position.ww * sk_RTAdjust.yw, 0.0, gl_Position.w);
}

// Fragment GLSL
#version 100

precision mediump float;
precision mediump sampler2D;
varying mediump vec4 vcolor_Stage0;
void main() {
    mediump vec4 outputColor_Stage0;
    outputColor_Stage0 = vcolor_Stage0;
    {
        gl_FragColor = outputColor_Stage0;
    }
}


Errors:

[1007/102118.237:ERROR:shared_context_state.cc(797)] SharedContextState context lost via Skia OOM.
[1007/102118.237:ERROR:gpu_service_impl.cc(945)] Exiting GPU process because some drivers can't recover from errors. GPU process will restart shortly.
[1007/102118.259:ERROR:gpu_process_host.cc(956)] GPU process exited unexpectedly: exit_code=34
[1007/102118.259:WARNING:gpu_process_host.cc(1269)] The GPU process has crashed 3 time(s)
[1007/102118.387:ERROR:angle_platform_impl.cc(44)] Display.cpp:878 (initialize): ANGLE Display::initialize error 0: Internal Vulkan error (-3): Initialization of an object could not be completed for implementation-specific reasons, in ../../third_party/angle/src/libANGLE/renderer/vulkan/RendererVk.cpp, initialize:845.
[1007/102118.387:ERROR:gl_surface_egl.cc(780)] EGL Driver message (Critical) eglInitialize: Internal Vulkan error (-3): Initialization of an object could not be completed for implementation-specific reasons, in ../../third_party/angle/src/libANGLE/renderer/vulkan/RendererVk.cpp, initialize:845.
[1007/102118.387:ERROR:gl_surface_egl.cc(1375)] eglInitialize SwANGLE failed with error EGL_NOT_INITIALIZED
[1007/102118.387:ERROR:gl_initializer_win.cc(141)] GLSurfaceEGL::InitializeOneOff failed.
[1007/102118.388:ERROR:viz_main_impl.cc(161)] Exiting GPU process due to errors during initialization
[1007/102118.502:ERROR:gpu_init.cc(453)] Passthrough is not supported, GL is disabled, ANGLE is 
[1007/102118.504:WARNING:gpu_process_host.cc(984)] Reinitialized the GPU process after a crash. The reported initialization time was 0 ms

Notice the error about the missing D3DCompile entry point, which I think refers to the D3DCompiler_47.dll file. This file is not present in the Windows 10/11 SDK for arm64 (so it isn't included in the CEF redist for win-arm64), but is present in the system32 directory on Windows ARM64. However, when publishing a WPF application in .NET 5, it seems the .NET SDK also copies a D3DCompiler_47.dll file in the application's directory which is nearly empty (only 26.3 KB instead of a few MB) and doesn't seem to have any function exports (the file is contained in the Microsoft.WindowsDesktop.App.Runtime.win-arm64 package).

When I delete this small D3DCompiler_47.dll file from the app directory and remove the corresponding entry in app.deps.json, the application works without problems and the browser no longer hangs.

Note that when publishing a WPF app for x64/x86, there is no D3DCompiler_47.dll file copied to the app directory; instead, it deploys a D3DCompiler_47_cor3.dll file with similar size and exports as the regular file. For ARM64 however, there is no D3DCompiler_47_cor3.dll file deployed, but the small D3DCompiler_47.dll file.

[ghost]

Hi @kpreisser ,

Thank you very much for the report! I'm not a maintainer of CefSharp but it will help us tremendously with this issue in the future 👍

I have a request, could you please post this issue in https://github.com/dotnet/wpf repo? I believe Microsoft should look into the D3DCompiler_47.dll issue.

Thanks!

[kpreisser]

Hi @A-Ovchinnikov-mx,
thanks for your reply!

I have reported this issue about D3DCompiler_47.dll in dotnet/wpf#5462.

[kpreisser]

Additionally, I think we need to change DependencyChecker to not check for D3DCompiler_47.dll for win-arm64 (as it's not included in chromiumembeddedframework.runtime.win-arm64):

CefSharp/CefSharp/DependencyChecker.cs

Lines 57 to 66 in 15cf58c

	public static string[] CefOptionalDependencies =
	{
	// Angle and Direct3D support
	// Note: Without these components HTML5 accelerated content like 2D canvas, 3D CSS and WebGL will not function.
	"libEGL.dll",
	"libGLESv2.dll",
	"d3dcompiler_47.dll",
	//Crashpad support
	"chrome_elf.dll"
	};

Currently, it always checks for the presence of D3DCompiler_47.dll. This works currently due to the stub DLL deployed by the .NET SDK, but once this is fixed and that file is no longer copied, the dependency check would fail when running on ARM64.

[kpreisser]

I have reported this issue about D3DCompiler_47.dll in dotnet/wpf#5462.

Just a follow-up: The fix for this issue has been backported to .NET 6.0 and is expected to be included in the June 2022 release (6.0.6).