Atomic contention in triplet counting kernel could be alleviated

[stephenswat]

The triplet counting kernel is our third-hottest kernel in terms of throughput. However, this kernel introduces some atomic contention through the way it pushes data to the output array:

traccc/device/common/include/traccc/seeding/device/impl/count_triplets.ipp

Lines 105 to 115 in dee541f

	// if the number of triplets per mb is larger than 0, write the triplet
	// counter into the collection
	if (num_triplets_per_mb > 0) {
	triplet_counter_spM& header = spM_triplet_counter.at(counter_link);
	vecmem::device_atomic_ref<unsigned int> nTriplets(header.m_nTriplets);
	const unsigned int posTriplets =
	nTriplets.fetch_add(num_triplets_per_mb);
	mb_triplet_counter.push_back(
	{spB_loc, counter_link, num_triplets_per_mb, posTriplets});
	}

Although modern GPGPU architectures do automatically coalesce atomic accesses to some extent, we might still benefit from coalescing the atomic addition on a block-scale first (using, e.g., barrier::blockCount) and issuing only a single atomic increment per block.

This relatively simple and well-contained issue should be very suitable for developers trying to get started with traccc or with GPGPU programming in general.