CUDA: support for weight clamp in top-k norm

[am17an]

Support #16655

[am17an]

@CISC maybe need to rebase? Idk what happened

[ORippler]

@CISC maybe need to rebase? Idk what happened

Stacked PRs + squash-merge require linear history to work well. So the "best" way to do this is to no longer do merges to include upstream changes into a branch, but only do sequential, (interactive) rebases + force pushes from the bottom to the top of the stacked PR chain.

If you:

• want and need 6de8ed7..03792ad in https://github.com/ggml-org/llama.cpp/tree/cisc/norm-topk-bias , you need to rebase https://github.com/ggml-org/llama.cpp/tree/cisc/norm-topk-bias onto master and then do an interactive rebase of am17an:norm-topk-cuda onto https://github.com/ggml-org/llama.cpp/tree/cisc/norm-topk-bias, keeping only 4267d3e..161248c (i.e. discarding the range you need in your target branch)
• do an interactive rebase onto https://github.com/ggml-org/llama.cpp/tree/cisc/norm-topk-bias, discarding the commit range mentioned above if you do not want and need them. This is likely to be the case if you spun your branch off of master instead of https://github.com/ggml-org/llama.cpp/tree/cisc/norm-topk-bias

Once again: Doing stacked PRs manually with git is possible but cumbersome, which is why there exists a plethora of tooling to manage stacked PRs in git

[CISC]

It looks like this happened because you pulled in master, hopefully it is recoverable though, but if not just start a new one.

[am17an]

It looks like this happened because you pulled in master, hopefully it is recoverable though, but if not just start a new one.

It is recoverable, but your branch needs to be updated. For now I can create this PR on master including your change, after you merge your PR we can merge this one

[jeffbolznv]

You need to either check that the upper bound of the clamp is INFINITY, or just always do both sides of the clamp.