ggml-hrx: HIP kernels through HRX (plumbing + add-on hook)

[bong-water-water-bong]

Lets HRX run hipcc code objects as ggml-hrx kernels, beside the Loom kernels, and lets an external kernel add-on plug in at build time. Draft: do not merge yet. The engine release is on hold.

• 616034b HIP plumbing:
  • Build: hip/ggml-hrx-hip.cmake compiles hip/kernels/*.hip with amdclang++ into raw code objects per GGML_HRX_HIP_TARGETS (default gfx1151) and embeds them in the library.
  • Runtime: hip-kernel-registry (a HipKernel description becomes a KernelDefinition in family hip), and hip-kernel-loader (the executable cache loads the embedded object instead of a Loom compile).
  • Matchers: registered in one place, hip-dispatches.cpp.
  • Docs and tests: README.md with the recipe; example hip_scale_f32 with its matcher (opt-in GGML_HRX_HIP_EXAMPLE_SCALE=1); the ggml-hrx-hip-smoke tool.
  • AMD files: one-line hooks only.
• 8719cf4 add-on hook:
  • GGML_HRX_HIP_ADDON_DIR=<dir> adds <dir>/kernels/*.hip to the code-object build and compiles <dir>/*.cpp/*.h into ggml-hrx with GGML_HRX_HIP_ADDON defined.
  • It includes <dir>/addon.cmake if present and calls ggml_hrx_hip_addon_register(registry).
  • Generic attention-sink extension point: set_hip_attention_sink_hook. The dispatch falls back to Loom when no hook is set.
• d5de4b1: three MUL_MAT_VEC_FUSION cases (one-token Q4_K/Q5_K gate/up + SwiGLU at outputs 128/384).

Checks on strixhalo (gfx1151), performance mode:

• Without an add-on: ggml-hrx-hip-smoke PASS; test-backend-ops -o SCALE -b HRX0 4/4 on 3 runs with hip.scale_f32 matched, and 4/4 with the example off.
• With an add-on, against the same kernels built in-tree:
  • the same matchers register (identical counts) on Qwen3-8B, GLM-4.7-Flash, ZAYA1-8B and Qwen3.6-35B;
  • llama-bench pp512/tg128 are within noise;
  • MUL_MAT 325/325, MUL_MAT_ID 108/108, MUL_MAT_VEC_FUSION 57/57, CONCAT 6/6.

🤖 Generated with Claude Code

[bong-water-water-bong]

Added 3527b56 ggml-hrx: HIP matchers can declare the ops they claim (hip/hip-capabilities).

supports_op only hands a node to the dispatcher when eager_capability_declared lists its op, so a HIP matcher for an op outside that list could never fire. New hip/hip-capabilities.{h,cpp}: a matcher calls hip_declare_eager_op(op) from its register_* function while the registry is built; eager_capability_declared consults the set in its default branch (one line in ggml-hrx.cpp). hip_eager_op_declared builds the registries on first use so the set is filled before the scheduler's first probe. With no declaring matcher the set is empty and nothing changes; the public tree names no add-on op.