GPU: GLSL compilation as C++ for gpu static shaders #128724

						
				@ -915,0 +922,4 @@

				)

				cmake_policy(SET CMP0119 NEW)

				set_source_files_properties(intern/shaders/draw_debug_print_display_vert.glsl LANGUAGE CXX)

Ray molenkamp commented

2024-10-11 01:26:40 +02:00

set_source_files_properties(intern/shaders/draw_debug_print_display_vert.glsl PROPERTIES LANGUAGE CXX)

without the PROPERTIES keyword, cmake won't propagate it being a C++ file to msvc, however once you do about 40 of these guys show up (at different locations, not 40x this one)

1>K:\BlenderGit\blender\source\blender\draw\intern\shaders\draw_debug_info.hh(17,1): error C2466: cannot allocate an array of constant size 0

`set_source_files_properties(intern/shaders/draw_debug_print_display_vert.glsl PROPERTIES LANGUAGE CXX) ` without the `PROPERTIES` keyword, cmake won't propagate it being a C++ file to msvc, _however_ once you do about 40 of these guys show up (at different locations, not 40x this one) `1>K:\BlenderGit\blender\source\blender\draw\intern\shaders\draw_debug_info.hh(17,1): error C2466: cannot allocate an array of constant size 0`

👍 1

fclem marked this conversation as resolved

Clément Foucault added 3 commits 2024-10-11 19:44:44 +02:00

Fix compile warning and errors on GCC 4c8b59f61a

Merge branch 'main' into glsl-cpp-compilation 39f454ae43

# Conflicts:
#	source/blender/gpu/shaders/gpu_glsl_cpp_stubs.hh

Move shader executable to its own directory 40cae65002

Clément Foucault force-pushed glsl-cpp-compilation from 40cae65002 to d522f048b3

2024-11-02 00:46:30 +01:00

Compare

Clément Foucault force-pushed glsl-cpp-compilation from d522f048b3 to ec03cb6e28

2024-11-02 00:49:03 +01:00

Compare

Clément Foucault added 1 commit 2024-11-02 00:49:35 +01:00

Turn CPP compilation on for testing

buildbot/vexp-code-patch-lint Build done.

Details

buildbot/vexp-code-patch-linux-x86_64 Build done.

Details

buildbot/vexp-code-patch-darwin-x86_64 Build done.

Details

buildbot/vexp-code-patch-darwin-arm64 Build done.

Details

buildbot/vexp-code-patch-windows-amd64 Build done.

Details

buildbot/vexp-code-patch-coordinator Build done.

Details

1b57f9b994

Clément Foucault reviewed 2024-11-02 00:51:21 +01:00

source/blender/gpu/shaders/CMakeLists.txt Outdated

						
				@ -0,0 +81,4 @@

				add_definitions(-DGPU_SHADER)

				function(compile_sources_as_cpp

Clément Foucault commented

2024-11-02 00:51:21 +01:00

@LazyDodo I couldn't make it to work if I define this in macro.cmake.

Is it ok to copy this a few time (one time per shader folder)?

@LazyDodo I couldn't make it to work if I define this in `macro.cmake`. Is it ok to copy this a few time (one time per shader folder)?

fclem marked this conversation as resolved

Clément Foucault reviewed 2024-11-02 00:52:39 +01:00

CMakeLists.txt Outdated

						
				@ -875,0 +879,4 @@

				option(WITH_GPU_SHADER_CPP_COMPILATION "\

				Compiler shaders using C++. \

				Allows testing Metal compilation on other platform and enable C++ IDE support for shader code"

				  ON

Clément Foucault commented

2024-11-02 00:52:30 +01:00

TODO: Turn off. Only here for checking on the build bot.

fclem marked this conversation as resolved

Clément Foucault changed title from ~~WIP: GPU: GLSL compilation as C++~~ to GPU: GLSL compilation as C++ for gpu static shaders

2024-11-02 00:53:06 +01:00

Clément Foucault commented

2024-11-02 00:53:24 +01:00

@blender-bot build

Clément Foucault reviewed 2024-11-02 00:54:20 +01:00

CMakeLists.txt

						
				@ -96,2 +96,4 @@

				endif()

				# Allow to specify language per file.

				if(POLICY CMP0119)

Clément Foucault commented

2024-11-02 00:54:20 +01:00

Is this ok to put here or should it be enabled local?

fclem marked this conversation as resolved

Clément Foucault added 2 commits 2024-11-05 00:40:21 +01:00

Make common libs C++ compatible 107022e32e

Merge branch 'main' into glsl-cpp-compilation b57edfc74f

Clément Foucault added 4 commits 2024-11-05 23:01:13 +01:00

Avoid error caused by gpu_index_load symbol redefinition 9f1e1db65e

Add support to remaining common libs b2d1202654

Fix compilation error c330f9c312

Make sure that WITH_GPU_SHADER_CPP_COMPILATION requires CMP0119 and have fallback

buildbot/vexp-code-patch-lint Build done.

Details

buildbot/vexp-code-patch-darwin-arm64 Build done.

Details

buildbot/vexp-code-patch-linux-x86_64 Build done.

Details

buildbot/vexp-code-patch-darwin-x86_64 Build done.

Details

buildbot/vexp-code-patch-windows-amd64 Build done.

Details

buildbot/vexp-code-patch-coordinator Build done.

Details

fefd627faa

Clément Foucault commented

2024-11-05 23:09:43 +01:00

@blender-bot build

Clément Foucault requested review from Ray molenkamp 2024-11-06 20:26:53 +01:00

Ray molenkamp approved these changes 2024-11-06 20:59:39 +01:00

Ray molenkamp left a comment

I see nothing wrong with the build system changes, everything else is pretty far out of my normal area and i don't feel qualified to review.

Clément Foucault requested review from Jeroen Bakker 2024-11-06 21:05:18 +01:00

Clément Foucault requested review from Miguel Pozo 2024-11-06 21:05:19 +01:00

Miguel Pozo commented

2024-11-07 16:36:33 +01:00

It's not working on my end (VSCode, msvc, default C++ extension pack) :(

It looks like it's not catching the GPU_SHADER define, if I define it manually it works:

I've tried defining it with target_compile_definitions but it didn't do the trick.

Aside from that, I had to update the STORAGE_BUF_FREQ definition to qualifiers type_name name = {0}, otherwise compilation fails.
I'm not sold on requiring a "fake" library compilation to get Intellisense working, to be honest.
It adds to the compile times and prevents the build from finishing if any of the hacks fail.

It's not working on my end (VSCode, msvc, default C++ extension pack) :( ![imagen](/attachments/80f269d2-4cb6-4639-a995-e6cf11978ab9) It looks like it's not catching the `GPU_SHADER` define, if I define it manually it works: ![imagen](/attachments/4e253dcb-cf4e-4c9c-a4e8-f840d614b17d) I've tried defining it with `target_compile_definitions` but it didn't do the trick. Aside from that, I had to update the `STORAGE_BUF_FREQ` definition to `qualifiers type_name name = {0}`, otherwise compilation fails. I'm not sold on requiring a "fake" library compilation to get Intellisense working, to be honest. It adds to the compile times and prevents the build from finishing if any of the hacks fail.

imagen.png

186 KiB

imagen.png

187 KiB

Clément Foucault commented

2024-11-07 16:58:47 +01:00

I've tried defining it with target_compile_definitions but it didn't do the trick.

Does CMAKE config has the CMAKE_EXPORT_COMPILE_COMMAND enables and does the C++ extension picks it up? (you might have to trash the intellisense cache)

It looks like it's not catching the GPU_SHADER define, if I define it manually it works:

What does the content of your ${BUILD_FOLDER}/compile_commands.json looks like for the GLSL C++ compilation? (you can attach it here and I'll look at it).

It adds to the compile times and prevents the build from finishing if any of the hacks fail.

It is opt-in.
Failing the build is exactly the purpose. It signals a problem with shader compilation that is likely to be an issue on Metal. And that's the only way to detect issue on MSL (symbol clashing, invalid syntax, reserved keywords) on non-Mac systems.

The initial target was intellisense support, but the added benefit of correct compilation are much bigger. Once it is setup, you have static analysis & clang-tidy working and useful warnings.

The hacks failing is because not every cases were tested yet and we are still making it work. I don't think this will have a very high maintenance cost and fixing it is quite easy as you saw.

> I've tried defining it with target_compile_definitions but it didn't do the trick. Does CMAKE config has the `CMAKE_EXPORT_COMPILE_COMMAND` enables and does the C++ extension picks it up? (you might have to trash the intellisense cache) > It looks like it's not catching the GPU_SHADER define, if I define it manually it works: What does the content of your `${BUILD_FOLDER}/compile_commands.json` looks like for the GLSL C++ compilation? (you can attach it here and I'll look at it). > It adds to the compile times and prevents the build from finishing if any of the hacks fail. 1. It is opt-in. 2. Failing the build is exactly the purpose. It signals a problem with shader compilation that is likely to be an issue on Metal. And that's the only way to detect issue on MSL (symbol clashing, invalid syntax, reserved keywords) on non-Mac systems. The initial target was intellisense support, but the added benefit of correct compilation are much bigger. Once it is setup, you have static analysis & clang-tidy working and useful warnings. The hacks failing is because not every cases were tested yet and we are still making it work. I don't think this will have a very high maintenance cost and fixing it is quite easy as you saw.

Miguel Pozo commented

2024-11-07 17:18:03 +01:00

Does CMAKE config has the CMAKE_EXPORT_COMPILE_COMMAND enables and does the C++ extension picks it up?

It's enabled by default, but it looks like it does nothing for msvc:
https://cmake.org/cmake/help/latest/variable/CMAKE_EXPORT_COMPILE_COMMANDS.html

This option is implemented only by Makefile Generators and Ninja Generators. It is ignored on other generators.

So I don't have a compile_commands.json at all.

> Does CMAKE config has the CMAKE_EXPORT_COMPILE_COMMAND enables and does the C++ extension picks it up? It's enabled by default, but it looks like it does nothing for msvc: https://cmake.org/cmake/help/latest/variable/CMAKE_EXPORT_COMPILE_COMMANDS.html > This option is implemented only by Makefile Generators and Ninja Generators. It is ignored on other generators. So I don't have a `compile_commands.json` at all.

Clément Foucault commented

2024-11-07 17:29:17 +01:00

Interesting. So I guess we should add a hint inside this new WITH_GPU_SHADER_CPP_COMPILATION that its only compatible with Ninja on windows.

Interesting. So I guess we should add a hint inside this new `WITH_GPU_SHADER_CPP_COMPILATION` that its only compatible with Ninja on windows.

Ray molenkamp commented

2024-11-07 17:47:30 +01:00

for VS Code you should be able to use the ninja generator on windows, it likely be the preferred generator for such a setup.

For what it's worth, gave it a whirl with the normal VS IDE (Not VS Code) it builds (kinda) fine, but no intellisense/code completion is available.

ran into the same issue with STORAGE_BUF_FREQ as @pragma37 on top of that

1>K:\BlenderGit\blender\source\blender\gpu\shaders\gpu_glsl_cpp_stubs.hh(650,36): warning C4273: 'fma': inconsistent dll linkage
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\ucrt\corecrt_math.h(510,47): message : see previous definition of 'fma'

Also when reviewing this i assumed it was just a single file for testing, but as this is now seems to be coming closer to landing time, it only builds a single file per subproject currently, should there have been more of them?

for VS Code you should be able to use the ninja generator on windows, it likely be the preferred generator for such a setup. For what it's worth, gave it a whirl with the normal VS IDE (Not VS Code) it builds (kinda) fine, but no intellisense/code completion is available. ran into the same issue with `STORAGE_BUF_FREQ` as @pragma37 on top of that ```plaintext 1>K:\BlenderGit\blender\source\blender\gpu\shaders\gpu_glsl_cpp_stubs.hh(650,36): warning C4273: 'fma': inconsistent dll linkage 1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\ucrt\corecrt_math.h(510,47): message : see previous definition of 'fma' ``` Also when reviewing this i assumed it was just a single file for testing, but as this is now seems to be coming closer to landing time, it only builds a single file per subproject currently, should there have been more of them? ![image](/attachments/5696b577-26cf-4b43-ab97-ab58331d8c3d)

image.png

11 KiB

Miguel Pozo commented

2024-11-07 18:04:43 +01:00

Passing the files as a string fixes the issue and makes IntelliSense work:

diff --git a/source/blender/gpu/shaders/CMakeLists.txt b/source/blender/gpu/shaders/CMakeLists.txt
index f1aab36f900..267ba1e2068 100644
--- a/source/blender/gpu/shaders/CMakeLists.txt
+++ b/source/blender/gpu/shaders/CMakeLists.txt
@@ -90,10 +90,8 @@ function(compile_sources_as_cpp
   sources
   define
   )
-
-  foreach(glsl_file ${sources})
-    set_source_files_properties(${glsl_file} PROPERTIES LANGUAGE CXX)
-  endforeach()
+
+  set_source_files_properties(${sources} PROPERTIES LANGUAGE CXX)

   add_library(${executable} OBJECT ${sources})
   set_target_properties(${executable} PROPERTIES LINKER_LANGUAGE CXX)
@@ -102,9 +100,10 @@ function(compile_sources_as_cpp
 endfunction()


+
 # Compile shaders with shader code.
 if (WITH_GPU_SHADER_CPP_COMPILATION)
-  compile_sources_as_cpp(gpu_cpp_shaders_vert ${SRC_GLSL_VERT} "GPU_VERTEX_SHADER")
-  compile_sources_as_cpp(gpu_cpp_shaders_frag ${SRC_GLSL_FRAG} "GPU_FRAGMENT_SHADER")
-  compile_sources_as_cpp(gpu_cpp_shaders_lib ${SRC_GLSL_LIB} "GPU_FRAGMENT_SHADER")
+  compile_sources_as_cpp(gpu_cpp_shaders_vert "${SRC_GLSL_VERT}" "GPU_VERTEX_SHADER")
+  compile_sources_as_cpp(gpu_cpp_shaders_frag "${SRC_GLSL_FRAG}" "GPU_FRAGMENT_SHADER")
+  compile_sources_as_cpp(gpu_cpp_shaders_lib "${SRC_GLSL_LIB}" "GPU_FRAGMENT_SHADER")
 endif()

But now I'm drowned in compilation errors. 😫

Passing the files as a string fixes the issue and makes IntelliSense work: ```diff diff --git a/source/blender/gpu/shaders/CMakeLists.txt b/source/blender/gpu/shaders/CMakeLists.txt index f1aab36f900..267ba1e2068 100644 --- a/source/blender/gpu/shaders/CMakeLists.txt +++ b/source/blender/gpu/shaders/CMakeLists.txt @@ -90,10 +90,8 @@ function(compile_sources_as_cpp sources define ) - - foreach(glsl_file ${sources}) - set_source_files_properties(${glsl_file} PROPERTIES LANGUAGE CXX) - endforeach() + + set_source_files_properties(${sources} PROPERTIES LANGUAGE CXX) add_library(${executable} OBJECT ${sources}) set_target_properties(${executable} PROPERTIES LINKER_LANGUAGE CXX) @@ -102,9 +100,10 @@ function(compile_sources_as_cpp endfunction() + # Compile shaders with shader code. if (WITH_GPU_SHADER_CPP_COMPILATION) - compile_sources_as_cpp(gpu_cpp_shaders_vert ${SRC_GLSL_VERT} "GPU_VERTEX_SHADER") - compile_sources_as_cpp(gpu_cpp_shaders_frag ${SRC_GLSL_FRAG} "GPU_FRAGMENT_SHADER") - compile_sources_as_cpp(gpu_cpp_shaders_lib ${SRC_GLSL_LIB} "GPU_FRAGMENT_SHADER") + compile_sources_as_cpp(gpu_cpp_shaders_vert "${SRC_GLSL_VERT}" "GPU_VERTEX_SHADER") + compile_sources_as_cpp(gpu_cpp_shaders_frag "${SRC_GLSL_FRAG}" "GPU_FRAGMENT_SHADER") + compile_sources_as_cpp(gpu_cpp_shaders_lib "${SRC_GLSL_LIB}" "GPU_FRAGMENT_SHADER") endif() ``` But now I'm drowned in compilation errors. 😫

Clément Foucault commented

2024-11-07 18:09:28 +01:00

But now I'm drowned in compilation errors. 😫

Please attach them here so I can have a look.

> But now I'm drowned in compilation errors. 😫 Please attach them here so I can have a look.

Miguel Pozo commented

2024-11-07 18:29:46 +01:00

Ok, after updating STORAGE_BUF_FREQ to qualifiers type_name name = {type_name()}; I no longer get errors, but I get a gigantic list of warnings (mostly duplicated definitions).

I think you should get those too if you fix your compile_sources_as_cpp call.

BTW, for files that have to be included everywhere I would use precompiled headers:
target_precompile_headers(${executable} PRIVATE "gpu_glsl_cpp_stubs.hh")

Ok, after updating `STORAGE_BUF_FREQ` to `qualifiers type_name name = {type_name()};` I no longer get errors, but I get a gigantic list of warnings (mostly duplicated definitions). I think you should get those too if you fix your `compile_sources_as_cpp` call. BTW, for files that have to be included everywhere I would use precompiled headers: `target_precompile_headers(${executable} PRIVATE "gpu_glsl_cpp_stubs.hh")`

Ray molenkamp commented

2024-11-07 18:32:40 +01:00

target_precompile_headers(${executable} PRIVATE "gpu_glsl_cpp_stubs.hh")

historically we've only used that when there was a significant savings to be had (ie shave minutes off a build) i don't see precompiled being useful here, only complicating the build without any tangible benefits

> target_precompile_headers(${executable} PRIVATE "gpu_glsl_cpp_stubs.hh") historically we've only used that when there was a significant savings to be had (ie shave minutes off a build) i don't see precompiled being useful here, only complicating the build without any tangible benefits

Ray molenkamp commented

2024-11-07 18:35:05 +01:00

most of the warns are because of type_traits somehow including math.h and fma haivng a different calling convention there, naively sidestepping it inside gpu_glsl_cpp_stubs.hh like this seems to quiet things down a lot.

#ifndef _MSC_VER
double fma(double, double, double) RET;
#endif

most of the warns are because of type_traits somehow including `math.h` and `fma` haivng a different calling convention there, naively sidestepping it inside `gpu_glsl_cpp_stubs.hh` like this seems to quiet things down a lot. ``` #ifndef _MSC_VER double fma(double, double, double) RET; #endif ```

Miguel Pozo commented

2024-11-07 18:47:49 +01:00

i don't see precompiled being useful here, only complicating the build without any tangible benefits

The tangible benefit is not having to add an #include "gpu_glsl_cpp_stubs.hh" to every single info.hh and lib.glsl file, and not getting weird compiler errors when someone inevitably forgets to do so when they have the WITH_GPU_SHADER_CPP_COMPILATION option disabled.
What's the downside of using precompiled headers in this case?

> i don't see precompiled being useful here, only complicating the build without any tangible benefits The tangible benefit is not having to add an `#include "gpu_glsl_cpp_stubs.hh"` to every single `info.hh` and `lib.glsl` file, and not getting weird compiler errors when someone inevitably forgets to do so when they have the `WITH_GPU_SHADER_CPP_COMPILATION` option disabled. What's the downside of using precompiled headers in this case?

Ray molenkamp commented

2024-11-07 19:05:06 +01:00

The same could be done with /FI msvc and -include gcc where the behaviour is explicitly wanted, rather than a side effect you're exploiting.

The same could be done with `/FI` [msvc](https://learn.microsoft.com/en-us/cpp/build/reference/fi-name-forced-include-file?view=msvc-170) and `-include` [gcc](https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Preprocessor-Options.html) where the behaviour is explicitly wanted, rather than a side effect you're exploiting.

👍 1

Clément Foucault commented

2024-11-07 19:13:10 +01:00

The same could be done with /FI msvc and -include gcc where the behaviour is explicitly wanted, rather than a side effect you're exploiting.

What about clang?

I am not sure about hiding includes inside the build system itself. It would confuse external devs even more than the current duplicated include.

Moreover, often times, the infos file need more (defines + other info includes) than just this file to be made compatible. So I am not sure how much we would be saving here.

> The same could be done with /FI msvc and -include gcc where the behaviour is explicitly wanted, rather than a side effect you're exploiting. What about clang? I am not sure about hiding includes inside the build system itself. It would confuse external devs even more than the current duplicated include. Moreover, often times, the infos file need more (defines + other info includes) than just this file to be made compatible. So I am not sure how much we would be saving here.

Ray molenkamp commented

2024-11-07 19:20:37 +01:00

clang will also take -include on forced includes vs explicit includes, i have no horse in the race but i could see some code completion implementations get confused with the pch/forced include way of things.

clang will also take `-include` on forced includes vs explicit includes, i have no horse in the race but i could see some code completion implementations get confused with the pch/forced include way of things.

Miguel Pozo commented

2024-11-07 19:32:00 +01:00

I am not sure about hiding includes inside the build system itself. It would confuse external devs even more than the current duplicated include.

I would normally agree, but this is just emulating GLSL built-in functions that are always available.
Having to explicitly include empty stubs because of a custom build-system hack only makes it more confusing, IMO, and certainly less convenient.

Code-completion being confused by it is a good point, but unless we have a specific example it's only a "what if".

> I am not sure about hiding includes inside the build system itself. It would confuse external devs even more than the current duplicated include. I would normally agree, but this is just emulating GLSL built-in functions that are always available. Having to explicitly include empty stubs because of a custom build-system hack only makes it more confusing, IMO, and certainly less convenient. Code-completion being confused by it is a good point, but unless we have a specific example it's only a "what if".

Ray molenkamp commented

2024-11-07 19:40:39 +01:00

Heh, yeah soo... fun story, it's more of a "what if" since code completion (on these files) doesn't work at all in the VS IDE , so it doesn't even get to the point it would work badly :)

Heh, yeah soo... fun story, it's more of a "what if" since code completion (on these files) doesn't work _at all_ in the VS IDE , so it doesn't even get to the point it would work badly :)

😕 1

Ray molenkamp commented

2024-11-07 20:25:13 +01:00

one for the docs : it'll work if you set Tools -> Options -> Text Editor -> File Extension -> Extension: glsl, Editor: Microsoft Visual C++ and close/reopen any open glsl tabs.

looks like you'll may have to be careful with the comments you leave though, as they show up in the tooltips.

one for the docs : it'll work if you set `Tools -> Options -> Text Editor -> File Extension -> Extension: glsl, Editor: Microsoft Visual C++` and close/reopen any open glsl tabs. ![image](/attachments/390e6b59-7854-473c-82f0-a2baefd4f3fe) looks like you'll may have to be careful with the comments you leave though, as they show up in the tooltips.

image.png

64 KiB

👍 1

Clément Foucault commented

2024-11-08 22:45:17 +01:00

I would normally agree, but this is just emulating GLSL built-in functions that are always available.

It is not 100% just emulating GLSL built-in. It is supposed to also have all the definitions inside mtl/glsl_shader_defines.glsl/msl. I am also looking into making theses include explicit in the future (except for pyGPU shader of course).

Adding the header to all infos can be done using a common header which would look like this:

#ifdef GPU_SHADER
#include "gpu_glsl_cpp_stubs.hh"
#endif
#define "gpu_shader_create_info.hh"

This can be done once we sort the dependency issues and add #pragma once to the info files. That wouldn't remove the need for adding #defines at the top of each info file. So that could be a follow up task.

About having to include gpu_glsl_cpp_stubs.hh to the GLSL lib, it only needs to be included in file with no other lib included. Since it is included in very common lib like gpu_shader_math_lib.glsl it is already added to a good portion of the codebase.

About if someone forgets to put the include:

it is easy to fix.
it is not very likely to happen given that new code is usually copied from the existing one.

getting weird compiler errors

I am not sure what you are referring to. If the cpp shader fails to build because vec2 is not a recognized symbol as well as pretty much everything, I think the error is easy to understand.

> I would normally agree, but this is just emulating GLSL built-in functions that are always available. It is not 100% just emulating GLSL built-in. It is supposed to also have all the definitions inside `mtl/glsl_shader_defines.glsl/msl`. I am also looking into making theses include explicit in the future (except for pyGPU shader of course). Adding the header to all infos can be done using a common header which would look like this: ``` #ifdef GPU_SHADER #include "gpu_glsl_cpp_stubs.hh" #endif #define "gpu_shader_create_info.hh" ``` This can be done once we sort the dependency issues and add `#pragma once` to the info files. That wouldn't remove the need for adding `#define`s at the top of each info file. So that could be a follow up task. About having to include gpu_glsl_cpp_stubs.hh to the GLSL lib, it only needs to be included in file with no other lib included. Since it is included in very common lib like `gpu_shader_math_lib.glsl` it is already added to a good portion of the codebase. About if someone forgets to put the include: - it is easy to fix. - it is not very likely to happen given that new code is usually copied from the existing one. > getting weird compiler errors I am not sure what you are referring to. If the cpp shader fails to build because `vec2` is not a recognized symbol as well as pretty much everything, I think the error is easy to understand.

Clément Foucault added 3 commits 2024-11-08 23:16:43 +01:00

Merge branch 'main' into glsl-cpp-compilation a8e897b239

Fix source list 1a0dfbe6ad

Fix compilation on MSVC 57d80d8a9a

Clément Foucault added 1 commit 2024-11-12 16:16:04 +01:00

Fix FMA error fcaac2843f

Clément Foucault added 2 commits 2024-11-12 16:20:15 +01:00

Merge branch 'main' into glsl-cpp-compilation 4d9edaceab

# Conflicts:
#	source/blender/gpu/shaders/common/gpu_shader_math_fast_lib.glsl

Fix comment

buildbot/vexp-code-patch-lint Build done.

Details

buildbot/vexp-code-patch-linux-x86_64 Build done.

Details

buildbot/vexp-code-patch-darwin-arm64 Build done.

Details

buildbot/vexp-code-patch-windows-amd64 Build done.

Details

buildbot/vexp-code-patch-darwin-x86_64 Build done.

Details

buildbot/vexp-code-patch-coordinator Build done.

Details

76a765ed2c

Miguel Pozo approved these changes 2024-11-12 16:50:31 +01:00

Clément Foucault commented

2024-11-12 17:09:03 +01:00

@blender-bot build

Clément Foucault merged commit 091004f1b8 into main

2024-11-12 18:53:55 +01:00

Clément Foucault referenced this issue from a commit

2024-11-12 18:53:56 +01:00

GPU: GLSL compilation as C++ for gpu static shaders

Clément Foucault deleted branch glsl-cpp-compilation

2024-11-12 18:53:59 +01:00

Sign in to join this conversation.

No reviewers

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

GPU: GLSL compilation as C++ for gpu static shaders #128724