1. 首页
  2. 问答
  3. [ggerganov/llama.cpp]通过放宽 constness 来修复 ROCM 构建

[ggerganov/llama.cpp]通过放宽 constness 来修复 ROCM 构建

2024-07-05 829 views
9

至少在我的系统上，这个改变对于使用 ROCM 进行构建似乎是必要的。

ggml-cuda.cu:7370:9: error: no matching function for call to 'hipblasGemmBatchedEx'
        cublasGemmBatchedEx(g_cublas_handles[id], CUBLAS_OP_T, CUBLAS_OP_N,
        ^~~~~~~~~~~~~~~~~~~
ggml-cuda.cu:32:29: note: expanded from macro 'cublasGemmBatchedEx'
#define cublasGemmBatchedEx hipblasGemmBatchedEx
                            ^~~~~~~~~~~~~~~~~~~~
ggml-cuda.cu:209:32: note: expanded from macro 'CUBLAS_CHECK'
        cublasStatus_t err_ = (err);                                                    \
                               ^~~
/opt/rocm/include/hipblas/hipblas.h:18459:32: note: candidate function not viable: 11th argument ('const void *const *') would lose const qualifier
HIPBLAS_EXPORT hipblasStatus_t hipblasGemmBatchedEx(hipblasHandle_t    handle,

类似于之前被“接受”的改变......

KerfuffleV2

回答

7

我们能否以不产生警告的方式来做到这一点？

slaren

3

我们能否以不产生警告的方式来做到这一点？

上面的代码会(const char *)产生类似的警告。编译该文件实际上会给我产生 10 页的警告。

您对不会引起警告的方法有什么建议吗？

KerfuffleV2

3

这仍然是使用 ROCM 进行编译所必需的。我检查了最新的更改。

KerfuffleV2

5

目前，ggml-cuda.cu使用 CUDA 12.3 和 GCC 12.3.0 进行构建不会生成任何警告。这会重新添加我在 #3891 中删除的两个警告。我猜您看到的警告仅在使用 ROCM 进行构建时才会发生。如果我们无法找到一种方法来同时修复 CUDA 和 ROCM 的这个问题，那么我想我们可以忍受这些警告，但如果没有它们就更好了。

slaren

6

我想象您看到的警告仅在使用 ROCM 构建时才会发生。

据我所知，ROCM 的“nvcc”是 clang。如果你使用 clang 构建，你可能会看到我提到的大量警告垃圾邮件。

如果我们不能找到一种方法来修复 CUDA 和 ROCM 的问题

不幸的是，这有点超出我的能力范围。我瞎折腾了一阵子，还是没找到解决办法。HIPBLAS 函数的const void **前两个指针和void **第三个指针都需要一个。

我觉得（可能错了）这与我们所说的一块内存既是 const 又是 not 有关？但如果是这样的话，那么你必须 malloc 多个内存块，但据我所知，分配会带来不小的性能成本。

KerfuffleV2

3

我认为，如果我们回到 2 个带有指针的独立数组而不是 1 个数组，我们可以修复警告。第一个数组将保存 const src 指针，第二个数组将保存 dst 指针。如果 @KerfuffleV2 无法弄清楚，我稍后会尝试一下。

ggerganov

9

说实话，我对此一无所知，只是我的改动让它可以编译。我真的不太了解重构实际代码。

我们可以暂缓合并，希望真正了解自己在做什么的人能提供更好的解决方案。最坏的情况是，这个拉动可用。不过最好不要让它坏太久。所有 7 位 ROCM 用户都会很难过！

KerfuffleV2

7

这是警告：

/home/cebtenzzre/src/forks/llama.cpp/ggml-cuda.cu: In function ‘void ggml_cuda_mul_mat_mat_batched_cublas(const ggml_tensor*, const ggml_tensor*, ggml_tensor*)’:
/home/cebtenzzre/src/forks/llama.cpp/ggml-cuda.cu:7369:126: warning: cast from type ‘void**’ to type ‘const void**’ casts away qualifiers [-Wcast-qual]
 7369 |         CUBLAS_CHECK(
      |                                                                                                                              ^                                    
/home/cebtenzzre/src/forks/llama.cpp/ggml-cuda.cu:7369:198: warning: cast from type ‘void**’ to type ‘const void**’ casts away qualifiers [-Wcast-qual]
 7369 |         CUBLAS_CHECK(
      |                                                                                                                                                                                                      ^

这是因为强制转换为const void **允许您稍后通过存储来取消 const 一个指针，然后通过 在没有 const 的情况下检索它。const void *const void **void **

hipBLAS API 似乎确实要求将 const 指针和非 const 指针存储在单独的数组中，因为没有安全的方法来在这些类型之间进行转换。

cebtenzzre

1

我们可以-Wcast-qual从编译器标志中删除它。

slaren

3

我们可以-Wcast-qual从编译器标志中删除它。

如果我们这样做，我宁愿只对代码的这一部分执行如下操作：


#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wcast-qual"
// offending code here
#pragma GCC diagnostic pop

cebtenzzre

9

您能详细说明一下为什么您认为这个警告很重要吗？除了承认 C 类型系统的缺陷之外，抱怨将非 const 指针转换为 const 有什么价值？我非常希望不要在代码中充斥与代码无关的指令。这也不是第一次发生，由于这个警告，我几乎放弃了尝试使 ggml 哈希表至少在某种程度上符合 const 要求。

slaren

0

我猜他想说的是，这可能并不总是无用的警告。大概有人认为值得将其添加到编译器中以警告用户。因此，如果它被全局禁用，也许一些错误会漏掉，否则可能会被发现 - 即使在这个特定情况下它是良性的。

稍微扮演一下魔鬼代言人的角色，我更关心的是，你知道......实际上能够在我的系统上编译这个东西。:)

KerfuffleV2