What is the policy with respect to updating libggml the current upstream release?

[shakfu]

There is currently a version gap with respect to libggml: SD uses ggml 0.9.5, llama.cpp and whisper.cpp are on 0.9.8.

• Is is a project objective to catch up with changes in upstream libggml?

• is it a project objective to keep SD's libggml consistent with upstream libggml?

I ask these questions because I integrate all three libraries in my cyllama project, and I've had to include different ggml versions to SD from the llama.cpp/whisper.cpp. Also concerned that upstream bug fixes may not propagate to SD so readily if it keeps its owned vendored copy of ggml or if the gap widens.

S

[shakfu]

I see that there is a SD_USE_SYSTEM_GGML CMake option for using system ggml, so perhaps there is an intent to keep in sync with upstream ggml.

I'll test this out in my own project.

[wbruna]

FWIW, Koboldcpp tracks ggml as part of llama.cpp, so we usually find issues before they reach the ggml repository. I can't really say about whisper.cpp, but stable-diffusion.cpp should work fine with more recent versions with a few changes; I'm keeping track at #1371 .

[shakfu]

Thanks @wbruna

stable-diffusion.cpp should work fine with more recent versions with a few changes

I’ve confirmed this as well and have built all three (llama.cpp, whisper.cpp, and stable-diffusion.cpp) to dynamically link to ggml version 0.9.8 in my current dev branch.

As ggml moves toward 1.0.0 and beyond, it seems likely that the dependency will become more stable.