Things arrived in the mail today! With luck, I'll have the server for the bot set up this weekend :D
winders is upturdating!
a hitch in my plan: opening a complicated model on a windows 11 vm running on half a CPU core on a potato takes a hot minute to compile a few hundred shaders 🙃
another hitch in my plan is my RSI is flaring up tonight :|
this is the problem model in the first image. each color is a different shader that had to be generated by tangerine to render the voxel, and the average complexity of the generated shaders is also high.
the second image is the generated part for one of the these shaders. its basically the object structure w/ all the params pulled out.
it's basically half way to being an interpreter, i'd just need to also pull the call structure out into a parameter buffer, and replace the function with an interpreter loop. it would be slower than rendering with all of the compiled shaders, but it only needs to produce one frame for the bot
incidentally this happens to also be my plan for how to deal with shader compiler hitches in general, i've just been procrastinating on it because opengl doesn't believe in async shader compiling
@aeva You could try compiling to SPIR-V in a separate thread, that way the driver only has to go from bytecode to machine code.
https://www.khronos.org/opengl/wiki/SPIR-V#Shader_compilation
@lh0xfb also does SPIRV let you turn off optimizations?
I use shaderc:
https://github.com/google/shaderc
It has several options, like optimization level, source language, and target environment (I'm using HLSL + vulkan).
It's shipped as part of the vulkan SDK, so I just LoadLibrary and load its functions to use from C.
There's also glslang:
https://github.com/KhronosGroup/glslang
Also dxc can compile hlsl to dxil or spir-v:
https://github.com/microsoft/DirectXShaderCompiler
@lh0xfb thanks, i will keep this in mind ♡
I am not 100% sure, but it looks like it would not be a huge undertaking if you are already using GL3.3 core.
There are some code snippets on the GL wiki linked above, it looks pretty trivial to change the cpu code side.
@lh0xfb i'm targeting 4.2 with some extensions. i don't think i'm using anything particularly exotic
@aeva That should be fine; I think the main requirement is explicit attribute and binding locations, so that everything links together consistently.
@aeva Basically this subheading: https://www.khronos.org/opengl/wiki/SPIR-V#Mapping_to_GLSL
@lh0xfb ah! i'm already doing that anyway since it makes the gl side simpler
Here's a site where someone shared their before / after of converting their GLSL shader over to work with SPIR-V: https://eleni.mutantstargoat.com/hikiko/opengl-spirv/
I think it may also affect your cpu code with regard to relying on GL to perform reflection on your shader, eg. to find the binding id of a uniform. With SPIR-V you'd instead need to know which binding id you want to update.
It's still a hell of a lot simpler than vulkan, where you have to also provide even more info about *everything* and do descriptor set allocation, writes, and lifetime / state management such that descriptors are not modified while the gpu is using them.
I do the laziest/simplest thing possible, where I only have one global descriptor set per frame, I update it once before any rendering is done, and reclaim it a couple frames later.
https://github.com/gheshu/pim/blob/master/src/rendering/vulkan/vkr_bindings.c
https://github.com/gheshu/pim/blob/master/src/rendering/vulkan/vkr_desc.c
https://github.com/gheshu/pim/blob/master/src/shaders/bindings.hlsl
@lh0xfb oooooo wonderful
@lh0xfb how much of an undertaking is it to convert from gl/glsl to spirv/glsl?