ggml: fix CUDA grid launch condition for large block_nums.y in binbcast

[leejet]

This PR fixes a potential CUDA grid launch issue in binbcast.cu.
Previously, only the z dimension (block_nums.z) was checked against the CUDA grid limit (65535).
However, the y dimension can also exceed this limit for large tensors, leading to an invalid grid configuration and potential launch failure.

The fix adds a check for block_nums.y > 65535 to prevent grid dimension overflow.

[jeffbolznv]

Please add a backend test that hits this case. The bug may exist in other backends, too.

[leejet]

The backend test has been added.

[jeffbolznv]

Thanks. This one is kind of slow. Would it hit the same bug with smaller ne[0]?

[leejet]

The smaller ne[0] requires a larger ne[1]. block_nums.y = ne1*ne0 / 256 when ne0 <= 128

        const int block_size = 128;

        int64_t hne0 = std::max(ne0 / 2LL, 1LL);

        dim3 block_dims;
        block_dims.x = std::min<unsigned int>(hne0, block_size);
        block_dims.y = std::min<unsigned int>(ne1, block_size / block_dims.x);
        block_dims.z = std::min(std::min<unsigned int>(ne2 * ne3, block_size / block_dims.x / block_dims.y), 64U);

        dim3 block_nums((hne0 + block_dims.x - 1) / block_dims.x, (ne1 + block_dims.y - 1) / block_dims.y,
                        (ne2 * ne3 + block_dims.z - 1) / block_dims.z);

[jeffbolznv]

Ah, OK. I'm fine with it then.

[slaren]

The second parameter of add_test_bin_bcast is the number of repetitions, so this results in a 4 GB tensor, and it is causing the CI to fail. Using {1,1,1,1} should be enough to test this.

[leejet]

Thanks for your review. I’ve now reduced the repetitions.

[JohannesGaessler]

The CI seems to be failing due to a timeout. I'm not familiar with how the CI was set up so it would be useful if someone more knowledgeable could provide some context.