-
Notifications
You must be signed in to change notification settings - Fork 5.2k
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
[Feature Request] Build Telegram for ARM64EC target for Windows 64-bit #25266
Comments
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.
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 |
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. |
Yes please, definitely need this. |
Is that a blocker for Telegram Desktop? |
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? |
@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
There are no official binaries yet and I don't think this project wants to built Qt itself. |
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 :( |
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.
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. 😅 |
In light of all the new windows ARM hardware released with the snapdragon chips, I would love to see a native version of telegram. |
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. |
As an active Windows ARM + Telegram user, I prefer the web version because ARM experience of Telegram in WIndows is awful:
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 |
@Aokromes, What's the minimum number of people affected to address an issue? |
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. |
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. |
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. |
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. |
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. |
@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 |
@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? 😄 |
@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. |
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). |
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. |
I don't want another distinct hardware, I really do hope Apple Silicon would do. I already need it for macOS builds. |
@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. |
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). |
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. |
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. |
@lexcyn That QT fix seems to have been merged. |
[Edit] I'm wrong, you are right, the changes haven't been merged yet |
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 :) |
Because you still build from the same Qt version where the bug is not fixed? |
You would need something like that to get it applied
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 |
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! |
Can anyone confirm that the right architecture is reported under emulation in system version (sessions list) on 5.5.7? |
no one? |
Wow, nice, so we can measure the amount of arm64 users now |
Your arm64 build has arm64 in application string, right? |
By the way, 5.6 now includes various Qt 6 network plugins on Windows, Qt 6.8.0-rc1 and the media viewer fixes. So the only remaining blockers should be the compiler bug and determining what to do with OpenGL. |
That's great to hear. I have a case open with Microsoft regarding the compile bug as well, they are claiming a fix is coming soon. |
Just received my Surface Laptop and am curious about aarch64 support of Telegram. I see some people manage to compile some versions. Could somebody summarize the current state of the issues now? Thanks |
There's an issue with the compiler right now that Microsoft is trying to fix so while you can compile the dependencies etc the final compile won't work if you use the release build. If you try a debug build there are some odd QT debug errors as well but I haven't attempted this in a while. Last build I was able to successfully compile and use was 5.4.4 with QT 5.8 (which is what I am still using now) |
I just started to compile dependencies. Could you share somehow your working build? Many thanks |
It's a debug build using my personal API key so I can't share it sorry! |
Good news all! The debug errors I was getting are gone and I was able to compile the latest version in debug mode. Sadly the same compile error is still present trying to compile release. @ilya-fedin [Edit] Compile issue has been fixed! Will be included in next update: https://developercommunity.visualstudio.com/t/Encountered-ICE-While-Building-Telegram-/10718860 |
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
The text was updated successfully, but these errors were encountered: