[Feature Request] Compute Shader Support

[DillonHHH]

It would be great if this lsp supported compute shaders.

As of now, the #[compute] hint results in "shader_type missing" and having more than one layout shows "Redefinition of variable 'buffer' in the same scope" for each layout after the first.

[scump1]

Compue shaders in godot use raw GLSL. I have restrained from this for now, as i would basically need to implement a language server for GLSL in parallel to the gdshader language.

Furthermore, the developers of godot mentioned an active implemrntarion in gdshader language for compute shaders (shader_type compute).

I will look into the best way to handle this for now.

[DillonHHH]

Compue shaders in godot use raw GLSL. I have restrained from this for now, as i would basically need to implement a language server for GLSL in parallel to the gdshader language.

However, there also seems to be a lack of active development on the GLSL lsp side. I'll look into it.

For now I've downloaded the latest release from shader-sense.

As long as I name my files with a .comp.glsl extension, shader-sense and Godot will both recognize them properly. This is the only solution I've found to have full glsl lsp support (though I probably could just use glslang directly, I'm not willing to mess with it if it works for now). I have to add // \ at the top of the file to avoid errors due to the #[compute] hint, but otherwise it works pretty well so far.

As far as I can tell, they're just using glslang-rs under the hood, which is just a set of Rust bindings for glslang which is implemented in C++, so that may be a good place to start. I have no experience in lsp development, so can't propose a solution to this, sorry.

[scump1]

Thanks for sharing that workaround!

You are right about glslang being a key tool here, but to give some context on how it fits in: what glslang actually does is translate your shader unit into an AST (Abstract Syntax Tree). This is the foundation of every LSP. Currently, gdshader-lsp does the exact same thing — translating your .gdshader files into an AST.

The real magic of an LSP happens afterwards (although building the AST is hard enough on its own!). All the nice quality-of-life things like autocompletion, type checking, hover hints, and more require actually having programmatic access to the rules of the language that make up the AST.

So, while glslang can parse/compile your shader units and spit out errors, it doesn't provide the actual features of an LSP out of the box. I would still have to build all of that language server logic for GLSL in parallel to gdshader.

Moving forward, I see two paths for this issue:

1. Short-term: I start adapting my current LSP backbone to parse Godot's specific flavor of compute GLSL as a secondary dialect; or atleast to not annoy you with error messages.
2. Long-term: We wait for Godot upstream to officially merge shader_type compute into the native .gdshader language, at which point adding support here becomes trivial.

[DillonHHH]

Since there are other options we can use for the compute shaders for now, I'd say the work to adapt it probably isn't worth it if Godot will have shader_type compute anytime soon. Thanks for making this lsp!