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

Make ffx-fsr2-api build on Linux #60

Open
wants to merge 14 commits into
base: master
Choose a base branch
from

Conversation

TheJackiMonster
Copy link

@TheJackiMonster TheJackiMonster commented Sep 30, 2022

I've tested it building with newest gcc and clang on Archlinux. The only additional requirement is that wine needs to be installed to run the "FidelityFX_SC.exe". The automatic permutation unrolling from bash doesn't affect the permutations in shader parameters anymore and I exposed the targets via variables to the parent scope. So it can be used by other projects via CMake using add_subdirectory().

Edit: It's now possible to build it without using wine. See below for more information.

@TheJackiMonster TheJackiMonster mentioned this pull request Sep 30, 2022
@FuyuriSeiichi
Copy link

This is just GREAT. Is there special requirement of the wine? Version? built with vulkan support?
Please make sure to share more details with us.

@TheJackiMonster
Copy link
Author

This is just GREAT. Is there special requirement of the wine? Version? built with vulkan support? Please make sure to share more details with us.

I don't think wine needs to require Vulkan support. I can not tell you exactly what it needs to do since I don't have the source code of the FidelityFX_SC.exe. But I assume it just processes the arguments to some degree and forwards it to the glslangValidator.exe. So comparing it to the glslang package on Arch, I would say there is no extra requirement for wine.

@TheJackiMonster
Copy link
Author

Also for some people who want to see an example how FSR2 can just be integrated via CMake using the repository as submodule, I implemented that yesterday in a Vulkan framework from university, I'm working on. Here's the code and other changes from the specific merge-request. The framework should build across Windows, macOS and Linux. But since I mostly develop and test on Arch, it might require some fixes. ^^'

But for very interested people, the merge-request includes changes to the example project of the framework "indirect_dispatch" which shows a motion-blur implementation by another student. The project now supports using FSR2. I think, I still have to tweak it though.

Signed-off-by: TheJackiMonster <[email protected]>
@TheJackiMonster
Copy link
Author

Today I noticed during testing a build of the framework I'm working on that my changes broke the ability to build everything on Windows. So I included a fix which allows it to work on Windows as well as Linux. However if anyone knows a better way to address curly braces replacements in Bash, let me know.

Otherwise maybe the tool to compile the shaders could use a different syntax for parameters than X={0,1}..?

@Calinou
Copy link

Calinou commented Jan 16, 2023

Regarding FidelityFX_SC.exe, could you commit the files resulting from running the executable for both Vulkan and Direct3D 12? This way, there would be no more need to run the executable at build-time, therefore removing the WINE requirement.

The executable can be kept in version control so that it can be run again for future FSR updates.

@TheJackiMonster
Copy link
Author

Regarding FidelityFX_SC.exe, could you commit the files resulting from running the executable for both Vulkan and Direct3D 12? This way, there would be no more need to run the executable at build-time, therefore removing the WINE requirement.

The executable can be kept in version control so that it can be run again for future FSR updates.

Oh, I should mention that I didn't get it for Direct3D 12 working on Linux but only Vulkan. The resulting files are a lot of headers containing the binary data for the shaders which get compiled to archives. I assume I can provide them for x86_64 targets as debug and release builds: FSR2-linux.zip

Those archives can be built when setting FFX_FSR2_API_VK to ON and FFX_FSR2_API_DX12 to OFF. That's what I do to include FSR2 for upscaling in a custom Vulkan framework here. Long term I planned to replace the requirement of wine by writing a custom shell script translating the files via glslang but I didn't look into that yet.

@ericwomer ericwomer mentioned this pull request Feb 4, 2023
@Saancreed
Copy link

However if anyone knows a better way to address curly braces replacements in Bash, let me know.

My solution for this is: don't use bash, at least for make. If you're unfortunate enough to use a distro that symlinks /bin/sh to bash like Arch Linux, you can still build this fine by installing some POSIX-compatible shell and building with something like make SHELL=/usr/bin/dash for example.

Here is a diff that also is sufficient to build on Linux with gcc but aims to have much smaller footprint (to make future rebasing easier): gcc-linux-compat.diff.txt

Changes compared to this PR:

  • includes stddef.h instead of stdlib.h for size_t
  • replaces cmath include with math.h instead of changing std::abs because a bunch of other functions from cmath are also used without std:: qualifier
  • uses #define wcscpy_s wcscpy instead of fixing each call site separately
  • has better quoting/shell escaping in FidelityFX_SC.sh and silences Wine's debug output
  • uses spaces for indentation and doesn't attempt to fix whitespaces all over the code

@TheJackiMonster
Copy link
Author

  • uses #define wcscpy_s wcscpy instead of fixing each call site separately

I don't think there should any wcscpy_s() be in code though since it's clearly used wrong here. The function actually requires 3 parameters looking at the documentation:

Otherwise using a different shell is a good point but unfortunately bash is widely used as default shell. So for compatibility it's better to support it, I think.

@Saancreed
Copy link

I don't think there should any wcscpy_s() be in code though since it's clearly used wrong here. The function actually requires 3 parameters looking at the documentation

Not exactly, MS docs have this:

template <size_t size>
errno_t wcscpy_s(
   wchar_t (&dest)[size],
   const wchar_t *src
); // C++ only

Which is obviously not part of the standard so it will compile with MSVC but not any other compiler that doesn't provide a similar extension. The #ifndef _MSC_VER is precisely to workaround use of a nonstandard function with other compilers.

Otherwise using a different shell is a good point but unfortunately bash is widely used as default shell. So for compatibility it's better to support it, I think.

You're right, but I believe this is a problem only if /bin/sh on your system is symlinked to bash. There should be no such issue on Ubuntu, Debian and other distros that don't take this shortcut.

@adevaykin
Copy link

FYI: FidelityFX_SC.exe is an issue on Mac, so it would be great to have a workaround.
My current workaround was to just copy permuteted shader headers from Windows and skip call to FidelityFX_SC.exe on Mac.

@TheJackiMonster
Copy link
Author

There you go people, I've written a script in Python which mostly matches the behavior of AMD's binary to process shaders. The downsides are that it's limited to GLSL and you need some tools installed for it to work:

...and of course you will need Python. The script compiles GLSL to optimized SPIRV using all the different permutations of macros, generates headers for each unique permutation and combines those together with expected info structures. It's all reverse-engineered from the output I got from running FidelityFX_SC.exe via wine because I didn't have the original source code. If there's still an issue, let me know but hopefully this makes compiling FSR2 easier.

@romulasry
Copy link

There is no motion vectors in videos. FSR2 cannot be ported as a video's filter/shader.
https://gist.github.com/agyild/82219c545228d70c5604f865ce0b0ce5?permalink_comment_id=4491278#gistcomment-4491278

AMD FidelityFX Super Resolution v1.0.2 for mpv

@Calinou
Copy link

Calinou commented Mar 4, 2023

AMD FidelityFX Super Resolution v1.0.2 for mpv

FSR 1.0 is a spatial upscaler, so it can be implemented in video players. FSR 2.0 is a temporal upscaler, so it can't as videos don't provide motion vectors.

@gardotd426
Copy link

There you go people, I've written a script in Python which mostly matches the behavior of AMD's binary to process shaders. The downsides are that it's limited to GLSL and you need some tools installed for it to work:

...and of course you will need Python. The script compiles GLSL to optimized SPIRV using all the different permutations of macros, generates headers for each unique permutation and combines those together with expected info structures. It's all reverse-engineered from the output I got from running FidelityFX_SC.exe via wine because I didn't have the original source code. If there's still an issue, let me know but hopefully this makes compiling FSR2 easier.

Real confused, since there's literally zero information on how to build this (I would imagine if you want this to have any hope of getting merged you probably need to also file a PR for README.md to add Linux instructions to the build section). Obviously the python script requires an input file, but there's no information on what the input file is supposed to be. Obviously none of the exes are going to work, nor are the batch scripts or CMake files. What the hell do you even run the python script on?

@m3t4f1v3
Copy link

does this work for unreal engine?
i've tried applying the patches but it still seems to fail at linking some libs at FSR2TemporalUpscaler.cpp

@TheJackiMonster
Copy link
Author

does this work for unreal engine? i've tried applying the patches but it still seems to fail at linking some libs at FSR2TemporalUpscaler.cpp

I haven't tested that. Last time I tried using UnrealEngine on Linux, I had to manually compile for an hour and the build script simply failed at the end. Since then I've sticked with game engines which seem to support Linux more reasonable.

So I don't really know how they link it to be honest, whether it uses some specific API to be compatible with the engine. All efforts here are just to build it on Linux at all without the use of wine or DirectX.

@TheJackiMonster
Copy link
Author

Real confused, since there's literally zero information on how to build this (I would imagine if you want this to have any hope of getting merged you probably need to also file a PR for README.md to add Linux instructions to the build section). Obviously the python script requires an input file, but there's no information on what the input file is supposed to be. Obviously none of the exes are going to work, nor are the batch scripts or CMake files. What the hell do you even run the python script on?

More detailed information is here:
#6 (comment)

But to be honest any developer knowing CMake should get it going with the information I've put up here. It's intended for developers anyway. There's no need to run a python script manually or any exe files. So I'm not sure what you are referring to.

I've even pointed to a custom project where I integrated support via git submodule and CMake:
https://gitlab.uni-koblenz.de/vulkan2021/vkcv-framework/-/blob/develop/modules/upscaling/config/FidelityFX_FSR2.cmake

At this point developers only need to use the branch as git submodule and call add_subdirectory() in CMake to use it in any software. That's as hard as using it on Windows. I know this because the framework I integrated it cross-compiles on Windows as well.

Also there's not one official response yet towards this PR from AMD or GPUOpen. I assume to merge it, they would want their example projects to build and run as well calling it properly supported. But I don't have the time to tweak all of this.

@gardotd426
Copy link

gardotd426 commented Jun 21, 2023 via email

@melroy89
Copy link

melroy89 commented Jun 5, 2024

Will this be merged anytime soon now?

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.

10 participants