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.
@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.
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.
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.
the mastodon instance at cybre.space is retiring
see the end-of-life plan for details: https://cybre.space/~chr/cybre-space-eol