GS/HW: Allow baking shaders into executable.

[TJnotJT]

Description of Changes

Adds a Python script and build settings to allow baking some GS shaders into the PCSX2 executable.

Affects the following shaders:

bin/resources/shaders/common/fxaa.cpp
bin/resources/shaders/vulkan/convert.cpp
bin/resources/shaders/vulkan/imgui.cpp
bin/resources/shaders/vulkan/interlace.cpp
bin/resources/shaders/vulkan/merge.cpp
bin/resources/shaders/vulkan/present.cpp
bin/resources/shaders/vulkan/shadeboost.cpp
bin/resources/shaders/vulkan/tfx.cpp
bin/resources/shaders/opengl/convert.cpp
bin/resources/shaders/opengl/imgui.cpp
bin/resources/shaders/opengl/interlace.cpp
bin/resources/shaders/opengl/merge.cpp
bin/resources/shaders/opengl/present.cpp
bin/resources/shaders/opengl/shadeboost.cpp
bin/resources/shaders/opengl/tfx_fs.cpp
bin/resources/shaders/opengl/tfx_vgs.cpp
bin/resources/shaders/dx11/convert.cpp
bin/resources/shaders/dx11/imgui.cpp
bin/resources/shaders/dx11/interlace.cpp
bin/resources/shaders/dx11/merge.cpp
bin/resources/shaders/dx11/present.cpp
bin/resources/shaders/dx11/shadeboost.cpp
bin/resources/shaders/dx11/tfx.cpp

Rationale behind Changes

This allows different shaders to be more easily tested. For example, we can test multiple executables with different shaders without having to make sure the shaders on disk don't change.

Suggested Testing Steps

VS (manual): In the file common/vsprops/ShaderToCpp.props, change the line <BakeShadersInCpp>false</BakeShadersInCpp> to <BakeShadersInCpp>true</BakeShadersInCpp>.

VS (UI): In Property Manger window go under the pcsx2 project, select any configuration (e.g., Debug | x64), double click on ShaderToCpp. In the Common Properties > User Macros section, change the value of BakeShadersInCpp to true.

CMake: Build with the config variable BAKE_SHADERS_IN_CPP=true.

When building, you should see messages in the build log that indicate that the shaders are being converted to CPP files. The resulting executable should have the shaders baked at compile time so any changes made to the files in bin/resources/shaders should have no effect.

Did you use AI to help find, test, or implement this issue or feature?

I used AI to generate the Python files for converting text -> CPP. Also, to get help with the build file setup.

[TJnotJT]

Small addition so that this can be enabled in the VS UI without having to edit project files manually.

[TellowKrinkle]

Please put generated files into the build directory in cmake (CMAKE_CURRENT_BINARY_DIR), then you don't have to worry about gitignoring them, and there won't be any fights if you make multiple builds from the same source dir.

If you look at the vs files for e.g. handling qt translations, you can probably find a similar binary dir for use with vs.

[TJnotJT]

Please put generated files into the build directory in cmake (CMAKE_CURRENT_BINARY_DIR), then you don't have to worry about gitignoring them, and there won't be any fights if you make multiple builds from the same source dir.

If you look at the vs files for e.g. handling qt translations, you can probably find a similar binary dir for use with vs.

Good point, I modified it so that the generated files are now output in "${CMAKE_CURRENT_BINARY_DIR}/shaders_cpp" for CMake and "$(OutDir)/shaders_cpp" for VS, and the directory is added to the includes.

[F0bes]

Is there a reason why we don't ship releases with this enabled?

[lightningterror]

Agreed, we used to do this in the wx era and I prefer if the do it again. Bundle all the shaders in the executable with an option to search file directory too.

First check directory, if it doesn't exist then load built in shaders.
By default we won't ship the shader files.
That's how it used to work.

But I think the method we used was a little different back then compared to this.

[TellowKrinkle]

But I think the method we used was a little different back then compared to this.

We used RC files on Windows and gresources on Linux/Mac

BTW I'd rather not enable this for releases on mac builds, they're already self contained and there's no reason to embed stuff in the executable. Linux builds are also self contained, so they probably don't need it either.

[TJnotJT]

I'm fine with either option as I don't think users will be affected either way. I was mainly trying to make it easier to do GS dump runs when developing different branches, without having to clone into separate directories.