-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add a lib-shdc? #34
Comments
Yeah I think that should work and wouldn't be too complicated (both as DLL or static link library, or with a bit of tinkering even as a WASM module). It won't be small though (the DLL will probably be between 5..6 MBytes, or in case of a static lib, add that much to the executable). What's needed is an "API header/source pair" which defines a C library API and maybe move some code from main.cc into a common source used both by the sokol-shdc exe and the library. Ideally the sokol-shdc executable would use the same library API internally too (I'd prefer this because then the library API is automatically tested by the sokol-shdc executable). I had something similar in mind but for a different use case: eventually I want to get rid of the precompiled binaries in https://github.com/floooh/sokol-tools-bin and want to have a solution where the bulk of the shader compiler is compiled to WASM and then executed through some WASI-launcher, I think this would also benefit from having the core functionality wrapped in a separate library. I'll see if I can start tinkering on this 'soon-ish' (want to do some smaller things first). |
Also define callback functions for basic file operations (open, read, write, seek, tell ,close). If not defined, use the standard ones. |
Picking this back up — would also really like this. I'm binding Sokol headers to an external language (C#) for an engine, and being able to have runtime compilation of shaders (and also abstract away the process to end-users) would definitely be ideal. I think something as simple as "pass in a glsl file and get back the shader in the target lang + uniforms in some info struct"would be great, don't need any of the header generation stuff. Right now my plan was to ship shdc and invoke it as an external process and capture the output. A DLL would definitely be more ideal. |
Would it be possible to get some guidance on implementing a library for shdc? It seems a bit low priority for @floooh so perhaps I could take a stab at it. I’ve also wanted to compile shaders at runtime so they can be easily hotloaded, and to simplify build steps by not requiring build time shader compilation. |
There's a couple of fairly simple steps, and one I don't know how to solve :)
...and now the tricky part: D3D and Metal byte code generation (which might be out of scope):
Both might not be an option (but maybe also not required?) for sokol-shdc as a library, so maybe this can simply be ignored (since at one point, shader source code needs to be compiled anyway, and this can just as well happen in sokol_gfx.h). If anybody wants to tackle this, I would prefer it as a number of smaller PRs instead of a single big one, for instance:
|
Correct me if I'm wrong but bytecode generation would be the thing that would make the library most useful. Especially in terms of hotloading shaders, there would need to be some compile step as part of library functionality to actually consume the shaders, otherwise the library would only be about producing .c versions of the shaders, correct? For me, the bytecode generation bit would definitely be the thing worth doing. Though I'm also not good enough (for now!) to actually build this func and would mostly be a consumer of whatever anyone else does until I could contribute to it. |
I've been creating my own library for a while now. The way I've done it revolves around making minimal changes to the shdc codebase to make it easier to maintain. The library can use either a filename or a pointer to the source code. If you're interested in seeing the strategy I've used, you can find it here: https://gist.github.com/rcases/8f65e7d54b2556fea60bc138af6cdb0d |
No, there would be no code generation step, you would get GLSL, HLSL, MSL and WGSL source code as strings which you can feed into sokol-gfx in the How to deal with reflection is indeed an interesting question though. One 'naive' way would be to have a new function which directly returns a populated A cleaner way would be to have a new 'user-friendly' reflection struct which makes it easy to build a |
Ah thanks for the clarification!
One possible option here could be to provide a header similar to sokol_glue.h that acts as a go-between when both gfx and the (not yet existent) sokol_shdc.h are present that can return a populated |
Being able to recompile shaders at run-time is a thing I would like in my sokol projects.
sokol-shdc has done a wonderful job of wrapping the
glslang
andSPIRV-cross
libs. Would it be feasible to write a C API for a sokol-shdc.dll that, given some shader source, fills the appropriate sokol shader description structs?The text was updated successfully, but these errors were encountered: