Make ffx-fsr2-api build on Linux

[TheJackiMonster]

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.

[FuyuriSeiichi]

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]

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]

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.

[TheJackiMonster]

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]

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]

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.

[Saancreed]

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]

• 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:

• https://en.cppreference.com/w/c/string/wide/wcscpy
• https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/strcpy-s-wcscpy-s-mbscpy-s?view=msvc-170

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]

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]

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]

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:

• glslangValidator: https://github.com/KhronosGroup/glslang
• spirv-opt: https://github.com/KhronosGroup/SPIRV-Tools
• spirv-cross: https://github.com/KhronosGroup/SPIRV-Cross

...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]

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]

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]

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:

• glslangValidator: https://github.com/KhronosGroup/glslang
• spirv-opt: https://github.com/KhronosGroup/SPIRV-Tools
• spirv-cross: https://github.com/KhronosGroup/SPIRV-Cross

...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]

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]

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]

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]

That makes so much more sense, when I saw python I am used to running python directly to build projects, though I know you did say it was just a script. I get it now, thanks.

…

On Wed, Jun 21, 2023 at 11:19 AM Tobias Frisch ***@***.***> wrote: 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) <#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. — Reply to this email directly, view it on GitHub <#60 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AM5Y337N2CJZOJCPTY37KRLXMMGJFANCNFSM6AAAAAAQZ4R57A> . You are receiving this because you commented.Message ID: ***@***.***>

[melroy89]

Will this be merged anytime soon now?