GitLab

Load dynamic cpu lib on windows

On linux, we link the CPU library in to the Go app and fall back to it
when no GPU match is found. On windows we do not link in the CPU library
so that we can better control our dependencies for the CLI.  This fixes
the logic so we correctly fallback to the dynamic CPU library
on windows.

* update cmake flags for intel macOS

* remove `LLAMA_K_QUANTS`

* put back `CMAKE_OSX_DEPLOYMENT_TARGET` and disable `LLAMA_F16C`

Improve maintainability of Radeon card list

Fail fast on WSL1 while allowing on WSL2

Fix CPU only builds

Go embed doesn't like when there's no matching files, so put
a dummy placeholder in to allow building without any GPU support
If no "server" library is found, it's safely ignored at runtime.

This prevents users from accidentally installing on WSL1 with instructions
guiding how to upgrade their WSL instance to version 2.  Once running WSL2
if you have an NVIDIA card, you can follow their instructions to set up
GPU passthrough and run models on the GPU.  This is not possible on WSL1.

This moves the list of AMD GPUs to an easier to maintain list which
should make it easier to update over time.

Add ollama user to render group for Radeon support

For the ROCm libraries to access the driver, we need to add the ollama user
to the render group.

Fix windows system memory lookup

This refines the gpu package error handling and fixes a bug with the
system memory lookup on windows.

Refactor how we augment llama.cpp and refine windows native build

This one log line was triggering a single line llama.log to be generated
in the pwd of the server

Refactor where we store build outputs, and support a fully dynamic loading
model on windows so the base executable has no special dependencies thus
doesn't require a special PATH.

This changes the model for llama.cpp inclusion so we're not applying a patch,
but instead have the C++ code directly in the ollama tree, which should make it
easier to refine and update over time.

Guard integration tests with a tag