Make runtime shader compilation optional #251

bullno1 · 2024-11-22T10:21:44Z

Huge changes:

Add libcute-shader as a wrapper for glslang.
Add cute-shaderc, an offline compiler that can generate header for embedding.
Add various functions to accept bytecode from generated headers.
Precompile builtin shaders and also allow runtime compilation.
Builtin shaders have to be declared in src/cute_shader/builtin_shaders.h
Updated all samples to support both precompiled bytecode and runtime compilation.

As of this writing, windows build in CI is blocked by: actions/runner-images#10978.

~~Allso, #include within the cf_shader_directory is not yet resolved.~~ (Implemented)
I'm posting this early for feedbacks.

RandyGaul

Questions:

Is the shader compiler a standalone program? Which source is it exactly? I didn't want to spend time trawling the cmake file to find out. Is it just cute_shaderc.cpp and associated header?
Could you outline here what the major individual build targets are exactly and outline their dependencies to each other?
Can the shader compiler be linked in statically into cute.lib or cute.dll (static or dynamic libs, but not as a standalone exe), as a simple cmake option?
Is this easy for users to toggle on/off in cmake? I want runtime shaders in CF on by default, and behind a single cmake option to turn them off and NOT compile or pull in any SPIRV nonsense. Is that the way things work here as of now?
Do you have plans yet to add in a dedicated website page for documenting the compiler?
Can the compiler output serialized SPIRV blobs directly, and not just C headers?
Can the compiler output reflection info required for passing into SDL_Gpu (various input counts for specific resource sets)?
I'd prefer only one or two samples to use bytecode. The rest should just use runtime shaders alone to reduce complexity.

RandyGaul · 2024-11-22T22:10:30Z

CMakeLists.txt

 		add_executable(timestep samples/timestep.cpp)
 		add_executable(joypad samples/joypad.c)
 		add_executable(outline_stencil samples/outline_stencil.cpp)
-		add_executable(recolor samples/recolor.cpp)
+		add_executable(recolor samples/recolor.cpp samples/recolor_data/recolor_shd.h)


I would prefer the majority of sample code to use runtime string shaders. Precompiling is unneeded complexity when starting out.

Oh I made the changes just to check that all samples are fine with CF_GLSLANG=OFF

I can revert but those samples would crash when CF_GLSLANG=OFF, is that acceptable?

Yep that's fine. As long as they all work with default settings when cloning, if the user turns it off I would expect them to then crash.

RandyGaul · 2024-11-22T22:11:15Z

include/cute_draw.h

+ * @remarks  This can be created using the `cute-shaderc` compiler.
+ * @related  CF_Shader cf_draw_push_shader cf_draw_pop_shader cf_draw_peek_shader cf_make_draw_shader_from_bytecode
+ */
+typedef struct CF_DrawShaderBytecode {


Newline on brace to match the rest of CF. We will need a page on CF website documenting cute-shaderc for sure. I can help get you going on that if you need -- it's really easy.

RandyGaul · 2024-11-22T22:12:11Z

samples/hello_triangle_data/tri_fs.h

@@ -0,0 +1,36 @@
+#pragma once
+
+static const uint8_t s_tri_fs_bytecode_content[448] = {


We want, in a comment, the string representation of the shader just above the bytecode here. Perhaps the compiler should output this directly into the header. sokol-shdc does this and it's greatly appreciated

Sure. Preprocessed shader or original code?

Probably preprocessed

RandyGaul · 2024-11-22T22:13:48Z

src/cute_shader/cute_shader.cpp

+	size_t size;
+};
+
+class Includer: public glslang::TShader::Includer {


Interesting, is this includer thing a part of the glslang API? I hate it, but looks like it's just a way to use glslang, which is accpetable and I'm glad you hid this all back here in the implementation in an isolated place.

Yes, it is glslang API to search for include file. It is passed to glslang:TShader::preprocess. glslang will call the includer to search for files.

I use that to implement lookup in the VFS, builtin shader include and also automatic include guard.

In the case of duplicated includes, the content is resolved into an empty string.

RandyGaul · 2024-11-22T22:23:59Z

Would also be quite nice to document in the code as comment a rough plan on transitioning to SDL shader tools in the future, explaining how the current SPIRV handling is temporary until SDL evolves more thoroughly.

bullno1 · 2024-11-23T00:18:21Z

Is the shader compiler a standalone program? Which source is it exactly? I didn't want to spend time trawling the cmake file to find out. Is it just cute_shaderc.cpp and associated header?

Yes, it is just src/cute_shader/cute_shaderc.cpp.

Could you outline here what the major individual build targets are exactly and outline their dependencies to each other?

First, all glslang and spriv targets are now unconditionally fetched.

cute-shader is a library that wraps glslang compilation into spirv.
It depends on glslang.

cute-shaderc is a CLI program that can compile glsl to spriv and generate a C header.
It depends on cute-shader.
Notably it is also used to generate src/data/builtin_shaders_bytecode.h with the -type=builtin flag.
Mostly because I didn't want to make another program just for that.
This is done through a add_custom_command so whenever src/cute_shader/builtin_shaders.h is edited, cute-shaderc will get rebuilt and the bytecode header will be regenerated, keeping it in sync.

cute itself always depend on SPIRV tools since it still needs to do reflection even without runtime compilation.
The cute-shader dependency is conditional.

When CF_GLSLANG=OFF it will not link to cute-shader.
All compilation functions just return NULL.
Samples using inline string shader will crash (with a message in stderr).

When CF_GLSLANG=ON it will link to cute-shader.
All compilation functions will call cute_shader_compile.
Include now works with VFS and it will search in the cf_shader_directory if set.
The directory is passed to cute-shader as an include directory, similar to the -I flag in cute-shaderc.

Can the shader compiler be linked in statically into cute.lib or cute.dll (static or dynamic libs, but not as a standalone exe), as a simple cmake option?

Yes. It is the CF_GLSLANG option.

Is this easy for users to toggle on/off in cmake? I want runtime shaders in CF on by default, and behind a single cmake option to turn them off and NOT compile or pull in any SPIRV nonsense. Is that the way things work here as of now?

Not quite yet.
glslang is always pulled because the shader compiler requires that.
I can make it so that cute-shaderc is not built.
Then when CF_GLSLANG=OFF and CF_CUTE_SHADERC=OFF, glslang will not be pulled.

SPIRV-tool is still needed regardless of options because I have only implemented bytecode compilation, not reflection.
I plan to do that next.

Do you have plans yet to add in a dedicated website page for documenting the compiler?

Yes, I can do that.

Can the compiler output serialized SPIRV blobs directly, and not just C headers?

It was possible earlier but I reverted it because draw shader, the most common case, is a couple of shaders.
This can be added back and it will error on cases other than -type=vertex or -type=fragment.
The other values are:

draw: Draw shader, which is actually 2 fragment shaders.
builtin: Dump all builtin shaders, for when runtime compilation is turned off.

I can add a -obytecode= flag.

Can the compiler output reflection info required for passing into SDL_Gpu (various input counts for specific resource sets)?

Not yet.
That should be next in the list.
This will truly get rid of SPIRV and co from cute with CF_GLSLANG=OFF.
With CF_CUTE_SHADERC=OFF they will not even be pulled.

Is the plan to distribute cute-shaderc as a prebuilt binary to save users from the pain?

I'd prefer only one or two samples to use bytecode. The rest should just use runtime shaders alone to reduce complexity.

Sure. I will only make changes to samples that already use shader in file and revert changes from samples with inline shaders.

bullno1 · 2024-11-23T00:30:26Z

Would also be quite nice to document in the code as comment a rough plan on transitioning to SDL shader tools in the future, explaining how the current SPIRV handling is temporary until SDL evolves more thoroughly.

Tbh, I have no idea where SDL shader tool is heading.
This is my reference: https://github.com/libsdl-org/SDL_shader_tools.

I'll add some comment on how it is a temporary solution.
But I think what we can somewhat guarantee is that the API will remain the same.
That includes the compiler and all its flags, the include behaviour etc...

Shader syntax may change depending on what SDL_shader tool is doing.

RandyGaul · 2024-11-23T01:27:02Z

But I think what we can somewhat guarantee is that the API will remain the same.

Thanks! Excellent.

Edit: I'll get to the rest of your updates later.

RandyGaul · 2024-11-23T02:07:32Z

cute itself always depend on SPIRV tools since it still needs to do reflection even without runtime compilation.

If we attach reflection info can we instead cut out SPIRV from CF runtime (other than SPIRV-Cross), unless online shader compilation is required? We can augment the bytecode blob struct with all necessary info. Thoughts? Just a few more structs to store extra reflection info for CF runtime, mainly uniform information.

The shader compiler has all it needs to output prebuilt shaders and setup a little reflection table of information. It could be a static array of structs holding uniform information and counts. CF_ShaderBytecode can store a pointer to the static table for prebuilt shaders. For runtime compilation, the reflection info could be initialized on the stack as-needed for online compilation.

bullno1 · 2024-11-23T02:22:10Z

If we attach reflection info can we instead cut out SPIRV from CF runtime (other than SPIRV-Cross), unless online shader compilation is required? We can augment the bytecode blob struct with all necessary info. Thoughts? Just a few more structs to store extra reflection info for CF runtime, mainly uniform information.

Yes, that's the plan.
My previous comment was about the current state of the PR but I'm heading towards moving all Spirv dependencies (except for SPIRV-Cross) into cute-shader.

RandyGaul · 2024-11-24T04:01:42Z

docs/topics/shader_compilation.md

+
+## Offline compilation
+
+If you have a lot of shaders and want to avoid runtime compilation overhead, CF provides its own offline compiller: `cute-shaderc`.


compiller typo

RandyGaul · 2024-11-24T04:30:12Z

src/cute_shader/cute_shader.h

+#include <stddef.h>
+#include <cute_shader_bytecode.h>
+
+typedef struct cute_shader_define_t {


Could we use CF_ style for structs, and brace on separate line

Sure, for cute shader, it's not really part of CF's public API though. How should I name it:

CF_ShaderDefine: Might clash.

CF_CuteShaderDefine: A bit long but possible.

CSH_Define: CuteShader define.

CS_Define: But CS is already cute_sound

How should I name the functions:

cute_shader_init: The current.

cf_shader_init: May clash with the main CF.

cf_cute_shader_init: A bit long.

csh_init: Sounds like a shell (csh).

I'd say just go with CF_ prefix

RandyGaul · 2024-11-24T04:30:55Z

include/cute_shader_bytecode.h

+ * @brief    Information about an input of a vertex shader.
+ * @related  CF_ShaderBytecode
+ */
+typedef struct CF_ShaderInputInfo {


Separate brace line

RandyGaul · 2024-11-24T04:34:35Z

src/cute_shader/cute_shaderc.cpp

+	SHADER_TYPE_BUILTIN,
+} shader_type_t;
+
+static const char* parse_flag(const char* arg, const char* flag_name) {


Brace on different line

RandyGaul · 2024-11-24T04:35:17Z

Looking quite good, and nice job on the documentation. Let me know when you feel like it's ready for me to pull it down and try things out.

bullno1 · 2024-11-24T05:26:32Z

Except for stylistic changes, which I'll get to later today, there should not be anymore implementation changes.

RandyGaul reviewed Nov 22, 2024

View reviewed changes

bullno1 added 23 commits November 23, 2024 11:26

Move shader compilation to libcute-shader

c5fabda

Fix user shader compilation

22bf4bc

Remove unnecessary include

d2d6598

Make cf_make_shader_from_bytecode more friendly to code generator

6b82fa6

Add cute-shaderc

bb9d6f4

Implement draw shader compilation

9c2ffb3

Fix syntax error in generated header

28534c8

Pre-compile builtin shaders

e43c319

Pre-compile imgui shaders

0dce0ac

Update hello_triangle sample

065f62c

Update shallow_water sample

1b32104

Update recolor sample

a20dec9

Update spaceshooter example

dac1089

Update waves sample

e7cafcb

Update metaballs sample

02465fc

Make CI build both variants of CF_GLSLANG

a29ebd8

Skip uploading artifact for variant without runtime shader compilation

0683724

Ensure that src/data/builtin_shaders_bytecode.h is rebuilt when needed

2efcc74

Simplify hello_triangle sample

7ad0347

Enable PIC in libcute-shader when building CF as a dynamic library

7e90035

Stack allocate the list of builtin includes

faa9a73

Add VFS support in cute-shader

2f356f2

Make the runtime compiler lookup cf_shader_directory for include

11ee711

bullno1 added 8 commits November 23, 2024 11:26

Revert samples which uses inline shader

fd4e5ec

Add preprocessed shader source as comment in generated header

6880179

Style fix

9177ff5

Remove unnecessary dependencies

dc8e3d7

Add reflection info to shader compiler

c274b14

Make CF use reflection info from cute-shader

5ca5439

Make CF and cute-shader share the CF_ShaderBytecode definition

088dcc8

Add extern "C"

327e3f6

bullno1 force-pushed the cute-shader branch from 91a18a5 to 327e3f6 Compare November 23, 2024 19:46

bullno1 added 6 commits November 24, 2024 04:08

Fetching and building of glslang optional

b573c3f

Make workflow use the new options

88ddbd4

Add doc to CF_ShaderInputInfo

5aa7d62

Clean up

36b9087

Add -obytecode= to cute-shaderc to write raw SPIRV blob

2e8c663

Create documentation for changes

45e9115

RandyGaul reviewed Nov 24, 2024

View reviewed changes

bullno1 added 2 commits November 25, 2024 11:56

Typo and wornding in doc

e1b7791

Update coding style to follow CF convention

6972b1e

bullno1 requested a review from RandyGaul November 25, 2024 06:53

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Make runtime shader compilation optional #251

Make runtime shader compilation optional #251

bullno1 commented Nov 22, 2024 •

edited

Loading

RandyGaul left a comment

RandyGaul Nov 22, 2024

bullno1 Nov 22, 2024

RandyGaul Nov 22, 2024

RandyGaul Nov 22, 2024

RandyGaul Nov 22, 2024

bullno1 Nov 22, 2024

RandyGaul Nov 22, 2024

RandyGaul Nov 22, 2024

bullno1 Nov 22, 2024 •

edited

Loading

RandyGaul commented Nov 22, 2024

bullno1 commented Nov 23, 2024 •

edited

Loading

bullno1 commented Nov 23, 2024 •

edited

Loading

RandyGaul commented Nov 23, 2024 •

edited

Loading

RandyGaul commented Nov 23, 2024 •

edited

Loading

bullno1 commented Nov 23, 2024

RandyGaul Nov 24, 2024

RandyGaul Nov 24, 2024

bullno1 Nov 24, 2024 •

edited

Loading

RandyGaul Nov 25, 2024

RandyGaul Nov 24, 2024

RandyGaul Nov 24, 2024

RandyGaul commented Nov 24, 2024

bullno1 commented Nov 24, 2024

		@@ -0,0 +1,36 @@
		#pragma once

		static const uint8_t s_tri_fs_bytecode_content[448] = {


		## Offline compilation

		If you have a lot of shaders and want to avoid runtime compilation overhead, CF provides its own offline compiller: `cute-shaderc`.

Make runtime shader compilation optional #251

Are you sure you want to change the base?

Make runtime shader compilation optional #251

Conversation

bullno1 commented Nov 22, 2024 • edited Loading

RandyGaul left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bullno1 Nov 22, 2024 • edited Loading

Choose a reason for hiding this comment

RandyGaul commented Nov 22, 2024

bullno1 commented Nov 23, 2024 • edited Loading

bullno1 commented Nov 23, 2024 • edited Loading

RandyGaul commented Nov 23, 2024 • edited Loading

RandyGaul commented Nov 23, 2024 • edited Loading

bullno1 commented Nov 23, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bullno1 Nov 24, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

RandyGaul commented Nov 24, 2024

bullno1 commented Nov 24, 2024

bullno1 commented Nov 22, 2024 •

edited

Loading

bullno1 Nov 22, 2024 •

edited

Loading

bullno1 commented Nov 23, 2024 •

edited

Loading

bullno1 commented Nov 23, 2024 •

edited

Loading

RandyGaul commented Nov 23, 2024 •

edited

Loading

RandyGaul commented Nov 23, 2024 •

edited

Loading

bullno1 Nov 24, 2024 •

edited

Loading