Repository navigation
Feature Request - ARM64 support #2944
Description
Activity
See also dotnet/winforms#2053 and dotnet/wpf#1817 for the progress of Windows ARM64 support in .NET Core, including WinForms and WPF.
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
CEFsupport (probablyChomiumin general) for buildingWin ARM64is still in it's early stages. - I'm not sure
Chromehas actually released an official version, so it's likely too early to look at from a stability point of view.
Someone else is welcome to take responsibility for adding and supporting
Win ARM64. An ongoing commitment would be required.Official Windows ARM64 builds starting with M88 will be available shortly from https://cef-builds.spotifycdn.com/index.html#windowsarm64.
This is blocked on the linker errors when attempting to compiler
CefSharp.Core.Runtimetargeting.Net 5.0(required forARM64). 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 errorsThe
CefSharp.BrowserSubprocess.Coreproject 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 withNet 5 Team.Reacted by Weipeng LIUFor 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.libCurrently https://github.com/cefsharp/cef-binary/blob/master/build.ps1 downloads, builds and packages the
x86/x64versions, it should be possible (haven't tried obviously) to extend this to download, build and package thearm64target binaries.Reacted by Konstantin Preißer and Weipeng LIU- added a commit that references this issue
on Jan 14, 2021 - added a commit that references this issue
on Jan 15, 2021 This is blocked on the linker errors when attempting to compiler
CefSharp.Core.Runtimetargeting.Net 5.0(required forARM64). As reported in #3284 (comment) which I've confirmed as being a problem.Note that switching to
net5.0might not actually be necessary for supportingarm64in CefSharp. Withcef.sdk 88.1.2that includes the ARM64 versions oflibcef.libandlibcef_dll_wrapper.lib(from cefsharp/cef-binary#90), I was able to successfully compileCefSharp.Core.RuntimeandCefSharp.BrowseSubprocess.Coreafter addingarm64as platform target, and confirmed withdumpbin.exe /headersthat 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-arm64with .NET 5.0 and running it on a Windows 10 on ARM machine actually works (WPF is not yet supported forwin-arm64).Reacted by Media Explorer11 remaining items
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
ARM64support in version93as it would save me some time as I can finally create thereleasebranch frommasterwhich includesARM64support.Anyone who is interested in
ARM64support and has some time please check out aCIbuild and report back. Thanks.ARM64has been included in93.1.110-presee #3780 (comment) for release details.Please be aware that I'm relying on community to provide support for
ARM64as I personally don't own anARM64device.Reacted by Konstantin PreißerReacted by Alovchin91Hi,
we now discovered an issue when using
CefSharp.Wpf.HwndHostin 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 msNotice the error about the missing
D3DCompileentry point, which I think refers to theD3DCompiler_47.dllfile. This file is not present in the Windows 10/11 SDK forarm64(so it isn't included in the CEF redist for win-arm64), but is present in thesystem32directory on Windows ARM64. However, when publishing a WPF application in .NET 5, it seems the .NET SDK also copies aD3DCompiler_47.dllfile 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 theMicrosoft.WindowsDesktop.App.Runtime.win-arm64package).When I delete this small
D3DCompiler_47.dllfile from the app directory and remove the corresponding entry inapp.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 noD3DCompiler_47.dllfile copied to the app directory; instead, it deploys aD3DCompiler_47_cor3.dllfile with similar size and exports as the regular file. ForARM64however, there is noD3DCompiler_47_cor3.dllfile deployed, but the smallD3DCompiler_47.dllfile.Hi @A-Ovchinnikov-mx,
thanks for your reply!I have reported this issue about
D3DCompiler_47.dllin dotnet/wpf#5462.Additionally, I think we need to change
DependencyCheckerto not check forD3DCompiler_47.dllforwin-arm64(as it's not included inchromiumembeddedframework.runtime.win-arm64):
CefSharp/CefSharp/DependencyChecker.cs
Lines 57 to 66 in 15cf58c
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 onARM64.- added a commit that references this issue
on Oct 10, 2021 - added a commit that references this issue
on Oct 15, 2021 I have reported this issue about
D3DCompiler_47.dllin 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).
Reacted by Alex Maitland
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.