Repository navigation
meta : handle host views - #30217
meta : handle host views#30217
Conversation
|
@JohannesGaessler PTAL when you have some time and let me know if this changes looks OK to you. |
|
Related PR by @yomaytk : #28075 . I'll take a look at this PR as well but the fundamental issue as I see it is that the backend scheduler is assigning backend IDs in contradiction of what the ggml backend API says should be supported in terms of buffer types. So my understanding is that this is a bug in the ggml backend scheduler that is simply surfacing through the meta backend. |
JohannesGaessler
left a comment
There was a problem hiding this comment.
Okay, I think I misunderstood what this PR attempts to do. Still, in my view the fundamental issue is that there are seemingly unrelated tensors in the graph's nodes that don't actually do anything.
|
My opinion is that we can merge something like this as an ad-hoc fix but please add a TODO that going forward we should look into a better solution. |
A view shares the memory of its view_src, so ggml-alloc never allocates a view in the buffer of the split it lands in - the scheduler copies the source into the split and the ops that use the view read that copy. The view node itself is a noop and does not need a split of its own, but the meta backend asserted when one was left inside a meta split: - ggml_backend_meta_get_split_state() dereferenced tensor->buffer->context - the graph rebuild mapped every node with ggml_backend_meta_buffer_simple_tensor() Accept such nodes when they are views of host tensors, which also generalizes the previous s_copy_main workaround. This fixes the assert hit by KV cache views when using --split-mode tensor with partial offload. Assisted-by: pi:llama.cpp/Qwen3.8-Flash-Next
27a975a to
ba2454e
Compare
|
I added a TODO in the latest commit. |
* meta : handle views of tensors allocated on the host A view shares the memory of its view_src, so ggml-alloc never allocates a view in the buffer of the split it lands in - the scheduler copies the source into the split and the ops that use the view read that copy. The view node itself is a noop and does not need a split of its own, but the meta backend asserted when one was left inside a meta split: - ggml_backend_meta_get_split_state() dereferenced tensor->buffer->context - the graph rebuild mapped every node with ggml_backend_meta_buffer_simple_tensor() Accept such nodes when they are views of host tensors, which also generalizes the previous s_copy_main workaround. This fixes the assert hit by KV cache views when using --split-mode tensor with partial offload. Assisted-by: pi:llama.cpp/Qwen3.8-Flash-Next * archs : re-enable sm tensor for K2 Horizon * cont : add TODO and reference
* meta : handle views of tensors allocated on the host A view shares the memory of its view_src, so ggml-alloc never allocates a view in the buffer of the split it lands in - the scheduler copies the source into the split and the ops that use the view read that copy. The view node itself is a noop and does not need a split of its own, but the meta backend asserted when one was left inside a meta split: - ggml_backend_meta_get_split_state() dereferenced tensor->buffer->context - the graph rebuild mapped every node with ggml_backend_meta_buffer_simple_tensor() Accept such nodes when they are views of host tensors, which also generalizes the previous s_copy_main workaround. This fixes the assert hit by KV cache views when using --split-mode tensor with partial offload. Assisted-by: pi:llama.cpp/Qwen3.8-Flash-Next * archs : re-enable sm tensor for K2 Horizon * cont : add TODO and reference
Overview
ref: #29535 (comment)
My analysis is that views of host-buffer tensors can end up assigned into the meta backend splits. This usually happens when we perform some reshape of the extracted token embeddings before using them:
I tried to modify the scheduler to prevent that (i.e. always keep the reshapes/views in the host split), but it gets a bit tricky since we don't have a guarantee where the reshapes/views nodes will end up in the graph - they are not always arranged next to the host ops (GET_ROWS in this case) depending on what other ops are performed before the
rescomputation.I don't see a reason why the meta backend cannot just ignore these nodes. After all, they don't cause any problem with other backends, so it seems something that should be fixed in the Meta backend. There is already a related FIXME comment. This PR extends the logic to handle this.
Additional information
The K2 Horizon model can now be used with
-sm tensor. This is also helps with a follow-up refactoring in #30160 .Requirements