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

Add support for Windows ARM64 #140

Draft
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

tommyvct
Copy link
Contributor

@tommyvct tommyvct commented Oct 29, 2022

Description

Add support for Windows ARM64

Motivation and Context

Make OBS Studio great on Windows ARM64 devices.

How Has This Been Tested?

Still need further integrated test.

Types of changes

  • New feature (non-breaking change which adds functionality)

Checklist:

  • My code has been run through clang-format.
  • I have read the contributing document.
  • My code is not on the master branch.
  • The code has been tested.
  • All commit messages are properly formatted and commits squashed where appropriate.
  • I have included updates to all appropriate documentation.

@RytoEX RytoEX marked this pull request as draft November 2, 2022 14:54
@tommyvct tommyvct force-pushed the windows-arm64-3 branch 7 times, most recently from 5b99bbe to 74f6051 Compare November 8, 2022 09:35
@tommyvct tommyvct force-pushed the windows-arm64-3 branch 8 times, most recently from 34c822d to dce9750 Compare November 20, 2022 15:32
@tommyvct tommyvct marked this pull request as ready for review November 20, 2022 15:32
@tommyvct tommyvct force-pushed the windows-arm64-3 branch 2 times, most recently from 82f0513 to 6e40a08 Compare November 25, 2022 21:52
@@ -51,6 +51,17 @@ runs:
shell: pwsh
run: ./Build-Dependencies.ps1 -Dependencies "Qt${{ inputs.qtVersion }}" -SkipBuild -SkipUnpack -Target ${{ inputs.target }} -Configuration ${{ inputs.config }} -Shared

- name: Install Qt
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't use third party actions, if you need a host-version of Qt, wait for the associated x64 job to finish, then use that artifact.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

okay.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let us know if that is not feasible as-is - in doubt we can and should amend the current Qt build workflow to generate what this workflow needs. Also I don't think I have seen associated steps in the build scripts ensuring that a host installation of Qt is available to cross compile it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that's possible in theory. I will need to dig a little bit about the CI though.

deps.ffmpeg/20-opus.zsh Outdated Show resolved Hide resolved
deps.ffmpeg/60-srt.zsh Outdated Show resolved Hide resolved
deps.ffmpeg/80-amf.zsh Outdated Show resolved Hide resolved
deps.qt/qt5.ps1 Outdated Show resolved Hide resolved
deps.qt/qt6.ps1 Outdated Show resolved Hide resolved
@pbo-linaro
Copy link

Hi everyone,

at Linaro, we are actively working to help some projects to support Windows on Arm and we would like to help OBS Studio to get ported on this platform.

It seems like a lot of work has been already done (thanks to @tommyvct - nice nickname by the way).
Is there a specific part where we can help? (automate CI for build dependencies, refactor an existing PR, anything else)

Thanks,
Pierrick

@derrod
Copy link
Member

derrod commented May 31, 2023

I believe @PatTheMav has also made some progress with getting OBS to run on Windows on ARM (in a VM on Apple Silicon at least) as part of the build system rework that's currently being finalised, so he'll probably have some more insight on the current status of things. This PR is a bit outdated, and will likely be superseeded.

One major concern I am aware of is the lack of hardware encoding support as this only seems to be available via MediaFoundation. And it would probably be quite important to have given the performance - or rather lack thereof - of pretty much all Windows on ARM machines.

@tommyvct
Copy link
Contributor Author

Is there a specific part where we can help? (automate CI for build dependencies, refactor an existing PR, anything else)

First, thanks for your intention to help, @pbo-linaro !

I was pretty busy working on my degrees in the past 6 months, and after a quick smoke test that I did about a month ago, my previous work fell flat with the current OBS Studio codebase. One of the notable changes that caused the this is the CMake overhaul glued NVENC to the libobs and requires some effort to separate, which the ARM64 build need to get rid of them.

Another major roadblocker, as @derrod said, is the lack of hardware encoding. OBS Studio used to have a Media Foundation encoding backend, but it was removed long ago in favor to vendor-specific solutions like AMF, QSV, and NVENC. The encoding and streaming performance with the version of OBS I compiled before, using software encoding, on a Surface Pro X SQ1, is perfectly usable, even for some light gaming.

Qualcomm chips like 8/7cx series are based on Snapdragon chips for smartphones, which is known to have a hardware encoder. However, after extensive research, I cannot find any usable information about how to utilize the hardware. I did found something remotely close to somewhat useful: there is a PDF document claiming that the encoder supports Windows 8 and some example, indicating the documentation was obsolete. What's worse is the SDK is not easily accessible, at least without contacting and paying a lot of money. I know Linaro is not Qualcomm, and it's gonna be most probably impossible, but can you find us some recent and usable documentation on the Qualcomm hardware encoder? Thanks!

@tommyvct
Copy link
Contributor Author

tommyvct commented May 31, 2023

And for the CI/Automation part, @PatTheMav has full control of this part. I'm simply extending and replicating his work to make OBS Studio work on Windows on ARM.

For the dependencies, LuaJIT is one of the dependencies that need extensive work, and simd-everywhere also needs a lot of work, but it is not deal-breaking.

@pbo-linaro
Copy link

Thanks for your feedback @tommyvct and @derrod.

Good news to hear it's still a work in progress, and that @PatTheMav is on track to enable it.

Concerning the hardware encoding support, I'll contact engineers we work with in Qualcomm, and see what we can do about it.

@PatTheMav
Copy link
Member

If we get around to implement ARM64 on Windows support (which will have to be dependent on whether contributors and volunteer supporters feel comfortable with the added support burden given the still somewhat limited availability of Windows for ARM64), we'd probably base it off the native Windows compilation toolchain for FFmpeg instead of cross-compilation.

In my tests there are the following remaining issues:

  • libvpx fails to compile with MSVC's native toolchain:
    • libvpx\vpx_dsp\arm\fdct4x4_neon.c(55,52): error C2078
  • x264 fails to produce ARM64 assembly by default. The gas-preprocessor perl script used by it are 9 years old and calls cpp to do actual preprocessing (even if cl.exe is used). FFmpeg's fork of the preprocessor fixes this, so the x264's version needs to be replaced with it to build on Windows
  • FFmpeg itself just requires the same gas-preprocessor script to be downloaded and made available in the PATH for the compilation

On top of that I think that MediaFoundation support needs to be enabled again, as I would expect Windows on ARM to be running on SOC-based systems (either Qualcomm-based SOCs, Microsoft's own, or Apple Silicon), so much like VideoToolbox it will be the official way to get hardware acceleration working on Windows.

And as correctly pointed out this will also require the obs-studio Windows build system to require MediaFoundation on ARM64 again and ignore AMF/NVEnc and other x64-specific features.

@pbo-linaro
Copy link

@PatTheMav In previous messages, it was suggested your were working on the rewrite of the build system. Is that the case? If yes, is that close to completion?

I'm trying to understand when it will be possible to contribute to a "stable" state, to avoid redundant/lost work.

@PatTheMav
Copy link
Member

@PatTheMav In previous messages, it was suggested your were working on the rewrite of the build system. Is that the case? If yes, is that close to completion?

I'm trying to understand when it will be possible to contribute to a "stable" state, to avoid redundant/lost work.

That'd be #186.

@tommyvct
Copy link
Contributor Author

tommyvct commented Jun 3, 2023

There's an update from the Qt side: https://www.qt.io/blog/qt-for-windows-on-arm

TL:DR is they have yet to decide whether ARM64 or ARM64EC will be their "native ARM64 architecture".

My previous work was all around the ARM64 ABI. If Qt changed their preferred ABI to ARM64EC, then most of my work (not my research and experience, though) would be in vain.

I did some experiments with the dependencies with the ARM64EC ABI before, and it seems that dependencies that's using anything other than msbuild or CMake, or heavily utilize intrinsics, will have major problems. The ARM64EC toolchain self-identifies the target machine as _M_X64, and the compiler and the linker don't have the same invocation behaviour as the x64 one. All in all, the program we are compiling will have some serious identity crisis, unless they are particularly patched for ARM64EC.

ARM64EC doesn't necessarily mean all trouble and no benefit, though. Say if a plugin like LuaJIT still doesn't have Windows ARM64 support, ARM64EC version of OBS Studio could just use the x64 version of DLL just fine.

In the end of the day, the choice between ARM64 or ARM64EC depends on 1) the usage and expectation from the WoA users and 2) the thoughts from the plugin developers and 3) the Qt company.

I personally would lean towards ARM64, since that what we have on hand that is working(?) for now.

@PatTheMav
Copy link
Member

From our POV the requirements are quite simple:

  • It has to compile when we throw it at MSVC's arm64 compiler

That's all there is to it. We will not cross-compile or use code generated by MINGW toolchains, it has to be compiled with MSVC. This works for almost all dependencies (as I outlined above), libvpx being the only one I wasn't able to figure out a fix for yet.

@tommyvct
Copy link
Contributor Author

tommyvct commented Jun 3, 2023

  • It has to compile when we throw it at MSVC's arm64 compiler

The question I'm talking about is which compiler or toolset we should use, ARM64 or ARM64EC. I would say just stay with ARM64, since we don't have nasty legacies like some old commercial softwares.

Since our user interface is written in Qt, hence the decision of the Qt company is at important stake.

@driver1998
Copy link

driver1998 commented Jun 6, 2023

If OBS supports va-api on Linux, we might be able to get it working on Windows with the new vaOn12 driver (which wraps va-api to DirectX 12). Not sure about how it works on Qualcomm platform though. (DirectX 12 in general is supported here, but not sure about DirectX 12 video).

Media Foundation is also an option.

@driver1998
Copy link

The question I'm talking about is which compiler or toolset we should use, ARM64 or ARM64EC.

I would say ARM64. We are mostly dealing with open source plugins right now, so the benefits of ARM64EC is not very appealing. (We can always port those plugins over, it's not like we haven't dealt with Linux ARM64 or anything).

Also with ARM64 we can use alternative toolchains like MinGW, even though we don't use it for official releases, some plugins might want or require it.

@tommyvct
Copy link
Contributor Author

tommyvct commented Jun 9, 2023

It looks that vaon12 is more promising than the media foundation encoder.

@driver1998
Copy link

driver1998 commented Jun 11, 2023

Looks like vaOn12 is decode only on 8cx Gen 2:

$ vainfo
Trying display: win32
libva info: VA-API version 1.18.0
libva info: User environment variable requested driver 'vaon12'
libva info: Trying to open D:/msys64/clangarm64/bin/\vaon12_drv_video.dll
libva info: Found init function __vaDriverInit_1_18
libva info: va_openDriver() returns 0
D:\msys64\clangarm64\bin\vainfo.exe: VA-API version: 1.18 (libva 2.18.2)
D:\msys64\clangarm64\bin\vainfo.exe: Driver version: Mesa Gallium driver 23.1.2 for D3D12 (Qualcomm(R) Adreno(TM) 680 GPU)
D:\msys64\clangarm64\bin\vainfo.exe: Supported profile and entrypoints
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointVLD
      VAProfileHEVCMain               : VAEntrypointVLD
      VAProfileHEVCMain10             : VAEntrypointVLD
      VAProfileVP9Profile0            : VAEntrypointVLD
      VAProfileVP9Profile2            : VAEntrypointVLD
      VAProfileNone                   : VAEntrypointVideoProc

VAEntrypointVLD is decoding support.

@tommyvct
Copy link
Contributor Author

Well, how about the 8cx gen 3 on the Surface Pro 9?

@driver1998
Copy link

Gen 3 is decode only as well, got this output from a friend with Dev Kit 2023:

-18f553376f3c3432.jpg

@driver1998
Copy link

I guess you may already know, but ARM64 Windows support of LuaJIT seems to be ready, cross-compiling from Windows x64 MSVC is possible too LuaJIT/LuaJIT#1081.

@tommyvct
Copy link
Contributor Author

Yeah, I did notice that issue have been closed.

I'm currently waiting for #186 to be merged.

@shijunz
Copy link

shijunz commented Jan 10, 2024

Yeah, I did notice that issue have been closed.

I'm currently waiting for #186 to be merged.

@tommyvct could you double check the #186 , it maybe is ok today now?

@tommyvct
Copy link
Contributor Author

Yeah, I did notice that issue have been closed.

I'm currently waiting for #186 to be merged.

@tommyvct could you double check the #186 , it maybe is ok today now?

There are still something to be done on top of that PR. I have been lazy and busy, I will try to find a time to try if it works

@i-lina
Copy link

i-lina commented Jan 11, 2024

Thanks @tommyvct your help in this would be much appreciated.

@tommyvct tommyvct marked this pull request as draft January 12, 2024 14:52
@i-lina
Copy link

i-lina commented Mar 11, 2024

Hello @tommyvct,
Were you able to make any progress on this?
Thanks!

@tommyvct
Copy link
Contributor Author

Hello @tommyvct, Were you able to make any progress on this? Thanks!

This PR will most likely be superseded by #190.

There are still quite a few things that we are waiting to be fixed in the upstream.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants