ggml-cpu: add F16 input to the FWHT by bri-prism · Pull Request #27779 · ggml-org/llama.cpp

bri-prism · 2026-08-27T01:24:59Z

Overview

The CPU FWHT accepts F32 input only. This change adds F16 input.

ggml_compute_forward_fwht now takes the source type as a template parameter. The CPU path accepts F16 input and F32 input. The CPU MUL_MAT reference converts an F16 src1 to F32 when the caller sets GGML_HINT_SRC0_IS_HADAMARD.

The change touches ggml-cpu only. It is 3 files.

Additional information

This is the first change of a small series. The later changes add F16 kernels to the backends, and add the 1024 and 2048 widths. This change is first because it sets the reference behaviour.

There are no test cases here. No backend has an F16 FWHT kernel yet, so a test would have no backend to compare the CPU result against. The test cases come with the first backend change.

test-backend-ops already has a width-1024 case with the comment too big (N>512). A later change covers that width.

I did not build the CUDA, Metal, or Vulkan backends. This change does not touch them.

Requirements

I have read and agree with the contributing guidelines
AI usage disclosure: YES - I used an AI assistant to write the code and to draft this description. I reviewed every line. I can explain and debug the change without assistance.

ggml-gh-bot · 2026-08-27T01:29:46Z

Hi @bri-prism, thanks for your contribution!

Per our contribution guidelines, the automated PR checker found the following issue(s) that need your attention:

Multiple open PRs from a new contributor: We limit new contributors (those without a previously merged PR) to 1 open PR at a time. You currently have 2 open PRs.
Multiple backend changes in one PR: When adding support for a new model or feature, focus on CPU support only in the initial PR. Add support for other backends like CUDA in follow-up PRs. If you have a good reason to modify multiple backends in one PR, please explain it.

Please note that maintainers reserve the right to make final decisions on PRs. If you believe there is a mistake, please comment below.

bri-prism · 2026-08-27T02:57:40Z

Thanks. I closed the other PR, #26883, so this is now my only open PR. It was obsolete: master already sets cparams.ctx_other and checks the draft context for null in common_speculative_init_result, so both of its changes are already in.

I also reduced the scope of this PR. It was 5 files across two backends. It is now 3 files and touches ggml-cpu only, which matches the title. The Metal part and the test cases move to the follow-up that adds an F16 FWHT kernel to a backend.

bri-prism · 2026-08-28T17:29:41Z

Hi @ggerganov — gentle ping when you have a moment: would you mind taking a look at this PR? Thank you!

The CPU FWHT accepts F32 input only. This change makes the source type a template parameter. The CPU path now accepts F16 input and F32 input. The CPU MUL_MAT reference now converts an F16 src1 to F32. It does this when the caller sets the Hadamard hint. No backend has an F16 FWHT kernel yet. The test cases come with the backend changes that add one.

bri-prism · 2026-09-10T06:31:48Z

Gentle ping on this one.

The PR checker's two items are addressed: this is my only open PR, and the diff is three files under ggml/src/ggml-cpu, so it is CPU-only as requested.

So far only the labeler workflow has run, so I think the build and test workflows still need maintainer approval for a first-time contributor. Happy to rebase onto current master or narrow the scope further if that would help.

ggerganov · 2026-09-10T06:46:32Z

+                    } else {
+                        const ggml_fp16_t * src_f16 = (const ggml_fp16_t *) src1_block;
+                        float * dst_f32 = (float *) dst_block;
+                        for (int64_t i = 0; i < n_block; ++i) {
+                            dst_f32[i] = GGML_CPU_FP16_TO_FP32(src_f16[i]);
+                        }


This is only correct if vec_dot_type == GGML_TYPE_F32. Needs asserts.

Added in b478d66. The F16 branch writes plain floats into wdata, so it needs vec_dot_type == GGML_TYPE_F32; the assert now states that explicitly alongside the existing type check.

ggerganov · 2026-09-10T06:47:07Z

+                        for (int64_t i = 0; i < n_block; ++i) {
+                            dst_f32[i] = GGML_CPU_FP16_TO_FP32(src_f16[i]);
+                        }


There is a faster implementation: ggml_cpu_fp16_to_fp32

Switched to ggml_cpu_fp16_to_fp32 in b478d66. The F32 path still uses from_float unchanged.

Address review feedback. The F16 branch writes plain floats into wdata, which is only correct when vec_dot_type is F32. That invariant held because supports_op only accepts an F16 src1 for the Hadamard hint with F32 src0 and dst, but nothing enforced it. Assert it next to the existing src1 type check so widening supports_op cannot silently break the write. Replace the hand-rolled conversion loop with ggml_cpu_fp16_to_fp32.

Green-Sky · 2026-09-18T08:19:08Z

I'm assuming this is needed to get ternary bonsai 2 27b work started?

I saw you added metadata to your ggufs that says which weights have a rotation applied.

@ggerganov having the ability to apply rotations to the weights in a generic way could benefit every low bit quant for some ~~minor~~ performance overhead. (assuming it does not disable essential fusions that way)

edit: probably not minor. In their whitepaper they say:

Rotation overhead. At batch size 1 the activation-side rotation transform remains one of the
larger non-matrix-multiply costs of a decode step. This is a pure implementation cost with no
bearing on output quality, and it is the most direct remaining lever on on-device decode latency.

khosravipasha · 2026-09-18T18:18:14Z

@Green-Sky Yes, this is for Bonsai-2 and yeah the rotations can help everyone probably :)

Next PR is out: #29094
After that we have few more small PRs per backend (CUDA, Meta, maybe vulkan)

* ggml-cpu: add F16 input to the FWHT The CPU FWHT accepts F32 input only. This change makes the source type a template parameter. The CPU path now accepts F16 input and F32 input. The CPU MUL_MAT reference now converts an F16 src1 to F32. It does this when the caller sets the Hadamard hint. No backend has an F16 FWHT kernel yet. The test cases come with the backend changes that add one. * ggml-cpu: assert the F16 FWHT input path, and use the bulk converter Address review feedback. The F16 branch writes plain floats into wdata, which is only correct when vec_dot_type is F32. That invariant held because supports_op only accepts an F16 src1 for the Hadamard hint with F32 src0 and dst, but nothing enforced it. Assert it next to the existing src1 type check so widening supports_op cannot silently break the write. Replace the hand-rolled conversion loop with ggml_cpu_fp16_to_fp32.

Bonsai 2 stores its weights in a rotated basis and needs a runtime Walsh-Hadamard transform to read them. Stock llama.cpp has no such transform (ggml-org/llama.cpp#27779): it rejects PTQ1_0 and PQ2_0 as unknown ggml types outright, and loads the legacy Q2_0 without complaint while emitting gibberish. The fork carries the ternary hybrid-attention kernels, rebases on upstream and publishes the same asset names, so moving the sidecar to it is a repo swap and nothing more. The two older variants keep working there -- verified by loading Ternary Bonsai 27B on the fork build and generating from it. BONSAI_RELEASE_REPO points fetch-sidecar.sh back at ggml-org for anyone who wants a stock build; everything but Bonsai 2 runs on one. The new entry sits after the older two, so an existing install keeps starting the variant it already has: list order decides the fallback. PQ2_0, the same weights in a looser packing, is offered on macOS only. At the pinned tag the ternary kernels cover it under CUDA and Metal but not Vulkan, and the Linux and Windows bundles are Vulkan builds precisely so they run on AMD and Intel with no CUDA install -- shipping it there would mean a second, NVIDIA-only sidecar. It costs 1.26 GB over PTQ1_0 and buys cheaper unpacking, so it is a real choice where the kernels exist. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* metal: add F16 input to the FWHT The Metal FWHT kernel accepts F32 input only. This change makes the source type a template parameter, so the kernel reads an F16 source directly instead of requiring a converted copy. The F32 instantiations are unchanged. The pipeline name now carries the source type, and supports_op accepts an F16 src1 for the Hadamard hint at the four sizes the kernels cover. Every other F16 src1 path still goes through ggml_metal_supports_mul_mat_op. These are the test cases mentioned in #27779. test-backend-ops on M5 Pro: MUL_MAT_HADAMARD 16/16, MUL_MAT 1265/1265. * metal: ask the same FWHT question in supports_op and the dispatch supports_op admitted an F16 src1 on the type, the hint and the width alone, but the dispatch also requires src1 and dst to be contiguous and the same shape. A Hadamard hinted MUL_MAT that passed the first and failed the second reached the generic path, which has no F32 src0 by F16 src1 kernel, and aborted on a nil pipeline: kernel not found in any metal library: base = 'kernel_mul_mv_f32_f16_4' ggml_metal_encoder_set_pipeline: nil Metal pipeline ggml_metal_use_fwht now holds the whole condition and both callers use it, so they cannot drift apart again. The added test case has src1 and dst of different shapes, which aborted before this change and is declined by the Metal backend after it. * metal: branchless butterfly select in the FWHT simdgroup kernel Review suggestion. Replaces the ternary in the shuffle stages with val2 - val + 2*((lane & i) == 0)*val, which is the same value without the select. Measured on M5 Pro, interleaved A/B, five rounds, first discarded, on a Hadamard matmul with block 512 and 65536 rows so the kernel rather than the launch dominates: 1324.6 us before, 1285.0 us after, a 3.0% gain, and faster in every round. At the shapes already in the perf suite the op runs 1.6 to 3.9 us against a 1.6 us launch floor, so the difference is not visible there. FOR_UNROLL on the same loops was also measured and made no difference, the delta changing sign between rounds, so it is not included. * metal: move the FWHT dispatch predicates to ggml-metal-common Review feedback. ggml_metal_use_fwht and ggml_metal_fwht_supported_size were static inline in ggml-metal-device.h. They now follow the ggml_metal_op_mul_mat_use_mm pattern: declared in ggml-metal-common.h and implemented in ggml-metal-common.cpp, which is already the home for helpers shared between supports_op and the op dispatch. The predicate is named ggml_metal_op_mul_mat_use_fwht to sit alongside the _use_mm pair it parallels. This also fixes the macos-latest-arm64 build. The header needed ggml-impl.h for ggml_get_op_params_i32, but ggml-metal-device.h is reached from tools/tuning through ggml-metal-tuning.h, and that target does not have ggml/src on its include path. ggml-metal-common.cpp already includes ggml-impl.h, so the accessor is used normally there and the header goes back to needing nothing extra. * metal: keep the FWHT size check internal and group the dispatch helpers Applies the patch from the review. ggml_metal_fwht_supported_size becomes static in ggml-metal-common.cpp since nothing outside it needs the size list, which also drops stdint.h from the header again, and ggml_metal_op_mul_mat_use_fwht joins the existing _use_mm declarations under their shared comment instead of carrying its own block. * tests: drop the mismatched-shape Hadamard case I added a case with m != k to cover an abort, but the hint is a promise that src0 is a Hadamard matrix, so src0 is square and dst has the same shape as src1. Every other case in the suite holds to that. The case was not a valid op, and on CPU it compared the FWHT against a real matmul of a non-square src0, which cannot agree. The supports_op and dispatch conditions still come from one predicate, which is what keeps them from disagreeing on contiguity.

* ggml-cpu: add F16 input to the FWHT The CPU FWHT accepts F32 input only. This change makes the source type a template parameter. The CPU path now accepts F16 input and F32 input. The CPU MUL_MAT reference now converts an F16 src1 to F32. It does this when the caller sets the Hadamard hint. No backend has an F16 FWHT kernel yet. The test cases come with the backend changes that add one. * ggml-cpu: assert the F16 FWHT input path, and use the bulk converter Address review feedback. The F16 branch writes plain floats into wdata, which is only correct when vec_dot_type is F32. That invariant held because supports_op only accepts an F16 src1 for the Hadamard hint with F32 src0 and dst, but nothing enforced it. Assert it next to the existing src1 type check so widening supports_op cannot silently break the write. Replace the hand-rolled conversion loop with ggml_cpu_fp16_to_fp32.

* metal: add F16 input to the FWHT The Metal FWHT kernel accepts F32 input only. This change makes the source type a template parameter, so the kernel reads an F16 source directly instead of requiring a converted copy. The F32 instantiations are unchanged. The pipeline name now carries the source type, and supports_op accepts an F16 src1 for the Hadamard hint at the four sizes the kernels cover. Every other F16 src1 path still goes through ggml_metal_supports_mul_mat_op. These are the test cases mentioned in ggml-org#27779. test-backend-ops on M5 Pro: MUL_MAT_HADAMARD 16/16, MUL_MAT 1265/1265. * metal: ask the same FWHT question in supports_op and the dispatch supports_op admitted an F16 src1 on the type, the hint and the width alone, but the dispatch also requires src1 and dst to be contiguous and the same shape. A Hadamard hinted MUL_MAT that passed the first and failed the second reached the generic path, which has no F32 src0 by F16 src1 kernel, and aborted on a nil pipeline: kernel not found in any metal library: base = 'kernel_mul_mv_f32_f16_4' ggml_metal_encoder_set_pipeline: nil Metal pipeline ggml_metal_use_fwht now holds the whole condition and both callers use it, so they cannot drift apart again. The added test case has src1 and dst of different shapes, which aborted before this change and is declined by the Metal backend after it. * metal: branchless butterfly select in the FWHT simdgroup kernel Review suggestion. Replaces the ternary in the shuffle stages with val2 - val + 2*((lane & i) == 0)*val, which is the same value without the select. Measured on M5 Pro, interleaved A/B, five rounds, first discarded, on a Hadamard matmul with block 512 and 65536 rows so the kernel rather than the launch dominates: 1324.6 us before, 1285.0 us after, a 3.0% gain, and faster in every round. At the shapes already in the perf suite the op runs 1.6 to 3.9 us against a 1.6 us launch floor, so the difference is not visible there. FOR_UNROLL on the same loops was also measured and made no difference, the delta changing sign between rounds, so it is not included. * metal: move the FWHT dispatch predicates to ggml-metal-common Review feedback. ggml_metal_use_fwht and ggml_metal_fwht_supported_size were static inline in ggml-metal-device.h. They now follow the ggml_metal_op_mul_mat_use_mm pattern: declared in ggml-metal-common.h and implemented in ggml-metal-common.cpp, which is already the home for helpers shared between supports_op and the op dispatch. The predicate is named ggml_metal_op_mul_mat_use_fwht to sit alongside the _use_mm pair it parallels. This also fixes the macos-latest-arm64 build. The header needed ggml-impl.h for ggml_get_op_params_i32, but ggml-metal-device.h is reached from tools/tuning through ggml-metal-tuning.h, and that target does not have ggml/src on its include path. ggml-metal-common.cpp already includes ggml-impl.h, so the accessor is used normally there and the header goes back to needing nothing extra. * metal: keep the FWHT size check internal and group the dispatch helpers Applies the patch from the review. ggml_metal_fwht_supported_size becomes static in ggml-metal-common.cpp since nothing outside it needs the size list, which also drops stdint.h from the header again, and ggml_metal_op_mul_mat_use_fwht joins the existing _use_mm declarations under their shared comment instead of carrying its own block. * tests: drop the mismatched-shape Hadamard case I added a case with m != k to cover an abort, but the hint is a promise that src0 is a Hadamard matrix, so src0 is square and dst has the same shape as src1. Every other case in the suite holds to that. The case was not a valid op, and on CPU it compared the FWHT against a real matmul of a non-square src0, which cannot agree. The supports_op and dispatch conditions still come from one predicate, which is what keeps them from disagreeing on contiguity.

* ggml-cpu: add F16 input to the FWHT The CPU FWHT accepts F32 input only. This change makes the source type a template parameter. The CPU path now accepts F16 input and F32 input. The CPU MUL_MAT reference now converts an F16 src1 to F32. It does this when the caller sets the Hadamard hint. No backend has an F16 FWHT kernel yet. The test cases come with the backend changes that add one. * ggml-cpu: assert the F16 FWHT input path, and use the bulk converter Address review feedback. The F16 branch writes plain floats into wdata, which is only correct when vec_dot_type is F32. That invariant held because supports_op only accepts an F16 src1 for the Hadamard hint with F32 src0 and dst, but nothing enforced it. Assert it next to the existing src1 type check so widening supports_op cannot silently break the write. Replace the hand-rolled conversion loop with ggml_cpu_fp16_to_fp32.

* metal: add F16 input to the FWHT The Metal FWHT kernel accepts F32 input only. This change makes the source type a template parameter, so the kernel reads an F16 source directly instead of requiring a converted copy. The F32 instantiations are unchanged. The pipeline name now carries the source type, and supports_op accepts an F16 src1 for the Hadamard hint at the four sizes the kernels cover. Every other F16 src1 path still goes through ggml_metal_supports_mul_mat_op. These are the test cases mentioned in ggml-org#27779. test-backend-ops on M5 Pro: MUL_MAT_HADAMARD 16/16, MUL_MAT 1265/1265. * metal: ask the same FWHT question in supports_op and the dispatch supports_op admitted an F16 src1 on the type, the hint and the width alone, but the dispatch also requires src1 and dst to be contiguous and the same shape. A Hadamard hinted MUL_MAT that passed the first and failed the second reached the generic path, which has no F32 src0 by F16 src1 kernel, and aborted on a nil pipeline: kernel not found in any metal library: base = 'kernel_mul_mv_f32_f16_4' ggml_metal_encoder_set_pipeline: nil Metal pipeline ggml_metal_use_fwht now holds the whole condition and both callers use it, so they cannot drift apart again. The added test case has src1 and dst of different shapes, which aborted before this change and is declined by the Metal backend after it. * metal: branchless butterfly select in the FWHT simdgroup kernel Review suggestion. Replaces the ternary in the shuffle stages with val2 - val + 2*((lane & i) == 0)*val, which is the same value without the select. Measured on M5 Pro, interleaved A/B, five rounds, first discarded, on a Hadamard matmul with block 512 and 65536 rows so the kernel rather than the launch dominates: 1324.6 us before, 1285.0 us after, a 3.0% gain, and faster in every round. At the shapes already in the perf suite the op runs 1.6 to 3.9 us against a 1.6 us launch floor, so the difference is not visible there. FOR_UNROLL on the same loops was also measured and made no difference, the delta changing sign between rounds, so it is not included. * metal: move the FWHT dispatch predicates to ggml-metal-common Review feedback. ggml_metal_use_fwht and ggml_metal_fwht_supported_size were static inline in ggml-metal-device.h. They now follow the ggml_metal_op_mul_mat_use_mm pattern: declared in ggml-metal-common.h and implemented in ggml-metal-common.cpp, which is already the home for helpers shared between supports_op and the op dispatch. The predicate is named ggml_metal_op_mul_mat_use_fwht to sit alongside the _use_mm pair it parallels. This also fixes the macos-latest-arm64 build. The header needed ggml-impl.h for ggml_get_op_params_i32, but ggml-metal-device.h is reached from tools/tuning through ggml-metal-tuning.h, and that target does not have ggml/src on its include path. ggml-metal-common.cpp already includes ggml-impl.h, so the accessor is used normally there and the header goes back to needing nothing extra. * metal: keep the FWHT size check internal and group the dispatch helpers Applies the patch from the review. ggml_metal_fwht_supported_size becomes static in ggml-metal-common.cpp since nothing outside it needs the size list, which also drops stdint.h from the header again, and ggml_metal_op_mul_mat_use_fwht joins the existing _use_mm declarations under their shared comment instead of carrying its own block. * tests: drop the mismatched-shape Hadamard case I added a case with m != k to cover an abort, but the hint is a promise that src0 is a Hadamard matrix, so src0 is square and dst has the same shape as src1. Every other case in the suite holds to that. The case was not a valid op, and on CPU it compared the FWHT against a real matmul of a non-square src0, which cannot agree. The supports_op and dispatch conditions still come from one predicate, which is what keeps them from disagreeing on contiguity.

* metal: add F16 input to the FWHT The Metal FWHT kernel accepts F32 input only. This change makes the source type a template parameter, so the kernel reads an F16 source directly instead of requiring a converted copy. The F32 instantiations are unchanged. The pipeline name now carries the source type, and supports_op accepts an F16 src1 for the Hadamard hint at the four sizes the kernels cover. Every other F16 src1 path still goes through ggml_metal_supports_mul_mat_op. These are the test cases mentioned in ggml-org#27779. test-backend-ops on M5 Pro: MUL_MAT_HADAMARD 16/16, MUL_MAT 1265/1265. * metal: ask the same FWHT question in supports_op and the dispatch supports_op admitted an F16 src1 on the type, the hint and the width alone, but the dispatch also requires src1 and dst to be contiguous and the same shape. A Hadamard hinted MUL_MAT that passed the first and failed the second reached the generic path, which has no F32 src0 by F16 src1 kernel, and aborted on a nil pipeline: kernel not found in any metal library: base = 'kernel_mul_mv_f32_f16_4' ggml_metal_encoder_set_pipeline: nil Metal pipeline ggml_metal_use_fwht now holds the whole condition and both callers use it, so they cannot drift apart again. The added test case has src1 and dst of different shapes, which aborted before this change and is declined by the Metal backend after it. * metal: branchless butterfly select in the FWHT simdgroup kernel Review suggestion. Replaces the ternary in the shuffle stages with val2 - val + 2*((lane & i) == 0)*val, which is the same value without the select. Measured on M5 Pro, interleaved A/B, five rounds, first discarded, on a Hadamard matmul with block 512 and 65536 rows so the kernel rather than the launch dominates: 1324.6 us before, 1285.0 us after, a 3.0% gain, and faster in every round. At the shapes already in the perf suite the op runs 1.6 to 3.9 us against a 1.6 us launch floor, so the difference is not visible there. FOR_UNROLL on the same loops was also measured and made no difference, the delta changing sign between rounds, so it is not included. * metal: move the FWHT dispatch predicates to ggml-metal-common Review feedback. ggml_metal_use_fwht and ggml_metal_fwht_supported_size were static inline in ggml-metal-device.h. They now follow the ggml_metal_op_mul_mat_use_mm pattern: declared in ggml-metal-common.h and implemented in ggml-metal-common.cpp, which is already the home for helpers shared between supports_op and the op dispatch. The predicate is named ggml_metal_op_mul_mat_use_fwht to sit alongside the _use_mm pair it parallels. This also fixes the macos-latest-arm64 build. The header needed ggml-impl.h for ggml_get_op_params_i32, but ggml-metal-device.h is reached from tools/tuning through ggml-metal-tuning.h, and that target does not have ggml/src on its include path. ggml-metal-common.cpp already includes ggml-impl.h, so the accessor is used normally there and the header goes back to needing nothing extra. * metal: keep the FWHT size check internal and group the dispatch helpers Applies the patch from the review. ggml_metal_fwht_supported_size becomes static in ggml-metal-common.cpp since nothing outside it needs the size list, which also drops stdint.h from the header again, and ggml_metal_op_mul_mat_use_fwht joins the existing _use_mm declarations under their shared comment instead of carrying its own block. * tests: drop the mismatched-shape Hadamard case I added a case with m != k to cover an abort, but the hint is a promise that src0 is a Hadamard matrix, so src0 is square and dst has the same shape as src1. Every other case in the suite holds to that. The case was not a valid op, and on CPU it compared the FWHT against a real matmul of a non-square src0, which cannot agree. The supports_op and dispatch conditions still come from one predicate, which is what keeps them from disagreeing on contiguity. (cherry picked from commit 9a9f939)

bri-prism requested review from a team and ggerganov as code owners August 27, 2026 01:25

github-actions Bot added testing Everything test related ggml changes relating to the ggml tensor library for machine learning Apple Metal https://en.wikipedia.org/wiki/Metal_(API) labels Aug 27, 2026

bri-prism force-pushed the up-fwht-f16-cpu branch from a30afab to 8e596f9 Compare August 27, 2026 02:46

bri-prism mentioned this pull request Sep 3, 2026

ggml-cpu: restore the src1 guard on the F16 Hadamard matmul path PrismML-Eng/llama.cpp#147

Merged

bri-prism force-pushed the up-fwht-f16-cpu branch from 8e596f9 to cc3c259 Compare September 10, 2026 06:40

ggerganov reviewed Sep 10, 2026

View reviewed changes

ggerganov approved these changes Sep 18, 2026

View reviewed changes

ggerganov added the merge ready A maintainer can use this label to indicate that they consider the changes final and ready to merge. label Sep 18, 2026

ggerganov merged commit 4fea119 into ggml-org:master Sep 18, 2026
23 of 29 checks passed

khosravipasha mentioned this pull request Sep 18, 2026

ggml : add PQ2_0 and PTQ1_0 ternary types; llama : apply Hadamard-folded weights #29077

Closed

This was referenced Sep 18, 2026

metal: add F16 input to the FWHT #29094

Merged

cuda: add F16 input to the FWHT #29096

Merged

bri-prism mentioned this pull request Sep 18, 2026

vulkan: add F16 input to the FWHT #29101

Draft

ggerganov mentioned this pull request Sep 23, 2026

ggml : bump version to 0.25.0 ggml-org/ggml#1635

Merged

BrewTestBot mentioned this pull request Sep 23, 2026

ggml 0.25.0 Homebrew/homebrew-core#313051

Merged

1 task done

Navigation Menu

Repository navigation

ggml-cpu: add F16 input to the FWHT - #27779

ggml-cpu: add F16 input to the FWHT#27779
ggerganov merged 2 commits into
ggml-org:masterfrom
PrismML-Eng:up-fwht-f16-cpu

bri-prism commented Aug 27, 2026 •

edited

Loading

Uh oh!

ggml-gh-bot Bot commented Aug 27, 2026

Uh oh!

bri-prism commented Aug 27, 2026

Uh oh!

bri-prism commented Aug 28, 2026

Uh oh!

bri-prism commented Sep 10, 2026

Uh oh!

ggerganov Sep 10, 2026 •

edited

Loading

Uh oh!

bri-prism Sep 11, 2026

Uh oh!

ggerganov Sep 10, 2026

Uh oh!

bri-prism Sep 11, 2026

Uh oh!

Green-Sky commented Sep 18, 2026 •

edited

Loading

Uh oh!

Uh oh!

khosravipasha commented Sep 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

bri-prism commented Aug 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Overview

Additional information

Requirements

Uh oh!

ggml-gh-bot Bot commented Aug 27, 2026

Uh oh!

bri-prism commented Aug 27, 2026

Uh oh!

bri-prism commented Aug 28, 2026

Uh oh!

bri-prism commented Sep 10, 2026

Uh oh!

ggerganov Sep 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bri-prism Sep 11, 2026

Choose a reason for hiding this comment

Uh oh!

ggerganov Sep 10, 2026

Choose a reason for hiding this comment

Uh oh!

bri-prism Sep 11, 2026

Choose a reason for hiding this comment

Uh oh!

Green-Sky commented Sep 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

khosravipasha commented Sep 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

bri-prism commented Aug 27, 2026 •

edited

Loading

ggerganov Sep 10, 2026 •

edited

Loading

Green-Sky commented Sep 18, 2026 •

edited

Loading