[CUDA] Fix row-wise histogram construction with dense data matrix

[shiyu1994]

Currently row-wise histogram construction cannot run successfully with dense data matrix. The check row_ptr_bit_type should be skipped here for dense data matrix,

LightGBM/src/treelearner/cuda/cuda_histogram_constructor.cu

Lines 280 to 288 in 60e72d5

	if (cuda_row_data_->row_ptr_bit_type() == 16) {
	LaunchConstructHistogramKernelInner1<HIST_TYPE, SHARED_HIST_SIZE, BIN_TYPE, uint16_t>(cuda_smaller_leaf_splits, num_data_in_smaller_leaf);
	} else if (cuda_row_data_->row_ptr_bit_type() == 32) {
	LaunchConstructHistogramKernelInner1<HIST_TYPE, SHARED_HIST_SIZE, BIN_TYPE, uint32_t>(cuda_smaller_leaf_splits, num_data_in_smaller_leaf);
	} else if (cuda_row_data_->row_ptr_bit_type() == 64) {
	LaunchConstructHistogramKernelInner1<HIST_TYPE, SHARED_HIST_SIZE, BIN_TYPE, uint64_t>(cuda_smaller_leaf_splits, num_data_in_smaller_leaf);
	} else {
	Log::Fatal("Unknown row_ptr_bit_type = %d", cuda_row_data_->row_ptr_bit_type());
	}

In addition, we disable the use of multi-value feature group in cuda_exp for now in this PR. Because we don't have an implementation of sparse bin currently, thus using multi-value feature group can be too costly for GPU memory. We force the feature groups to be single-value.

[jameslamb]

Thanks for this fix! Two things:

1. Why was this change so urgent that it needed to be merged with admin powers, even when one CI job was failing? (build link)
2. In the future, can you please try to ensure that "fix" type PRs are accompanied by tests that would prevent the issue from being re-introduced in the future?

[github-actions]

This pull request has been automatically locked since there has not been any recent activity since it was closed. To start a new related discussion, open a new issue at https://github.com/microsoft/LightGBM/issues including a reference to this.