[Feature Request] Build Telegram for ARM64EC target for Windows 64-bit

[ssg]

Is your feature request related to a problem?

Telegram runs under x64 emulation on Windows ARM devices, that causes a performance penalty especially with the CPU intensive tasks like video/GIFs, etc.

Creating a new ARM64 build might be costly, but Windows applications can be compiled for ARM64EC target which is essentially x64 but with ability to directly translate to ARM so it can be transpiled to the native code on ARM platforms.

Here are the details: https://devblogs.microsoft.com/cppblog/arm64ec-support-in-visual-studio/

Describe the solution you'd like

ARM64EC enabled x64 binaries for Telegram.

Describe alternatives you've considered

I considered suffering through performance problems, I didn't like it.

Additional context

No response

[sungaila]

Telegram cannot be ported to ARM64 just yet because some third-party dependencies are not ready (e.g. Qt ARM64 builds are still in tech preview). But ARM64EC might be a good compromise for now: Telegram runs natively and everything else stays x64.

Also porting can be done iteratively: replace the x64 dependencies with ARM64 builds step by step. Once all third-party dependencies are updated, just change the build target from ARM64EC to ARM64.

Edit: Forget the last part. The Microsoft docs state that ARM64EC can load x64 and ARM64EC binaries but they cannot load ARM64 binaries.

[NicolasOchoaMSFT]

Telegram cannot be ported to ARM64 just yet because some third-party dependencies are not ready (e.g. Qt ARM64 builds are still in tech preview). But ARM64EC might be a good compromise for now: Telegram runs natively and everything else stays x64.

Also porting can be done iteratively: replace the x64 dependencies with ARM64 builds step by step. Once all third-party dependencies are updated, just change the build target from ARM64EC to ARM64.

Edit: Forget the last part. The Microsoft docs state that ARM64EC can load x64 and ARM64EC binaries but they cannot load ARM64 binaries.

Hey Team,

​​​​​​​My name is Nicolas Ochoa, and I am an App Assure Manager with Microsoft's FastTrack Center. My team assists Microsoft customers and Independent Software Vendors (ISVs) with any application or software compatibility scenarios encountered while upgrading to our latest versions of Microsoft products.

We would like to work with Telegram to prepare your applications for Windows on Arm.

The App Assure team supports application compatibility for Windows 10, Windows 11, and Windows on Arm with an emphasis on collaborating with ISVs. Our goal is to help ensure your Telegram application is supported on Windows 11 and Windows on Arm. Our App Assure engineers can provide you with best practice guidelines and help remove any technical blockers encountered when developing compatible applications. These services are provided at no additional cost.

Feel free to reach out to me by replying to this thread

[ChrisOfTheLewi]

Arm64EC supports ARM64 code, but not ARM64 binaries. It works very well for partial ports in conjunction with a good linking strategy (the arm64 codebase in ARM64 and Arm64EC can be the same code essentially and ultimately you can produce Arm64X if needed to support both types from a single binary should you have any dlls which need to be able to load in both types of processes). Arm64EC is usually where I'd suggest open source projects with lots of dependencies start looking; you can get pretty great performance without having to recompile everything into Arm64.

[khmyznikov]

Yes please, definitely need this.

[ssg]

Arm64EC supports ARM64 code, but not ARM64 binaries

Is that a blocker for Telegram Desktop?

[CryptoManiac]

Telegram cannot be ported to ARM64 just yet because some third-party dependencies are not ready (e.g. Qt ARM64 builds are still in tech preview). But ARM64EC might be a good compromise for now: Telegram runs natively and everything else stays x64.

There was a need to patch few qmake files but nothing significant and overall the Qt builds for windows arm64 and works without any issues. Both with LLVM-Mingw64 and MSVC, the full source tree including the IDE, no problem at all. Though I checked it more than two years ago, I believe they didn't break it so far.

P.S. For an open source project, when the dependency sources are available, depending on the prebuilt libraries seems quite weird for me. Aren't you guys supposed to have at least some good and healthy paranoia when it comes to dealing with the 3rd the party blobs?

[sungaila]

@CryptoManiac Currently the Qt arm64 builds are considered stable but the tooling isn't there yet. See https://www.qt.io/blog/qt-for-windows-on-arm

Qt basically works natively on Windows on ARM. It is usable to build and run native Qt applications for your ARM64 devices but you will have to build Qt yourself. We, the Qt Company, still have some work to do to make the developer experience come up to par with the rest of our offering though.

There are no official binaries yet and I don't think this project wants to built Qt itself.

[john-preston]

Well, really this project (if you're talking about TDesktop) builds (and patches) Qt itself on all platforms for ten years now. But I'm not sure about ARM build of all other dependencies, Qt is just one, on Windows there are 28 steps in dependencies-building script. Right now I don't have time to check/port building all of them to ARM and then building one more version for each release :(

[sungaila]

But I'm not sure about ARM build of all other dependencies

I mean, that is the point of ARM64EC: use this target for the core of TDesktop and the (third-party) dependencies can stay x86-64. Then migrate the rest iteratively one step at a time.

Right now I don't have time to check/port building all of them to ARM and then building one more version for each release :(

I would help out if I had any C++ building experience. I'm still hoping someone else will be interested in giving it a shot. 😅

[nycevan]

In light of all the new windows ARM hardware released with the snapdragon chips, I would love to see a native version of telegram.

[Aokromes]

i am sure windows arm users is far lower than linux arm users wicth is far lower than linux x86 users and preston have far higher priorities, when windows arm can run windows x86_64 binaries.

[grandrew]

As an active Windows ARM + Telegram user, I prefer the web version because ARM experience of Telegram in WIndows is awful:

1. The UI elements are painfully slow. While app and calling technically does work, pressing every button is about a 5-second delay. And you have to press 3 buttons to make a call
2. It requires 500+ MB of RAM to just sit there while web version is less than 300. Calling on web version of telegram does not work on Edge/ARM. I believe x86 version of telegram is less than 100MB
3. Launching telegram is also about a 5-sec delay and depends on luck

On the overall Windows/ARM projections I believe this will get a lot of traction because it works at least as stable as x86 with more than acceptable performance and provides unbeatable benefits in battery, 5G connectivity, temperature and noise

[ssg]

i am sure windows arm users is far lower than linux arm users wicth is far lower than linux x86 users and preston have far higher priorities, when windows arm can run windows x86_64 binaries.

@Aokromes, What's the minimum number of people affected to address an issue?

[CryptoManiac]

While the native WoA build is unavailable, you could use Android version. It works fine with Windows Subsystem for Android. It's an ugly crutch of course, but Android version is far more usable than Windows x86_64 version. If anything, you'll be able to make calls without spending five minutes on establishing the connection. Hope it helps. An alternative is to use Linux version with WSLg.

[CryptoManiac]

i am sure windows arm users is far lower than linux arm users wicth is far lower than linux x86 users and preston have far higher priorities, when windows arm can run windows x86_64 binaries.

It works fine as long as you won't try to make a voice or video call. Something is severely broken in the cryptographic keys negotiation code. Broken so much that I have enough time to make a tea before the connection will be established. Win 11 on Qualcomm Snapdragon 8cx Gen 3 with 16 Gb of RAM. It looks like this particular code is dependent on the instruction(s) which are very hard to emulate, resulting with the ridiculously high emulation penalties. I guess this can be worked around by invoking the unoptimized code for this particular use case but this will require modifications. The application will need to be able to detect that it's running under the emulation and use the plain C version of that function in such a case, then it will be somewhat tolerable.

[ssg]

It works fine as long as you won't try to make a voice or video call.

Nope, autoplay GIFs and videos are problematic too. Telegram is still the top battery consumer on my Surface Laptop 7 without making a voice or video call.

[CryptoManiac]

It works fine as long as you won't try to make a voice or video call.

Nope, autoplay GIFs and videos are problematic too. Telegram is still the top battery consumer on my Surface Laptop 7 without making a voice or video call.

Didn't notice any trouble with them. Works fine for me. Battery consumption is another matter, though.

[ssg]

Didn't notice any trouble with them.

Yeah, GIFs and videos play smooth, but they consume a lot of power due to emulation running behind the scenes. That's what I meant as problematic.

[sungaila]

I have a Samsung Galaxy Book S (Snapdragon 8cx) and can't confirm any of the mentioned performance issues. Are you sure that you are running the x64 build (NOT x86)?

The battery usage is very poor though judging by the Windows logs.

[john-preston]

@ssg Well, from Unigram statistics the ratio of x64 users to arm users is 16'945, meaning there is almost 17'000 people using x64 version on every person using arm version, or arm userbase is ~0.006%

Given that I've EOLed support for systems under 1% of userbase when the time came it's really hard to justify spending big amount of time (working week? idk) to support native arm version for 0.006% of userbase.

BTW for me this percent would be even less, because Unigram works only on modern systems, while I still have relatively big percent of users on Windows 7 (more than 4% of userbase).

idk.. I'm open for the thing, but it is really hard to make (and support, and build every release) a native arm version and really low part of userbase

[sungaila]

@john-preston You would have to copy the Windows x64 pipeline, change the build target to Arm64EC and leave everything else (like x64 dependencies) as is. So that's 1-2 days max? But without proper hardware or VMs there is just no way to test it yourself.

Maybe Microsoft (@NicolasOchoaMSFT) would be willing to send you a Windows Dev Kit 2023? 😄

[john-preston]

@sungaila I'm not sure building tdesktop code Arm native and leaving dependencies x64 (like OpenSSL / FFmpeg / WebRTC) will do any good in terms of performance, I doubt that tdesktop code is the main problem here. It looks like a fully native build is needed for all this to make sense.

[john-preston]

I hope I'll be able to use Mac hardware for Windows on Arm development, that way I still need only two hardware sets to build all of supported tdesktop versions (Mac on Apple Silicon builds both x64 and Arm macOS versions, Windows on x64 builds Windows x86, Windows x64 and Linux x64 versions).

[CryptoManiac]

@john-preston You would have to copy the Windows x64 pipeline, change the build target to Arm64EC and leave everything else (like x64 dependencies) as is. So that's 1-2 days max? But without proper hardware or VMs there is just no way to test it yourself.

Maybe Microsoft (@NicolasOchoaMSFT) would be willing to send you a Windows Dev Kit 2023? 😄

Raspberry Pi will do. There is no need for expensive hardware to run these binaries. It's painfully slow however. One might even say that forcing someone to use windows on Raspberry Pi should be classified as a war crime.

[john-preston]

I don't want another distinct hardware, I really do hope Apple Silicon would do. I already need it for macOS builds.

[sungaila]

@john-preston You could be right, I too doubt that tdesktop is the bottleneck here.

For development you can run Windows 11 on ARM via virtualization on your Mac (e.g. https://kb.parallels.com/en/125375).

Windows cross-compiles to x86, x64, arm64 and arm64ec on each platform. You'd need Windows on ARM to test the binaries but not for compiling.

[lexcyn]

• Add QTDIR into your environment variables (PATH) with the following location: builddir\TGRAM\Libraries\Qt-6.7.2

This shouldn't be needed

It shouldn't but for whatever reason my build would just not detect QT unless I did this

[ilya-fedin]

Try now again. I'm pretty sure that's a mis-observation and setting it will lead to problems in future (e.g. when the Qt version changes).

[lexcyn]

Try now again. I'm pretty sure that's a mis-observation and setting it will lead to problems in future (e.g. when the Qt version changes).

I'll give it a go and yes this is just what I did to get it working and should probably not be kept this way. I will edit my post if it works after removing it.

[Edit] Looks like it worked - I think the key was getting that arch set properly in cmake

[ssg]

Great news! What's the next step to make it official?

[ilya-fedin]

@lexcyn can you try CMAKE_SYSTEM_PROCESSOR MATCHES "ARM"? I had a private talk with @john-preston and he wants it to be like that but it seems he has no time to try whether it works, so if you would confirm it works, I'd make a PR with the change (or you can make it if you want).

[ilya-fedin]

Great news! What's the next step to make it official?

There seem to be various major bugs in the build (e.g. broken media viewer) and it seems @john-preston has little time to work on that so this could take quite a lot time apparently. They seem to be mostly related to Qt 6 port rather than ARM build though but ARM build depends on Qt 6 port.

[ilya-fedin]

I even have a fix for the media viewer bug but @john-preston seem to have no time to review it.

[lexcyn]

Great news! What's the next step to make it official?

There seem to be various major bugs in the build (e.g. broken media viewer) and it seems @john-preston has little time to work on that so this could take quite a lot time apparently. They seem to be mostly related to Qt 6 port rather than ARM build though but ARM build depends on Qt 6 port.

Strange, I am still using 5.4.4 (which was on QT 6.7.2) and nothing is broken, it all works very well even the media viewer. But yes on the newer builds with QT 6+, the GUI feels laggy and it does crash on UI scaling (could be other crashes too, I will see if I can find any)

Also I did try CMAKE_SYSTEM_PROCESSOR MATCHES "ARM" and it did work!

[ilya-fedin]

Strange, I am still using 5.4.4 (which was on QT 6.7.2) and nothing is broken

is it transparent like in the qt 5 version? don't you have bugs resizing it if disabling opengl? (although the latter seem to be reproducible on qt5 too)

Also I did try CMAKE_SYSTEM_PROCESSOR MATCHES "ARM" and it did work!

Nice!

[ilya-fedin]

There's also a question what to do about OpenGL. OpenGL drivers are of very bad quality at mass level on Windows and it seems @john-preston doesn't want to release a stable version using it. Given that Qt 6 no more supports ANGLE (which translates OpenGL into D3D11 or D3D9), alternative solution is needed.

Here are the options I'm aware about:

1. The most obvious solution is to rewrite OpenGL code to the new Qt's RHI but that would require LOTS of time.
2. There are Krita's WIP patches for Qt 6 to bring ANGLE back but @john-preston ignored when I sent him the link so I have no idea what he thinks about that.
3. There's GLonD3D12 in mesa which talks WGL (which Qt uses!) but @john-preston says he wants to support D3D11+ at least.

[ilya-fedin]

@lexcyn I see your desktop-app/cmake_helpers#360, will you update it?

[lexcyn]

@lexcyn I see your desktop-app/cmake_helpers#360, will you update it?

Yes I will do that now!

[lexcyn]

Strange, I am still using 5.4.4 (which was on QT 6.7.2) and nothing is broken

is it transparent like in the qt 5 version? don't you have bugs resizing it if disabling opengl? (although the latter seem to be reproducible on qt5 too)

Also I did try CMAKE_SYSTEM_PROCESSOR MATCHES "ARM" and it did work!

Nice!

Yes the background is transparent and resizing it does work in OpenGL mode and with OpenGL disabled.

[ilya-fedin]

Yes the background is transparent and resizing it does work in OpenGL mode and with OpenGL disabled.

Ah, maybe this happens only with x86/x64... But anyway this has to be resolved for Windows Qt 6 port to happen.

[sungaila]

Yes the background is transparent and resizing it does work in OpenGL mode and with OpenGL disabled.

I am wondering on which ARM hardware you have tested OpenGL. I got the older Snapdragon 8cx here and need the OpenCL™, OpenGL®, and Vulkan® Compatibility Pack for that.

No idea about the newer Snapdragons (Copilot+PC) or Macs on virtualization though.

[ilya-fedin]

The effective state of the OpenGL could be seen in the log.txt. Or by trying to zoom the picture in the viewer (only OpenGL-based code has the animation).

[lexcyn]

Yes the background is transparent and resizing it does work in OpenGL mode and with OpenGL disabled.

Ah, maybe this happens only with x86/x64... But anyway this has to be resolved for Windows Qt 6 port to happen.

QT bug is being worked on now, I am going to test the code change listed here: https://codereview.qt-project.org/c/qt/qtbase/+/589214

[Edit] while it continues past that point, I get another breakpoint referencing the 'v_top' variable but this time in qrunnable.h (line 73) so I will have to submit another bug report to QT.

[lexcyn]

Strange - unsure if this is an issue with QT or now with the app. Adjusting the UI scale "up/increase" gives a the v_top break at line 73 of qrunnable.h and adjusting it "down/smaller" gives a v_top break at line 4160 of qpaintengine_raster.cpp.

[ssg]

@lexcyn That QT fix seems to have been merged.

[lexcyn]

@lexcyn That QT fix seems to have been merged.

[Edit] I'm wrong, you are right, the changes haven't been merged yet

[ilya-fedin]

But those are the same variables the previously linked fix changes. I.e. you reported the same thing second time.

[lexcyn]

But those are the same variables the previously linked fix changes. I.e. you reported the same thing second time.

But those are the same variables the previously linked fix changes. I.e. you reported the same thing second time.

Yes but it seems like it was not fully fixed. I had recreated my build environment and recompiled from scratch and still getting errors with those variables. At least now however I am getting warnings during the QT initial build and then breakpoints during GUI interactions after full Telegram compile (GUI scaling) with that same variable. I'm just basing that bug report on the results I'm seeing. I am not an expert in this by far so if I am way off base let me know :)

[ilya-fedin]

I had recreated my build environment and recompiled from scratch and still getting errors with those variables.

Because you still build from the same Qt version where the bug is not fixed?

[ilya-fedin]

You would need something like that to get it applied

diff --git a/Telegram/build/prepare/prepare.py b/Telegram/build/prepare/prepare.py
index b05f65cded..c052ea2a7b 100644
--- a/Telegram/build/prepare/prepare.py
+++ b/Telegram/build/prepare/prepare.py
@@ -1667,6 +1667,7 @@ mac:
     ninja
     ninja install
 win:
+    git cherry-pick 998bffecc25dd735175d296303d18ed0df1f9651
     for /r %%i in (..\\..\\patches\\qtbase_%QT%\\*) do git apply %%i -v
     cd ..
 

But that's a pedantic warning rather than a real bug so you could just as well build tdesktop in release mode. It won't do those annoying runtime warnings and should work a lot faster.

[lexcyn]

You would need something like that to get it applied

diff --git a/Telegram/build/prepare/prepare.py b/Telegram/build/prepare/prepare.py
index b05f65cded..c052ea2a7b 100644
--- a/Telegram/build/prepare/prepare.py
+++ b/Telegram/build/prepare/prepare.py
@@ -1667,6 +1667,7 @@ mac:
     ninja
     ninja install
 win:
+    git cherry-pick 998bffecc25dd735175d296303d18ed0df1f9651
     for /r %%i in (..\\..\\patches\\qtbase_%QT%\\*) do git apply %%i -v
     cd ..
 

But that's a pedantic warning rather than a real bug so you could just as well build tdesktop in release mode. It won't do those annoying runtime warnings and should work a lot faster.

Dang you are right, I'm dumb - I will try and see if it works, I know the last time I tried a release build it failed to compile.

[Edit] Seems like the emoji_sets_manager.cpp is throwing an internal compile error on line 452 - tried using github copilot to correct but could just be something with the MSVC ARM compiler

[lexcyn]

Looks like it's an issue with the compiler and Microsoft is working on a fix. https://developercommunity.visualstudio.com/t/Encountered-ICE-While-Building-Telegram-/10718860

[sungaila]

Looks like it's an issue with the compiler and Microsoft is working on a fix. https://developercommunity.visualstudio.com/t/Encountered-ICE-While-Building-Telegram-/10718860

This could be one of the problems that John has already reported.

[lexcyn]

Looks like it's an issue with the compiler and Microsoft is working on a fix. https://developercommunity.visualstudio.com/t/Encountered-ICE-While-Building-Telegram-/10718860

This could be one of the problems that John has already reported.

Great, hopefully it gets fixed soon!

[ilya-fedin]

Can anyone confirm that the right architecture is reported under emulation in system version (sessions list) on 5.5.7?