https://dispatch3.com/tags/kepler/Recent content in Kepler on Dispatch3 Inc.Hugo -- gohugo.ioen-usSun, 07 Apr 2013 00:00:00 -0400https://dispatch3.com/posts/fast_matrix_transpo_kepler_2/Sun, 07 Apr 2013 00:00:00 -0400https://dispatch3.com/posts/fast_matrix_transpo_kepler_2/Last time I presented a clever way of transposing that exploited the GPU’s support of 32-byte stores as its smallest “100% efficient” transaction size. An open question was whether designing a transpose that performed 64-byte stores would achieve better performance at the cost of more instructions. The answer is yes. Performing 64-byte transactions improves throughput by ~8%. The new 64-byte transpose kernel reaches ~148 GB/sec. on a 1024x1024 matrix of 32-bit elements on a K20c (758MHz).https://dispatch3.com/posts/fast_matrix_transpo_kepler/Tue, 26 Mar 2013 00:00:00 -0400https://dispatch3.com/posts/fast_matrix_transpo_kepler/I needed a fast and minimal routine that could transpose a warp with 32 elements per lane and store the result to device memory as the final step in a complex kernel. However, I had a hypothesis that Kepler SHFL instructions and 16-byte stores by pairs of lanes would be functionally equivalent to the standard matrix transpose approach but not require any shared memory or thread block synchronization yet still achieve 100% memory store efficiency.https://dispatch3.com/posts/experiments_with_shfl/Thu, 14 Mar 2013 00:00:00 -0400https://dispatch3.com/posts/experiments_with_shfl/I wanted to double-check my understanding of Kepler’s shfl operation when using negative indices or negative index offsets. The PTX documentation on this instruction is accurate but a little terse so a micro-test was in order. The summary results are: shfl.idx handles negative indices without any problem which means “shuffle rotations” are feasible. shfl.up has no chance to mask the lane - bval value so it sets the in-range predicate to false when negative indices are produced and the lane’s current value is assigned.